Minutes 2021 11 17

GPU Web 2021-11-17

Chair: CW

Scribe: AE

Location: Google Meet

Tentative agenda

• CTS updates
• Milestone triage (timebox 15m) #2073 (currently triaging V1 issues, start at #1001)
• texture_2d_depth for loading depth values might be unnecessary? #2094
• Texture view reinterpretation between srgb and non-srgb #168 (comment)
• Extension documents #2301
• GPUAdapter.name considered harmful #2191
• (stretch) Refactor descriptors for attachment load/store/read-only #2215
• (stretch) Expose blocking operations on workers #2217
• (stretch) Binding to zero-sized range of a buffer #686
• Agenda for next meeting

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Ben Clayton
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Loko Kung
• Intel
  • Yunchao He
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jeff Gilbert
• Jeremy Sachs
• Mehmet Oguz Derin
• Rob Conde

CTS updates

• KN: Tons of shader testing going on. Will ramp up other testing soon-ish. Development has been relatively slow recently.
• CW: ASTC and ETC2 formats relanded, so that’s good.

Milestone triage (timebox 15m) #2073 (currently triaging V1 issues, start at #1001)

• CW: Allowing fragDepth to be written if depthWriteEnabled is false
  • KN: Needs further investigation?
  • CW: Solve for v1 or blanket disallow?
  • MM: Is it observable the value written?
  • CW: DM says it may be observable with the late Z test.
  • KN: That requires and investigation for v1 then. It feels like one of those bits that we don’t know is useful, but someone probably wants it to work.
  • MM: Whether or not the driver is using late or early z is unobservable from a semantic point of view.
  • CW: Semantically, I think the driver always looks like late z. If you change fragDepth, it could change to be behind the current depth buffer.
  • KN: Can only allow writing fragDepth when depthWriteEnabled=false if drivers behave consistently with regard to the late depth test.
  • CW: Ok, we need a test to verify what happens and check specifications.
  • MM: I don’t think it’s worth it.
• #1211 Implementations allowed to crush DOMString to ASCII?
  • MM: For labels? I think you should be guaranteed to get the same thing.
  • CW: I agree, but not sure we can guarantee the backends can preserve the bytes.
  • JG: This issue is about when passing it down to the driver. Seems like more of an implementation decision.
  • MM: Right, it’s not testable.
  • CW: Okay let’s close.
• #1225 - editorial
• #1231 Open questions about swap chain formats
  • CW: We should keep and resolve this for v1
• #1250 Sparse color attachments
  • KN: I don’t think this is that important for v1
  • MM: Is this something that makes sense to add in later? I don’t see much cost to doing it now. It would naturally just slide right in.
  • KN: I don’t think we’ve tried to implement it. Don’t know if it’s possible without repacking. Implementation might not be trivial.
  • CW: I think I tried it and it worked, but I would need to double check.
  • CW: OK - I guess Chromium can volunteer to test this and see if it works on various target APIs.
• #1266 Post-comparison-filterable depth formats
  • KN: The Vulkan spec is iffy about what happens when you filter with comparison samplers. I think this just needs specification then.
  • JG: Part of the bigger question of how to specify filtering - which we can try to do partially. Lots of implementation-defined choices.
  • Move to needs spec.
• #1311 privacy implications of shader / pipeline caching
  • CW: Should we write in the spec that browsers should do per-origin caching?
  • KN: Yes, I think we should mention it. It doesn’t have to be a lot.
  • MM: We should say “should”. Not sure how we’ll do that in Metal because the compiler is a global daemon.
• next time start at #1358

texture_2d_depth for loading depth values might be unnecessary? #2094

• Postponed.

Texture view reinterpretation between srgb and non-srgb #168 (comment)

• CW: Wanted feedback on when reinterpretation is actually useful. Jasper came back with a clear situation. Long time ago, Intel also explained that allowing reinterpretation was a clear perf loss.
  Another thing is that Jasper said their experience in WebGL is that you can’t do it. Maybe we say that WebGPU has the same limitation for now.
