Minutes 2022 06 29

GPU Web 2022-06-29

Chair: KG

Scribe: KR / KG / others

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• Socialize: Passive Fingerprinting Surface #3101
• Specify that texture_external sampling functions clamp coords to [0, 1] #2766
• Expose WGSL errors in the API #2308
• Consider making ShaderModule compilation errors special #2119
• (stretch) Should objects have pointers back to their parents? #1497
• Agenda for next meeting

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Brandon Jones
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• Microsoft
  • Jesse Natalie
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Michael Shannon

Administrivia

• Socialize: Criteria for pushing the WebGPU and WGSL specification to Candidate Recommendation #3107
  • KG: Note: this isn't "releasing the spec" - widely reviewed, satisfies tech requirements, publishing to gather impl experience. Do we think the spec satisfies our API criteria.
• MM: tangential thoughts: think you're right we're running out of issues to discuss. Not running out of issues that need individual work. I have a lot of these - but I'm not the only one in the group who does. Do we think it's each individual's responsibility to get these done, or worth group action to do so? And if group action, what should it be?
  • KG: gets into project management. Sometimes you assign these somewhat arbitrarily. Imagining that as discussions proceed, we should re-triage assigned issues. If we think timeframe isn't realistic, reassign them.

CTS Update

• KN: not much new. Some work continuing from a few contributors. More work from other folks getting this running in their impls is welcome.
• KR: One other note, a contractor from Igalia (Gyuyoung Kim) is helping with validation and operation tests. More participations would be very welcome. We want to make sure we have good coverage, and also reduce customer use cases into test cases.
• MM: We had a discussion about listing the tests as a separate file, rather than what we have now.
• KN: haven't done anything yet - would like to know what format you need them in. Pointers to how you run other tests in similar frameworks would be helpful.
• KR: One heads up, watch out for per page test overhead. If we go to many more pages than we are, the suite may take a lot longer to run.
• MM: I'm certain that's true. Not a question of fast/slow mode - more, do we want to run it at all. Don't have the facility to list tests in a single file. We have to go slow before we can go fast.
• KN: main thing - unless we generate many many thousands of files, run times of these test pages will be highly variable. Many things in one test. Something to think about - do you have trouble with corpus of highly variable run times?
• MM: variability not an issue. Issue is if one single test takes a very long time. Solution's already in the CTS infra - it has a facility to say, this one test has 10,000 test cases, so separate out these chunks. Likely hand-created.
• KN: maintaining that splitting's a pain. Works to some extent. Let's discuss on email.

“Tacit Resolution” Queue

• https://github.com/gpuweb/gpuweb/pull/3070
  • KN: resolved this - binding depth textures to texture-typed binding points - you can do this, just use depth type in bind group layout.
  • KN: only did this for texture-2d binding type. there are also cube, array, and cube array types. Also exist for depth textures.
  • KN: should be fine to extend this similarly. Just want to make sure nobody sees issues with this. Since we already have these types in the API and WGSL - you can already translate them similarly.
  • MM: works for us.
  • KG: sounds fine. Go ahead.

Socialize: Passive Fingerprinting Surface #3101

