这是indexloc提供的服务，不要输入任何密码
Skip to content

GPU Web 2025‐10‐29

Jump to bottom
Jim Blandy edited this page Oct 29, 2025 · 1 revision

Allow binding zero-sized GPUBufferBindings #5312

  • MW: thumbs up
  • KN: There are two things we need to fix in the spec. Kind of ambiguous below. From my comment:
    • 1 Checking minimum binding size of a thing declared in the layout but not in the shader
    • 2 What happens when SizeOf the binding type is 0 (if that's possible)
  • Checking the minimum binding size. If we want to allow 2, that means that we ignore some bindings, which means it makes sense to do 1 as well?
  • JB: It does seem like Jasper added some interesting points there: it’s more about coping with unused indices than creating zero-length things that people actually want to use.
  • KN: So that means that 1) is important, and 2) is not.
  • JB: Good, I was worried about what would happen to OpArraySize, but in this case we don’t need to worry about that at all
  • TT: For the second question - I think I remember seeing WGSL specify that array sizes cannot be zero. So SizeOf cannot be zero at all. Structs also must have at least one field, I think.
  • JB: I think that’s right.
  • JB: If this is only concerned with bindings that are unused by the pipeline, then we want to take the change.
  • KN: We may want to cache the compatibility between the current bindgroup state and the pipeline. Right now. I think it’s the case that if you switch pipelines to another pipeline with the same layout, then we skip validation because we assume that the new pipeline is still okay. But that’s no longer the case if we permit this.
  • JB: You’re worried about the condition where you start with a pipeline that doesn’t use a binding, and then switch to a pipeline that does use the binding?
  • KN: Yes, that use the same layout object.
  • MW: Does that actually increase the validation? Wouldn't the effective minBindingSize that doesn't exist be 0. But that can already change between pipelines even if they have the same layout.
  • KN: Okay, you’re right. Then probably there isn’t anything that can be cached anyway. So this seems fine to me.
  • KN: So: At the pipeline validation level, don’t validate the size of bindings that aren’t statically used by the pipeline.
  • TT: And don’t require that the buffer binding in the bind group be non-zero in length. That requirement exists now, but it’d have to be removed altogether
  • KN: Yeah, that’s the thing quoted in the original issue.
  • KN: You still have to put a buffer there, but it has to be zero-sized? Is this helpful?
  • JB: it’d be better if you could omit the buffer altogether
  • KN: We should decide whether we want to just change the size requirements, or whether we can go further and simply not require anything to be bound there at all. Then we need to reevaluate the validation. It does seem to undercut the design of the layouts if it turns out that you don’t actually have to bind anything. But since we have the min binding size, maybe it’s not worse than what we have already.
  • MW: Seems fine, just a minor inconvenience, dev can always just create a four-byte buffer and bind that.
  • KN: But doesn’t it have to be as large as the struct? Not a huge deal, but that could be large.
  • KN: I think I have a good idea of what the change would look like, but it does need some hammering out.
  • KN: How important is this? Should we backlog it? I think I agree with MW that it’s not that urgent. But at least we’ve identified the complexities.
  • Resolved: Move to Milestone 3. Next step would be to draft PR, and see what comes out of that

[main branch] Specify Compatibility Mode #5402 - discuss any items that come up during review

  • SW: I’ve put a PR to merge compat mode into the main spec, KN has made some cleanups. Any concerns?
  • KN: It’s large, and needs review from the committee
  • TT: I haven’t had time to look at it yes, but I’ve looked at all the patches that landed on the branch, so it should be good
  • SW: There should not be any surprises. I previously brought up the issue of discovering the unique sampler/texture pairs. We glossed over that in the API spec, because it seems like it needs to be covered in the WGSL spec.
  • KN: It’s closely related to the algorithm we’re missing in the main spec. We already have sampler/texture pairing in the main spec, so compat is no worse.
  • JB: I think the algorithm we want for sampler/texture pairs is very close to the algorithm already in the WGSL spec for alias analysis, so we have a good example to follow when we do decide to fix that.
  • SW: Aside from that, no concerns.
  • Resolution: give TT a week to look over the final branch, but expect to merge.