• MM: Perf hit on Intel?
• JG: Texture compression.
• MM: Surprising because Metal doesn’t need flags for it which means that every RGBA8 texture is not compressed.
• KN: I’d suspect Metal found a way to workaround it. It is theoretically possible.
• JG: just the view or the resource?
• CW: The resource. There’s a compression plane, and when you use framebuffer compression you can use that plane. That plane could be allocated or allocated lazily if the format is reinterpretable. And it’s decompressed when needed.
• JG: I wonder how hard it would be to do this heuristic.
• KN: I think doing it ourselves would be hard.
• CW: Vulkan would need to reallocate a resource.
• JG: This would be a one-way thing. Reallocating is probably not that bad, and copying once also isn’t that bad. And then it’s slower after that point - tolerable?
• MM: Not slow on Intel though, it’s just as fast as it has to be. You’re not leaving perf on the table.
• CW: I have concerns because reallocation of resources is scary because it means we need to change the inside of bind groups, (KN: and render passes)
• CW: Maybe on Intel if the texture is only renderable and not sampleable, we could emulate the sRGB rendering by postfixing the shader with the sRGB transform. But then you couldn’t sample as sRGB
• JG: Probably a performance hit
• MM: And a correctness problem for sampling.
• CW: And sRGB blending wouldn’t work.
• JG: How old is this hardware?
• various: Gen 9, Skylake, 5 years old
• MM: if this is one set of cards from one vendor can we just say it gets a perf hit?
• JG: probably the single most common GPU
  • https://firefoxgraphics.github.io/telemetry/
  • 27.8% of all Firefox users are on IntelGen9
• CW: HD 630 and friends. the classic Intel GPU that everybody has
• CW: Getting complicated enough that I’d like to postpone.
• KN: Reminds me - we should make it possible to copy between non-sRGB and sRGB.
• MM: I can ask the Metal team how they do this, but I can’t promise anything.
• CW: Unless we have some groundbreaking way to workaround this, I would like to suggest to postpone.
• KN: A compatible format list would solve this too.
• MM: We still have concerns about the format list so +1 to what Corentin was saying.
• CW: Another possibility is bool allowSRGBFormatReinterpretation.
• MM: So in the eventuality of time we may have two booleans.
• JG: Maybe. I feel like the format list is the most robust.
• KN to write PR? KN wants to talk about format list more first.
  Also an issue about copying between sRGB and non-SRB formats.

Extension documents #2301

• CW: Normally this would have been editorial, but because this is the first extension document, we should agree on the process for that.
  Extensions that are being worked on or not meant to be exposed by browsers in normal web pages. Stuff not standardized - can still be in the repo in the extensions directory that show the idea and explain what changes.
• MM: There’s this great watermark you can add to .bs files that say this is not a real thing.
• JG: It would also be helpful to rename extensions → “draft extensions”
  Do we expect these to live for a decent amount of time before going into the main spec?
• KN: It depends. This is one <pipeline statistics> that we expect to leave indefinitely.
• CW: Probably both. Bindless we’ll probably iterate for a long time. Others, might be enabled by specific browser flags.
• JG: Weird to “do not implement” but then it’s enabled in all browsers with a flag.
• KN: Well I wrote “do not expose by default”.
• MM: We have an existence proof with timestamp extensions in Chrome. I think this would be a fine place for that.
• MM: Jeff, imagine some document for pipeline statistics / timestamps existed. if nothing about the contents of those documents changed, but it was in github.com/google, would you be more comfortable about that?
• JG: yea
• CW: Ok, what do we do if multiple browsers want to implement the same one?
• JG: If we wanted to put in FF, we would just link in documentation to the thing in Google that we’re trying to “standardize” on. Weird to put something in a Standardization repository that’s not actually official. A change of venue would make that easier.
• MM: I think that’s a reasonable perspective. I don’t necessarily agree, but think it’s reasonable to cater to that desire.
• CW: I think that’s why we need a split between the actual Standards group and the broader WebGPU community.
• JG: I don’t want to train developers to look at something that says “not real”, but developers think that well…. maybe it is actually real.
• KN: I think we can also just be clear about what “track” something is on. Standards track and unstable vs. never to be standardized.
• MM: Historically (90s) WebKit implemented a ton of CSS properties (not anymore!). They didn’t make it into any document. Some of them a ton of people started using, and then those did end up in the CSS working group. Some of them had a note that said this is bad, some of them did not.
• BJ: Sounds a lot like a Khronos extension pattern where you have an AMD or NV extension that eventually become KHR. But, given we try to avoid prefixes like that, I’d be interested to figure out how we would resolve some of the conflicts. If we had it hosted in a Google repo, and someone came up with an alternative.
• MM: There is a difference between what Vulkan does and what we do though. For Vk extensions, they just exist and you don’t need to launch with a special flag. Our non-standard extensions work differently. For Vk it’s reasonable to ask for NV_raytracing, but for our extensions, it’s not reasonable because you need to launch with a special flag.

