Skip to content

Minutes 2022 07 20

Jump to bottom
Corentin Wallez edited this page Jul 26, 2022 · 1 revision

GPU Web 2022-07-20

Chair: Corentin

Scribe: Ken / others

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • texture_2d_depth for loading depth values might be unnecessary? #2094
  • Specify that texture_external sampling functions clamp coords to [0, 1] #2766
  • Buffer Offset issue in buffer-texture copies with depth stencil textures #3185
  • Passive Fingerprinting Surface #3101
  • Agenda for next meeting

Attendance

  • Apple
    • Myles C. Maxfield
  • Google
    • Brandon Jones
    • Corentin Wallez
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Stephen White
  • Microsoft
    • Jesse Natalie
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert

Administrivia

  • Ongoing call for editors
  • CW: Asked Francois Daoust to email other working groups for wide review - he will do, for WebGPU and WGSL.
  • Only question is WHATWG - what specific aspects of the spec we'd like them to review. Need to make a list. Kai, Brandon or Myles?
    • KN: I'll make a list and post to the issue this week. We have 1 open issue Domenic (correction: Anne) filed, #2930, that will go into this bucket. Can point them to interop parts. Not too difficult to review.
    • CW: no urgent rush. Have said, 3 months for reviews.
  • MM: topic about <model> element and WebGPU interaction - opinion of the WebKit team that they don't interact at all.
    • CW: are the only people involved in <model> (or the majority) the WebKit team so far?
    • MM: no -
    • CW: want to make sure people across web platforms know about potential interactions and can review.
    • MM: we don't think any additional reaching out to other web framework standardization groups is necessary.
    • CW: OK, thank you.

CTS Update

  • KN: work ongoing, in particular on WGSL side. Ryan invested lot of work in a framework for numerical precision tests for builtins. Done, should make testing more robust.
  • KN: Igalia contributor making progress. Also from Takahiro from Mozilla.
  • writeTexture - didn't have many tests.
  • MM: (?) would Ryan's framework apply to API testing too?
  • KN: didn't discuss that. Little framework on API test side for precision. Don't know Ryan's work well enough to know whether it'd apply to the API side. If need more flexibility / robustness, we'll discuss.
  • KN: still aim to amend the PR to generate multiple files.
    • MM: no need to prioritize that, have a method that works for now.
    • KN: I'll land that then, can iterate on it later. Need someone to review.
    • MM: I can review whether it's sufficient.
    • https://github.com/gpuweb/cts/pull/1637

“Tacit Resolution” Queue

  • Empty!

texture_2d_depth for loading depth values might be unnecessary? #2094

  • MM: didn't realize solution we came up with would have the effect of increasing the binary size multiplicatively or exponentially
    • Medicine worse than the disease
  • MM: not sure that any compiler will actually blow up binary size
  • MM: but should just not ask authors to produce the extra information, and generate the code that will work.
  • KN: think making the proposed change is fine.
  • KN: enforced at pipeline creation time. We do the static analysis to know what textures / samplers are used together. This would be what textures / texture functions are used together. Not much more of a burden than we already have.
  • CW: not sure which solution we're talking about.
  • MM: summary: there are 3 options here. (1) we normatively say, any depth texture you bind to a shader, the type must be the depth type. (2) if you want to bind depth texture to shader, you don't have to use the depth type in the shader. If you don't, you have to provide that info in the BGL at pipeline creation time. (3) any depth texture can be bound to a non-depth texture type in the shader. Developer doesn't need to provide info at all.
  • MM: purpose of option (2) - offline compilers producing WGSL don't have to know what's depth and not. WGSL->Metal compiler would need to know - info provided by the API.
  • CW: right now we have (3)?
  • MM: previous resolution was (2). Option (3) better for authors, but didn't have confidence it'd work for authors. Since then, realize that to act upon this information, would need to do shader transformations blowing up shader size multiplicatively or exponentially. (3) will work most of the time for most operations. Increasing shader size will always make things worse.
  • CW: so we're going with (3) now? Incorrect code not too far off correct?
  • MM: right.
  • CW: thanks for the summary.
  • JB: do we need to defer shader compilation until later?
  • MM: no. Any solution where the depth info isn't in the shader would necessarily require this blowup. Regardless of when you compile the shader - using depth texture info blows up shader size. Option (3) instead is - never blow up the size of the shader. Generate invalid source, doesn't follow the rules, works anyway, but avoids blowing up the size.
  • JB: sounds fine. As long as we can preserve ability to compile shaders early.
  • CW: resolution to change to (3).