• KG: filed as part of PING review.
• KG: not requesting specific PRs or spec changes, but they'd be happy if things get better.
• KN: rather they're not proposing specific changes but they're requesting them.
• MM: they're presenting 5 options.
• BJ: 5 avenues to look into, rather.
• MM: agree, correct.
• BJ: one thing - last item, reduce granularity of values exposed - on Chrome, we're already doing. Spec has language - bucketing values. Unclear if that was recognized when they put in this comment, or if we should make this spec text stronger. Would like clarification. On Chrome side, already implementing. Hope other vendors hope to do the same. Like to know how much of a mitigating effect this has on their opinion.
• MM: word "can" is used here - if all browsers have plans to do this, suggest using "should".
• KG: concern with "must" - details we don't need to agree on. Prefer to leave up to UAs.
• MM: we can use "must" but not specify what gets bucketed how. "A browser must make similar devices appear as though they're identical" or something like that.
• KG: we can.
• BJ: I think this is a "should" situation. "must" feels a little strong. Think we can and should be more prescriptive about that we strongly recommend browsers take some of these steps.
• MM: I wouldn't push harder than that.
• KG: PRs welcome.
• MS: one issue about not standardizing this - something that works in one browser, but not another, on the same hardware. "Use this browser" - want to avoid.
• MM: good point. If you're on GPU X you have to use this browser…
• KG: boils down to: what do UAs want to support?
• MM: if one browser's more finely grained than another…
• KG: all UAs voluntarily handcuffed in the same way? Don't think it's worth getting into specific details of how we handle these.
• MM: think we'll discuss this when the group's less pressed for time.
• MM: what does "visible contexts" mean?
• BJ: we have visibility APIs on the web. Making some assumptions based on its behavior.
• MM: IntersectionObserver?
• BJ: window/tab visibility. Need to clarify - limit these capabilities to visible contexts. Capabilities are fairly static once device's created. Visibility can be fluid. With model we have now - reluctant to change - can't say, you got new capabilities because you're looking at the page. Seems bad for a variety of reasons. Limiting caps to frames that have received activation - few ideas here that you get really limited caps until later, when adapter gives you more stuff. Awkward model. Would like to not do anything along those lines.
• MM: discuss in future meeting?

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

• KG: last week - just having clamp in MVP seems reasonable. Implementing addressing mode yourself isn't that complicated. Myles wanted flexibility here.
• KN: specifically - came up with slight variation on Corentin's original proposal. We keep things as they are, do his orig proposal - clamp coords to rectangle for external textures. Later, add ability to configure whether it clamps or not on external texture. Use separate sampler, but its addressing modes are ignored. (...audio dropped out…)
• KG: https://github.com/gpuweb/gpuweb/pull/2796 external sampling always uses clamping address mode. Add those subsequently.
• MM: don't understand why clamping address modes are easier to impl than other address modes. The rectangle you're clamping to is a region inside the texture. When content says, sample at (x,y), we have to do some math. That math can implement clamping, repeating..
• GT: it doesn't implement repeating. Left of leftmost pixel, you have to pick up pixels from right hand.
• MM: is that not true for repeating?
• GT: no.
• KG: right, repeat / repeat-mirror has to decay into 2 different samples.
• MM: confused about - if people sample right most pixel, and it's a filtering sampler - if we just call sample() with that position- 2 left ones in bounds, right ones out of bounds. Also wrong.
• KG: you implement clamping by clamping extents of rectangle into half-pixel of what you're supposed to sample. Furthest out you ever sample is the very last floating-point sample point that gives you the clamp behavior.
• MM: i see, so you're missing half-pixel size border around image. If you use same technique with repeat, you'd miss half-size border but would be more visible?
• KG: no, you're supposed to get filtered results between multiple pixels. No way to synthesize this with a single sample point.
• MM: I see.
• KG: can do it for mirror though.
• GT: I'm happy if it does repeat and it has that issue - just document it. Funky repeat. In most cases you probably won't notice. Think most users won't care, but they can also repeat at a higher level and have it clamp at this level.
• MM: if dev does it at their level they won't get this edge effect either.
• KG: unless they do it themselves and opt in to the add'l overhead.
• KN: one thing we can do with repeat modes that they can't - if there isn't unused data at the edge, we can use the sampling hardware to get that behavior. If the sampler has the appropriate mode. Gets into option (3) where we combine texture/sampler.
• MM: appeal of option (3) - solves the edge effect problem. How does an implementer implement the correct edge effect in this option?
• KN: not that we'd always implement this, but opportunistically do so. If we can't use sampling hardware, we have a seam at the edge. Would work better in many cases. Eg if you had 640x480 that'd likely fit within macroblocks, but 1080p would have a seam in one direction.
• MM: i see, so if stars align about this then you'd get the desired behavior.
• KG: I think the amount of time invested on implementing addressing modes isn't worth it, and that repeating/tiling is "nice to have".
• MM: we disagree on this - think tiling videos is popular.
• KG: I'm more saying that clamping satisfies the use cases, and that developers will be able to work around this in their shaders.
• KN: agree - think dealing with this in user space is easy enough that people will just work around it.
• KR: can we not agree to stick with the clamping behavior?
• KG: people aren't convinced, let's give them more time to convince themselves.

