Skip to content

GPU Web 2023 10 18

Jump to bottom
Corentin Wallez edited this page Oct 23, 2023 · 1 revision

GPU Web 2023-10-18 Atlantic-time

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

Chair: CW

Scribe: KR, DN, CW

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • WebGPU Compatibility Mode (remaining issues) #4266
    • baseVertex in DrawIndirect (workaround #9)
    • View format reinterpretation
    • Texture layers in views: two options (restriction #3)
    • Mip levels in views (restriction #3)
    • Sample_mask (restriction #5)
    • (stretch) bgra8unorm-srgb
  • Shader module compilation hint API is messy #4338
  • Separate read-only state for stencil and depth aspects. #3036
  • Support for arrays of textures #822
  • Agenda for next meeting

Attendance

  • ByteDance
    • Yunchao He
  • Google
    • Austin Eng
    • Brandon Jones
    • Corentin Wallez
    • David Neto
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Stephen White
  • Mozilla
    • Jim Blandy
    • Teodor Tanasoaia

Administrivia

  • CW: Still outstanding - spec editor
  • CW: Formalizing process for “stage 1”, … to streamline approvals. E.g.. “browser X standards signal for feature YZW”.
    • KR: Discuss comfort level using existence of a feature in a public spec being used as a signal from the browser vendors. (Consensus was already reached.)
    • JB: Let’s defer to Kelsey; she has the most experience in standards like this. Personally seems reasonable.
    • CW: Let’s sync again, and make sure Apple acknowledges.

CTS Update

  • GT: Not much to report, looking to make dawn.node work with compat for the CTS, but mostly useful for the Dawn team.
  • SW: Down to about 700 failures in the CTS between fixing bugs in the implementation and adding suppressions for tests that can't pass on CTS.
    • KR: Stephen made a nice bug fix in ANGLE related to floating-point constant parsing and rounding of the result. (Stack: Dawn -> its GLSL backend -> ANGLE compiling the GLSL) Fixed hundreds of WebGPU CTS tests.

“Tacit Resolution” Queue

  • depthCompare is not required for depth attachments if not used #4336
  • Add RO and RW storage textures #4326
    • Agreement in this group for adding this; tiny mechanics in the spec for compatibility
    • Didn't discuss here:
        1. BGL that specs R/W is compatible with WGSL shader that's write-only. But not read-only. Image layouts, resource types are incompatible in the latter case.
        1. Default pipeline computation: if there's a write-only storage texture that's also a read-write storage texture in a later stage, it's OK, and it becomes a rw storage binding later. Not a problem right now. But will be useful in the future.
    • KN: can that also happen if you use it twice in the same shader stage?
    • CW: can't do that, WGSL will yell at you if you have 2 resource variables with conflicting (set,binding) bindings that are the same grouping location.
    • JB: there's an extension of the compatibility between what WGSL says and what the BGL says? And, allowing slop between 2 pipeline layouts?
    • CW: same flexibility when computing implicit pipeline layout. And grow the storage binding layout using same compatibility concept.

WebGPU Compatibility Mode (remaining issues) #4266

  • SW: thanks for reviews of consensus proposal! Second PR is up now with last week's resolutions.
  • baseVertex in DrawIndirect (workaround #9)
    • Anything with baseInstance was failing. Didn't realize WebGPU made baseInstance an optional feature. Might be that baseVertex works in indirect draws.
    • KR: Thought it was in the structs in all the APIs.
    • KN: It’s (baseInstance) in there, but has to be zero. baseInstance
    • SW: GLES says baseInstance must be zero.
    • SW: if "first" in OpenGL is baseVertex, and if it works, this is a non-issue.
    • CW: the structure of the indirect parameters is the same for every 3D API. If it's the same slot in the indirect structure, it means the same thing.
    • SW: "firstVertex" is the same as "first" in GLES, which is baseVertex.
    • KN: ~100% guarantee that the limits in Vulkan 1.0 are the same as GLES. If it supports baseVertex, then so does GLES. Ordering will be the same.
    • SW: good news. Needs to be in a workaround for baseInstance stuff.
    • CW: baseInstance is already validated out in the base WebGPU spec. Seems that this restriction isn't one, and we can forget about this item.
    • JB: item 9 in the workarounds also referred to direct draws. Wanted to check - the workaround is that you rebind the buffer at a different offset?
      • SW: yes. baseVertex is there in direct draws as well. Workaround is probably there for firstInstance/baseInstance only.
      • KN: think we'd need a workaround for baseVertex for direct draws. That issue links to OES_draw_elements_base_vertex etc. Not for indirect, only for direct.
      • KN: you can rebind. Not sure if you also have to fix some shader builtins.
      • JB: our primary concern: we're reluctant to add workarounds that have significant storage/perf costs. Making copies of vertex buffers - not good.
      • KN: won't be expensive but might need to do some work to emulate builtins in the shader.
      • SW: for now let's treat this as a non-issue.
  • View format reinterpretation
    • Don't have an entry for this in the proposal, but:
    • You can reinterpret a non-sRGB texture as sRGB, or vice versa. Can't do this in GLES because of lack of texture views.
    • Think - upon upload, we can support sRGB formats converting to RGB. Modify shaders. Can't do view format reinterpretation. Then have to modify the shader again at draw time. Prefer to not support view format reinterpretation.
    • KN: I agree we shouldn't allow the reinterpretation, or emulate sRGB on non-sRGB or vice versa. Can't touch fragment shaders' output merger. If we want to support sRGB canvas textures - your rendering into an sRGB texture - then see:
      • Draft PR: Resurrect canvas srgb formats #2551
    • KN: That PR is possibly non-trivial to implement. I asked about this, and Jie from Intel said it won't be easy in Chrome. Need to wire sRGB format all the way through our compositor, and make it work correctly in the compositor. Not sure how well that will work, or interactions with system compositor. Figuring that out will become more urgent. Possible to work around by rendering in sRGB and copying into the canvas, but would like to avoid the copy.
    • SW: other place this was problematic: preferred format is often BGRA. Might end up asking for BGRA_sRGB, not widely supported in ES. Nearly universal support for BGRA8, but not the sRGB variant.
    • KN: that'll interact with how we do this at the canvas level. On Android, preferred format is RGBA. Might not be a problem.
    • SW: need to check ChromeOS / D3D11. Will do more research on this.
  • Texture layers in views: two options (restriction #3)
    • Can't read 2 views of the same texture in the same draw call, differing in mip/array level parameters.
    • 2 options.
      • Array layer: can work around it by having a uniform alongside each texture. Base/size which you'd need to update. Already doing this for textureNumSamples/textureNumLayers.
      • Think this is no more costly than the other emulation.
      • Or, do we validate this out?
      • GT: non-costly option is you don't get any subset, only the whole thing.
      • CW: Apple's fine with adding validation. Mike W answered on the issue.
    • GT: Third option: if you do any subset for layers, then no reason to limit it to 1 view.
      • There's layers and levels. Confusing. GL doesn't have support for subsets of layers.
    • CW: either:
      • full array layer range all the time (bad, because you can't sample from some layers while rendering to another)
      • pass uniform range in, and use this to do clamping
      • I'm in favor of the second. Think that reading from one layer while rendering to another is useful. But I don't know of uses of it.
    • CW: validate it out for now and see if any user complains?
    • TT: sounds good.
  • Mip levels in views (restriction #3)
    • One range of mip levels. Anything more (2 views), validation error.
    • GT: this is per draw call. At draw time - check bind groups, across them - any textures with multiple views with different subsets of mip levels -> validation error.
    • SW: is there current validation at draw time?
    • CW: there is, but we try to keep it to a minimum.
    • TT: there's a way to pass in a range of mips.
    • GT: when you create a view, can spec mip levels. In GL, base/max level. Per texture. No views there.
    • TT: is this widely used? Would people get a lot out of this? Validate out spec'ing any mip range?
    • GT: common when you make mipmaps. Set it to look at the level higher than you're generating, and generate the lower one.
    • Let's validate this out - 1 texture view selecting a mip range is OK, 2 views with incompatible ones are illegal.
    • TT: sounds good.
  • Sample_mask (restriction #5)
    • SW: suggest we validate this out. Supported in ES 3.2, but not ES 3.1.
    • CW: Mike said he's ok with that.
    • TT / JB: OK with that too.
  • (stretch) bgra8unorm-srgb
    • SW: not widely supported format on ES. Think we can handle it on upload, doing a compute pass to swizzle to rgba8unorm-srgb.
    • KN: had all sorts of funny issues with bgra/rgba. Android, Compat device - just use RGBA. But, to implement Compat on other devices where preferred format is BGRA, would end up using this. But only if you have texture view reinterpretation - which you can't. Only till we have a way to use sRGB with canvases. Maybe we don't have this format in Compat now.
    • TT: is this point 7 in the workarounds?
    • SW: not sure I put this anywhere…it's point 10 in the first section. We propose to validate this out. First alternative - use compute shader to swizzle on upload/readback.
    • TT: this would depend on workaround #7? to have bgra8unorm textures?
    • SW: should talk about that. There's not official BGRA support in ES 3.1. Very widely supported though (99%+ reports).
    • CW: then we need compute shader copying buffer->texture for the sRGB version. Or a blit looking at the storage buffer.
    • CW: how about coming back next week with more detailed explanation.
    • SW: SGTM
    • KN: really tricky.

Shader module compilation hint API is messy #4338

  • KN: we'd decided we'd support multiple … per entry point because it was necessary. Implemented it in a non-breaking way. Then found nobody's implementing this. The way I did this is messy, would like to clean it up. Chrome implements the IDL for compilation hints, but doesn't do anything with them. I suggest we change the name and implement the hint. That way old code will ignore it and they'll have to update their code to be compatible with the new way.
  • JB: Mozilla thought this sounded great.
  • KN: Mike supported it as well.
  • CW: consensus -> can do it. Slight difficulty on Chromium - technically, unshipping a feature, have to tell owners that this won't break anybody.

Separate read-only state for stencil and depth aspects. #3036

  • CW: investigated with bunch of tests. AFAIK this passes on Metal, D3D12, D3D11. On Vulkan with KHR_maintenance2, made it work though it was very messy. Some progress without KHR_maintenance2, too, using the general layout. Can work, but still some bugs in my impl.
  • CW: given all this - and since Unity and Unreal Engine users wanting this - suggest we take this in. Fine if we require KHR_maintenance2 - we lose very few devices with this requirement.
  • TT: one q: did you remove the AMD extension from the base set of the tool? It's still there right now. We require maintenance1 right now, want to render to 3D texture layers.
  • KN: forgot to do that. Viewport inverting thing?
  • TT: yes. Then set of devices will be even smaller.
  • KN: true. Only ~1 GPU in there. Probably would disappear.
  • CW: makes it even easier to decide to support this.
  • TT: yes.
  • CW: Mike said on Metal it's fine so I assume he's fine with this. OK if we land this change?
  • TT: yes.
  • CW: thanks!

Support for arrays of textures #822

  • Skip for this week.

Agenda for next meeting

  • Arrays of textures.
  • WebGPU/Compat. Come back to items about format reinterpretation, bgra8unorm-srgb.
  • Not that many milestone 1 issues. Made progress on Compat this week, maybe cancel next week if it's just these two Compat items?
    • Let's heads-down on impl for one more week then. Meet on November 1.
    • KN: FYI next week is Khronos F2F anyway.
    • CW/DN going to that.
  • CW: let's try to make this meeting Pacific/APAC time. Will ask Pacific time / Intel folks if they have topics.
Clone this wiki locally