Skip to content

Minutes 2023 03 15

Jump to bottom
Corentin Wallez edited this page Apr 4, 2023 · 1 revision

GPU Web 2023-03-15

Note that unless stated otherwise this is a GPU for the Web community group meeting and not a working group meeting.

Chair: KG

Scribe: Ken

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • Limit for the maximum resource size? #3916
  • (GPUDeviceLostReason or undefined) seems non-standard and results in problematic feature detection #3894
  • add query for list of WGSL software/shader-lang extensions (e.g. do-while) #3875
  • maxBindingsPerBindGroup has arbitrary limit of 640 #3864
  • Agenda for next meeting

Attendance

  • Apple
    • Mike Wyrzykowski
    • Myles C. Maxfield
  • Google
    • Ben Clayton
    • Brandon Jones
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
  • Microsoft
    • Jesse Natalie
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert
    • Teodor Tanasoaia

Administrivia

CTS Update

  • KN: Shrek & I working on texture expiry timing tests. Tough - made some errors while writing down what I thought should be in the spec. Fixed now. Trying to test loose guarantees about texture expiry. Think working now. More corner cases can be tested. What if Canvas is transferred to offscreen? Both implicitly transferred, and has transferToImageBitmap on it? Not tested yet - but have basic tests for expiry timing. Also writing tests in our impl to test the exact expiry time.
  • KN: collecting code coverage data for our impl. Ben Clayton recently looked through Tint's ccov results, found bunch of things not covered well, will add more tests soon.
  • KN: Chromium's branch point is 1 week from now FYI! Couple small things to get done before then. Unsure about testing vs. impl focus for the next couple weeks.

“Tacit Resolution” Queue