GPUAdapter.name considered harmful #2191

• Also #2195
• MM:
• 1. Fingerprinting on the web is extremely common https://jonatron.github.io/webgl-fingerprinting/ shows that if you count page views, WebGL is used way more for fingerprinting than 3D graphics. We should try to improve this.
• 2. The fact that the standard says the contents of the string is undefined is not really acceptable because it means that any browser vendor can unilaterally start exposing more information. Why is anyone participating in standards? Trying to define what is expressible in Web technologies. Not expressing the contents is a standardization failure.
     It’s hard because who knows what the string will be. I want to name my device “Charlie”.
     If the contents come directly from MTLDevice.name, that would be a “non-starter” (from management).
• 3. This particular topic is quite difficult to discuss because the question isn’t “do people use this string”. They do. it is a fact. We’re trying to decide “must people use this string”? People are using it for all sorts of purposes, and we can satisfy those desires and usecases in other ways.
     WebGPU is different than other APIs in three ways:
  • 1. There is a thick layer between the driver and web app. We are the man in the middle to improve the situation for websites.
  • 2. We are built on more modern drivers than WebGL was built on.
  • 3. We haven’t shipped yet. If someone found a bug, therefore you must expose the name string, the “therefore” clause is false because we haven’t shipped yet. We can fix the bug
• 4. In WebGPU, there hasn’t been a demonstrated need. In fact there can’t be a demonstrated need because we haven’t shipped yet. three.js does not use device name string. Babylon.js uses it in one case (not clear on it).
     If in the future there is a demonstrated need, we are willing to have that conversation.
     We’re talking about tradeoffs between developer empowerment and privacy. In order to have that conversation we need to involve the TAG and the Privacy Interest Working Group.
     If we don’t expose this string, and developers start fingerprinting the heck to reverse-engineer what the string would be, that’s an improvement. If developers start looking at NaNs or how long operations take, there are things we can do. We can change shader NaNs, we can quantize timing results. If we give away the device name string, game over. We’ve lost the keys to the kingdom.
• MOD: I agree with Myles' arguments; behavioral portability has been a stated and practiced priority (see subgroup discussion)
• CW: I think we all agree on 1. that fingerprinting is common and we should improve.
• 2. Strings undefined is fine. That happens in other places too. Like CSS. THe system has the font? you can see it. It doesn’t? you get something else. Yes, we can do better than WebGL that has whatever, and we can give guidance, but because it’s undefined doesn’t mean we shouldn’t have it.
• 3. Long list of why people use the string, and yes theoretically the browsers can try to do something.
     We also don’t want to get into an arms race if we teach developers to do fingerprinting and we fight to mitigate it.
• BJ: You said giving out the Metal name is a non-starter. I wanted to understand that, is it giving it out without user confirmation? Or is it that Apple’s position that that name will never be given out, period.
• MM: Two parts: \

1. I was hoping to not get into the discussion about “what if we hide it behind a prompt?”
   It’s a non-starter to give an unfiltered string to anyone who asks for it.

• CW: Would like feedback on #2195. This is the proposal of expose, and the browser chose how to expose. \

(stretch) Refactor descriptors for attachment load/store/read-only #2215

(stretch) Expose blocking operations on workers #2217

(stretch) Binding to zero-sized range of a buffer #686

Agenda for next meeting

• texture_2d_depth for loading depth values might be unnecessary? #2094
• importExternalTexture in WebCodecs spec w3c/webcodecs#412