Specify that texture_external sampling functions clamp coords to [0, 1] #2766

  • MM: last week, where we left off - Kai asserted that there's no way the behavior of samplers can be symmetric between sampling external and color textures. We both wrote long posts. I think that statement was false - possible for them to be symmetric. They are, aside from these two sampler mode fields addressModeU/V. Also stated the reason symmetry's important. Functions which sample from external and regular textures - same signatures. One of the two ignoring certain sampler properties is unfortunate. Last week, had discussion about how to get this info into the shader. If we have to polyfill addressModeU/V - any mechanism's fine with us. Bake info into external texture. Feature extensions. Injecting info at BGL time - I don't think it's worse, Kai does.
  • KN: think it's pretty accurate about what I said. I don't think it's impossible to do this. I think it's unwarranted complexity. Point of describing the different methods to get that info into shader - here are the options we have. None are simple. Complexity's high. We think it's unwarranted - think this is a relatively small symmetry problem.
  • CW: If we do things at BG or draw/dispatch time - these are the most expensive / common calls in the API. Even checking, do we need to do extra work? More work we add, the more unhappy developers will be.
  • MM: is the statement you made specifically about adding branches? Or about adding new lines of code inside setBindGroup?
  • CW: the leaner impls can keep these calls, the better for performance. Lot of discussions about doing validation at draw time - extra branches, scary perf-wise. I'm reluctant to add any code, but we have to. If we can avoid it, it's best.
  • MM: the reason I didn't / don't think this is a problem - whenever you setBindGroup with external texture inside, you already set a bunch of different things. The clipping bounds, etc. Because all this stuff is being set, I'm talking about setting two additional pieces of info - each is 2 or 3 bits. Thought the cost would be low.
  • CW: you can bake all the external texture data at creation of external texture, or creation of bind group. Can decay the external texture to regular texture operations.
  • GT: still not familiar with the API, but to the point of things being ignored in samplers - in WebGL, if you sample integer texture, certain parameters are off-limits. At API level it's a normal texture. True in WebGPU? Pointing out it's not unprecedented that not all the sampler parameters are obeyed all the time.
  • KN: we have a complicated system of filterable/unfilterable texture types that we validate at pipeline creation. We know what types they are from BGL. Validate at BG creation that it conforms to the BGL. Responding to Myles: don't think it's as simple as a couple external bits in external texture. If it were I wouldn't be concerned. To make this fully general, have to be able to use N external textures with M samplers. At draw time have to look at all bind groups, all (external texture,sampler) pairs, look at BGs, see what data they're associated with, … - put this whole table of metadata somewhere the shader can access it. A lot more complicated than putting some trivial data in a uniform buffer.
  • MM: any time you use a sampler those bits would be used. Wouldn't be MxN. You're right about the time those bits would have to be identified.
  • KN: maybe not MxN - but you would have as many as there are samplers. Need to upload some kind of data into bonus space associated with external textures - either where to lookup data, or what it is. More complicated than that.
  • KG: idea to have an external sampler type, if it makes people happier about what you can do with them - reasonable to me.
  • MM: think there are 3 possible paths. Assume we can cross off idea Google objects to, there are 3 left. (1) add external sampler type. (2) change name of function, like Corentin suggested. (3) bake samplers into external textures. Would solve lifetime problem Kai pointed out.
  • KG: not particularly useful to have separable samplers for external textures.
  • MM: of those 3, only one satisfies the goal of tiling external textures be a part of the web platform.
  • KG: wouldn't want to have to implement tiling for external textures - sorry.
  • CW: if you don't want to implement that … external samplers that we force can't do tiling, or function rename, are the options.
  • MM: adding external sampler type is more elegant, but bigger change to the API surface.
  • KG: think that's worth exploring.
  • MM: worth thinking about?
  • CW: for Kelsey - also the option that you can pass parameters at external creation time. Right now, we don't allow wrapping.
  • KN: that's the direction I'd prefer. Don't think external sampler buys us much. Don't think it's worth the substantial complexity of adding a new type to shading language and the API.
  • KG: I don't see it as heavy cost FWIW.
  • MM: if we bake samplers into extnernal textures, does add a path forward in an extension to add more fields to that baking function. Could add this functionality in the future.
  • KG: something I'd more entertain after V1. don't want to reimplement filtering for V1.
  • KG: filtering + address modes makes you resynthesize sample from fetch for REPEAT - we discussed this previously.
  • CW: given all the options there, I think I have a fair preference for baking the sampling parameters into the external texture. Something other people can agree with?
  • KR: could we not just write these restrictions (clamp-only, which I prefer) in spec prose and continue to use the sampler semantics?
  • KG: think it's implementable
  • MM: better to not let authors express an illegal state. SamplerDescriptorBase that SamplerDescriptor inherits from, and take SamplerDescriptorBase in external texture creation.
  • CW: think we have multiple options that we can choose from.
  • KN: I'm fine with combining the two. I prefer to rename the function for external texture sampling. Can still add addressing modes to external texture later on. Will just use those instead of those in the sampler.
  • MM:
  • KN: use one sampler with multiple external textures. Prefer we do that, as external texture objects are already heavy in their binding cost.
  • MM: you're making external textures heavier but also saying they don't need separate sampler objects.
  • KN: most common case, yes, 1 external texture w/1 sampler. But if using one external texture with multiple samplers, or one sampler with multiple textures (external or not) - your binding cost goes up.
  • KG: want to think about this.
  • CW: seems we defer again. For the record, I'm convinced with Kai's reasoning. Maybe can reach resolution offline.