Immediates #75 - proposal doc has been updated (PRs #5399 #5418), confirm we are ready for a spec PR

  • KN: Everything should be more or less done in the proposal. Is there anything else people know they want fixed before it moves forward? Shaobo has begun work on the spec PR.
  • JB: Does the proposal include the word-granularity initialization checks that we agreed to in Toronto?
  • KN: Yes
  • JB: Okay, cool. Then I’m not aware of any other concerns that would block drafting a PR against the spec.

Add support for memoryless textures #5396

  • KN: We’re not going to be able to get too deep into this, but there are two related things: memoryless textures; and managing on tiled memory (#435)
  • KN: I need to read the sample that Mike linked to. Jasper has commented on that.
  • KN: I don’t think there’s an easy way for us to allow deferred rendering on-chip. But we could do memoryless textures if we wanted, as a first step. It might not help, but it would be useful in its own right. So, do we want to do this, or just try to have more robust on-chip memory management?
  • JB: Nice to be able to offer features unconditionally. Make the optimization when available and spend memory when not. Simpler apps have only one code path to deal with. Don't know how that complicates providing better control over device memory consumption.
  • MW: I think exposing the memoryless textures, perhaps with the name that Dawn uses, is a good first step, and would help a lot on mobile, just by removing the uses of the depth buffer and MSAA overhead. And it can be implemented on non-tile-based GPUs too. So we should move forward with this in the context of transient textures as implemented in Dawn now.
  • KR: It’ll be important to make sure that it works when you break a render pass while using a transient attachment, the transient attachment’s content will get discarded. There are some GL extensions like this, but they’re tricky to use in a robust way. So we should make sure that the feature we offer is robust. But it does seem very valuable on mobile, so I hope we can make it work.
  • KN: Vulkan actually has lazily allocated textures, so they’re not volatile between passes. I don’t know if they free themselves afterwards. In Metal, we still need to figure out what the constraints are. In Direct3D, no idea.
  • AB: On Vulkan, it should be easy to implement this in a way that performs the optimization when possible. Using multiple MSAA attachments sometimes forces allocations in a way that is not visible to the user. Looking at how Vulkan’s functionality is used in game engines should help us. I don’t think people vary their algorithms based on whether memory would be required, I think they just make coarse mobile/desktop distinctions.
  • RC: For D3D, the only IHV this applies to is Qualcomm, that’s the only mobile GPU that supports D3D12. If you use … on D3D12, you. There are corner cases where the driver decides it does need the memory after all. There are also cases where the system decides to pre-empt you, and your work needs to be spilled from the workgroup processor to main memory. But you end up needing to allocate the memory, just in case the system needs to kick you out. We could decide to just leave this to the driver, but then you’re at the mercy of the driver’s decisions. For better or worse, the application manages temporary memory, and then the browsers can decide whether it’s actually going to be used. So the behavior should not be like the touchy GL extensions KR mentioned.
  • KN: Is there a way to tell whether the memory got allocated?
  • AB: Not sure. Would have to look into it.
  • JB: Sounds like this needs more investigation.

Validation fails to reject out-of-range fragment shader output locations #5341

  • KN: This is closed. We discussed this in the prior meeting, the spec is fixed, it’s done.

copyExternalImageToTexture/importExternalTexture: Add HDR headroom parameter #5236

  • CC: We’ve had a few more meetings about it. Open issues: linear vs log: everyone wants linear. Then, naming of the parameter: linearHeadroom seems like a good idea. For the default value, I think we settled on SDR by default, but I don’t want to steamroll that.
  • MW: Overall I think we’re in agreement, but we’d like to see the full proposal because we don’t think this this proposal in isolation is useful to developers, because it doesn’t explain how tonemapping should happen. We do not want developers to start doing their own tone-mapping that relies on ScreenDetailed. So we shouldn’t merge this until we have tone-mapping specified in canvas, and here in WebGPU
  • CC: I want to have the entire proposal written out. The ScreenDetailed thing is going nowhere at the moment, so don’t worry about this. I’ve promised a document that puts together all the pieces for 2D, WebGL, and WebGPU. But I’m concerned about this languishing. I can write up a document that shows all the proposals together. But I do think this is valuable on its own. For the moment we’ll wait on that proposal, and then we can discuss order of landing
  • MW: Sounds good.
  • CC: Okay. Next step is for me to provide the full document. And probably ratify in colorweb CG, since it has people from 2D/WebGL/WebGPU.
Clone this wiki locally