Limit for the maximum resource size? #3916

  • KN: found this limit in D3D - here's the max size for any type of resource. We don't have this for textures right now, just max dimensions. In D3D, this limit - if there's VRAM available you're guaranteed to be able to allocate this much. Above this limit, may or may not succeed. Soft limit. Wanted to document it. But - don't think we need to change anything in the API based on this.
  • KN: anyone aware of other hard resource limits in other APIs?
  • KG: in our spec, maxBufferSize is a limit. Impls might report something large if no hard limit.
  • MM: in Metal, max single resource size < max addressable range by a shader. Smaller than VRAM. Shader could have access to many large buffers it can't allocate. Metal will still work, but resource won't be on GPU any more and reads/writes will go over the bus.
  • KG: still valuable to have this hard limit?
  • MM: hard limit is - limit on size of a given buffer. E.g., how many bits does a pointer need inside it? OK to have multiple resources, as long as each resource is small enough that a single pointer can go from its beginning to its end.
  • KG: we'll keep it then. Might be deceptive.
  • Resolved: do nothing for V1.
  • MM: if we're making a mistake now - say lots of applications try to make buffers that fail to allocate - is this something we can change in the future? Might want to err on the side of caution then.
  • KG: impl choice. Saying, this is a hard limit.
  • MM: about textures. Hard limit in WebGPU is about buffers - this issue's about all resources.
  • KN: don't think we need to add a limit, even cautiously - the D3D thing is more of a guarantee you can allocate this if you have VRAM. My reading - you're expected to be able to allocate things above this limit if you have space. Don't know what the limits look like. Sort of like OOM. If you have VRAM but have fragmentation, you'll have OOM anyway. Don't think we need a new limit.
  • RC: no D3D team members here today, but can ask them questions. Do we want clarification on the quoted text in the issue?
  • KG: Q we want to ask - is there a hard limit for max buffer / resource size in D3D?
  • KN: if I were to ask that question, would want to ask it for all backends, not just D3D.
  • KG: what will we do here to progress this question?
  • MM: (a) D3D limit is listed in the spec, but in reality apps go above the lmit all the time, expected to mostly work. Resolution - don't touch the spec. (b) there's a limit in D3D - if app goes over it, they should feel bad, make sure nobody thinks about going over it. In (b) that limit should be hoisted up to WebGPU. That's the question for the D3D team. How harsh is the spec text Kai quoted? Best-effort, or a formal requirement inside WebGPU?
  • RC: not sure.
  • KN: this limit is not given to us by the hardware/driver. It's ¼ the amount of VRAM you have - defined that way, with min/max value. The driver tells us - just a D3D hardcoded thing.
  • (Jesse joined, can ask the question directly now)
  • JN: confirming - asking whether resource size limits that are documented should be considered binding?
  • KN: yes. Seems clear from language it's not a hard limit.
  • JN: my understanding - don't think there's a hard limit, or anything that checks against these limits. D3D - buffers - 4 GB size isn't even a limit any more. Textures - typically run into texture dimension sizes before any size-in-megabytes limit. Max dimensions, max array size - don't think anything'd prevent you from exceeding the e.g. 2 GB size listed in the docs.
  • KG: concretely - is there a max buffer size similar to max 2D texture size?
  • JN: concretely, no.
  • KN: with base limits, you can ask for 1 texture 256 GB in size. Possible for things to get really big in texture land. Cases like this are OK to call out as memory errors.
  • JN: yes.
  • KG: # samples too.
  • JN: when dealing with tiled/sparse textures, can go well above any reasonable memory size.
  • KG: so, no max resource size. And if we only supported D3D we wouldn't have a max buffer size, either.
  • JN: we do have caps in D3D12 for max number of address bits available for a resource. Most GPUs - independent of processor architecture. Usually 38-40 bits. But sometimes have 32 bit process limit.
  • KN: OK, good impl note. Probably want to use that to express the max buffer size.
  • MM: is that per-resource? Or addressable by a shader in aggregate?
  • JN: 2 limits. Max address bits per resource, and total address space size.
  • KN: have pointers?
  • JN: yes, can link to this.
  • KN: want to document.
  • MM: Metal has one of those limits (# bits per resource) but not the latter. Go over that limit, we'll use the PCI bus.
  • KG: so, no limit for max resource size now.

(GPUDeviceLostReason or undefined) seems non-standard and results in problematic feature detection #3894

  • MW: testing for undefined in the non-failure case - seems hard to know whether feature's not implemented.
  • KN: reasonable. We should just give it a name and call it "Unknown". Happy with that change.
  • MW: sounds great from our perspective.
  • KG: resolved.
  • MM: someone from Apple can put together the PR for this.

add query for list of WGSL software/shader-lang extensions (e.g. do-while) #3875

  • KN: proposal right now: on navigator.gpu, put another thing, navigator.gpu.softwareExtensions or similar. Set-like thing, can ask if it contains something. Set-like of strings. Strings there will be same as those which show up after "requires" keyword in WGSL.
  • KR: could we be explicit about the name? "software extensions" sounds ambiguous.
  • Discussion.
  • BC: "extensions" in Tint are what you enable, "features" are what you require.
  • KN: OK. Different from API spec.
  • KR: "syntactic sugar features"?
  • KN: hardware features are in the API spec. We don't have vendor-specific extension documents, so we got rid of the word "extension". Think we can come up with a name, not sure what it is offhand. Will figure it out.
  • KG: just awaiting proposal.
  • KN: will be on tacit resolution queue next week, as long as everyone's happy with set-like entity.

maxBindingsPerBindGroup has arbitrary limit of 640 #3864

  • KG: proposed as a joke, but a directional joke. Deliberately chosen to be arbitrary.
  • MW: our concern, why's there a joke in the spec.
  • KG: otherwise we'd need a lower limit.
  • MW: what about something closer to 2^16 - 1?
  • KG: trying to split the difference slightly. Picking something in the middle, "log-scale".
  • KN: specific problem. Some drivers effectively loop through the entire space, up to the max index you use. Wanted to clamp that max index so people have enough space to work with, but not hit that large loop on drivers on which they don't test. Aside from saying impls have to do something to compress the space on those drivers - complicated because it requires pipeline-time-compilation work - this keeps people within a reasonable bound.
  • MW: why don't we choose a limit like 512 or 1024 then?
  • KN: we felt it important to make the limit seem arbitrary. Don't want people to think there's a real/hidden meaning behind it. Could have been a different arbitrary number. Power of two will make it look like a number of bits.
  • KG: that was the goal.
  • MM: just calling it 640 doesn't make it arbitrary.
  • KG: if you want a different number, please propose a different one. I propose 1000.
  • GT: can we add a spec note saying it's arbitrary?
  • BJ: there is such a note. "640 ought to be enough for anyone". Could make that more explicit, and say 640 is an arbitrary number. We can say that. Useful if the number looks arbitrary.
  • MM: why do we have this limit in the first place?
  • JB: there's a bug in the Mesa driver. We give it a gigantic index - Mesa driver slows down hugely.
  • KG: lower limit of 112 isn't actually the limit. That's the max limit if it's dense. Choosing a higher limit for sparse packing. Safer if we know it's lower than the problematic number. Is "1000" better? Tolerable for everyone?
  • MW: no objection
  • MM: if motivation's badly behaving driver, then the value should be informed by the de facto limit, not randomly.
  • KG: wasn't random. Erred on the side of being safer. 2 ^ 16 - 1 wasn't good. 2^15 - 1 seemed to be OK. We're confident that ~1000 is safe. Looking for consensus here, not a "correct" answer.
  • MW: I'll chat with Myles and we'll propose something in this issue.

Agenda for next meeting

  • Almost no PowerVR devices satisfy minimum Vulkan requirements #3631
    • (If Google comes back with some opinion about PowerVR support)
    • Turns out we still don’t support PowerVR - should we declare that we simply can’t? (without WebGPU compat)
    • Also a question about Adreno 500 support
  • Proposal: formats-tier-1 extension #3837
    • Make post-v1 even though it could subsume the existing "rg11b10ufloat-renderable" feature?
  • requestAdapterInfo() should be required to prompt (in at least some circumstances) #3962
  • Occlusion Query results seem under specified #3895
Clone this wiki locally