Buffer Offset issue in buffer-texture copies with depth stencil textures #3185

  • CW: D3D12 has validation rule - when you do buffer-to-texture copies, offset into buffer has to be 512-aligned. In other texture copies, can split them up to bypass the limitation. D3D12 also says - copying buffer to depth texture, have to copy the entire subresource. Hack doesn't work any more. Do we add this limitation to the API? Do impls silently copy from buffer to correctly-aligned buffer, and from there into texture?
  • CW: D3D12 recently added optional feature where these constraints disappear. All HW should be able to support that. All HW supports Vk, doesn't have the limitation.
  • CW: my suggestion - impls do the extra copy, and eventually, it won't happen because all D3D HW will support that extension.
  • JN: sounds reasonable. Commented on the issue - the whole-subresource restriction for depth is relaxed by a preexisting feature from Windows 10 days - partial MSAA feature does this. If you have that can fall back to your smaller number of copies solution.
  • MM: first paragraph says has to be multiple of 512 - is the #512 true on all devices? Will that number ever be device-specific?
  • JN: hardcoded in header. Either 512, or it doesn't exist.
  • CW: thanks JN for the add'l detail. Even more cases where that limitation doesn't need to apply.
  • MM: sounds like 2 issues- one about alignment of copies, and one about copying of subresources.
  • CW: same thing.
  • JN: based on my understanding- they're different but related. The alignment restriction is a thorny issue in general, requires a workaround to not have WebGPU have the restriction. And the workaround falls over for depth textures because of the whole-subresource issue.
  • MM: so solution is we don't add alignment requirements because we can polyfill it … but have to put whole subresource copy into WebGPU spec?
  • CW: if you copy from buffer into depth texture, you have to copy whole subresource, but don't have a constraint on the offset. Don't change the WebGPU spec at all, is the solution. Require impls to copy to temp buffer to align data correctly, on D3D12 devices having neither of these extensions.
  • JN: yup.
  • MM: sounds fine to me.
  • JB: I'll have to look it up - don't know offhand.
  • CW: if wgpu is fine with this then we can close this issue. Otherwise can discuss more.

Passive Fingerprinting Surface #3101

  • Punt to next meeting

Agenda for next meeting

  • CW: Let's really try to find resolution offline on external texture clamping, etc. Think we can do it.
  • CW: cancel for next week?
  • KN: editors hoping to have proposals for couple things related to errors. Not crucial to do this next week, if we'd like to skip.
  • CW: let's skip next week, come back with full agenda in 2 weeks - APAC time.
  • Agenda
    • Drop support for macOS 10.12? #3238
Clone this wiki locally