Expose WGSL errors in the API #2308

• KN: did we have more to discuss here? Internet's out here now.
• KG: didn't come to conclusion last week.
• KN: thought we'd treat this more like out-of-memory errors. Treat them like potentially recoverable. Thought we were done with discussion for now. Result - someone makes proposal like that.
• MM: q: in order to know whether one of these uncategorized errors has occurred, you have to invoke the platform compiler. If exposed like other validation errors - they'd show up at shadermodule creation time. So have to be able to run platform compiler at shadermodule creation time - not sure whether other impls plan to do this.
• KN: I think we should defer all of these to createPipeline time, even if impl gets the error from the platform compiler earlier.
• MM: think that's the only way this can work. Some impls don't run the platform compiler until createPipeline. "This error can be exposed either in createShaderModule or createPipeline." The OpenGL way.
• BJ: I'd prefer if this were consistent. Fewer places people have to wrap in error-catching mechanisms. If app absolutely needs to know error came from specific shader module - they could create dummy pipeline around it. Not convinced this is necessary.
• KG: in GL, standard practice - you check program link status. Print program link log then. Didn't compile a shader properly. You blindly check for link status - print program link status, VS/FS compile statuses, compile logs. Nice if we didn't do that - just report it late.
• KG: only way you can get around this.
• KN: also one other reason we need these in pipeline creation - they don't just come from the compilers but also from pipeline creation like inability to allocate shmem or registers.
• MM: check link status, then link log, etc - are you describing what the browser does or what users do?
• KG: both. At some time in FF I added compile failure logs to the program link failure log. Could technically guarantee that.
• MM: So are we done/resolved then?
• KN: We were talking about whether we should differentiate between validation errors and uncategorized errors. Validation errors are probably author error/not automatically recoverable, but you might have fallbacks for uncategorized errors.
• KN: Thus we should consider adding uncat errors to ooms (not validation errors), or add a new type of error.
• MM: Why with ooms?
• KN: They are also unpredictable, and you can kind of respond to them programmatically
• KN: We don’t want people looking at the string to figure out what to do programmatically.
• KG: Probably don’t fold with oom, but just realize they kinda are similar
• MM: +1, let’s add a new error type.
• Resolved: New error kind
  • KN: need proposal for this, but mostly editorial. Hopefully someone will come up with proposal and bring it back here.

Consider making ShaderModule compilation errors special #2119

• KG: do we want these as part of ErrorScopes? Little weird - happen on different timelines. Some discussion about understanding these happen on different timelines, but handle like "await Promise.all" even if things happen out-of-order.
• KN: last week - moving toward agreement on my proposal - we make it look as-if everything happens in order. Internally, deal with reordering/threading. Not make it special.
• MM: that's what I was going to propose.
• KG: resolved.
• KN: Corentin was the most invested in this.
• KR: I was second-most-invested. I think this will cause more problems in the API. This has proven problematic in WebGL - all result reporting had to wait for shader compilation to complete.
• KN: errors are delayed - suppose there are situations where apps want to deal with allocation errors. Validation errors - don't think programmatically handling those. Another issue with separating out validation errors. Think it's OK if they're delayed.
• KG: worth considering - we do have ErrorScopes. You could contract the error scope, not include shader module compilation. Want to know about OOMs - tightly wrap those with their own ErrorScope. Don't have the problem you do in GL because we have ErrorScopes - think you need to just take care.
• MM: sounds like the behavior if we didn't do the fixup - start ErrorScope, compile, do something erroneous, ask for the error - proposal from Ken is that the second thing erroneous should make the error happen. What if the second thing is correct?
• KR: it will complete.
• Discussion about this. Main proposal - these aren't strictly ordered with respect to other errors in that ErrorScope.
• Discussion about behavior for correct vs. incorrect programs.
• KG:** if you want things to end up differently we need an actual proposal for this**.

(stretch) Should objects have pointers back to their parents? #1497

• (out of time)

Agenda for next meeting

• KG: meet APAC time next week. If you're on vacation, enjoy your vacation!
• Specify that texture_external sampling functions clamp coords to [0, 1] #2766