Minutes 2021 12 08

GPU Web 2021-12-08

Chair: Corentin

Scribe: Austin / Ken

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
• GPUAdapter.name considered harmful #2191
• (stretch) Expose blocking operations on workers #2217
• (socialize) Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388
• Agenda for next meeting

This week's 5 issues to try and resolve offline:

• Can value of visibility attribute in GPUBindGroupLayoutBinding be NONE ? #405
• Binding to zero-sized range of a buffer #686
• Case for empty usages #1001
• Separate loadOp and clear values #2386
• Make depth/stencil load and store ops optional for read only #2387

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Loko Kung
• Intel
  • Yunchao He
• Mozilla
  • Kelsey Gilbert
• Brendan Duncan
• Mehmet Oguz Derin

CTS updates

• KN: Not a lot of updates here. WGSL testing continues though. Next couple of weeks, I will look through the tasks to do and make sure they are tracked somewhere.
• MM: Did you have a spreadsheet that describes areas that have or need tests?
• KN: Yes, but it hasn’t been updated in a while. Need to either update it or put the information somewhere else.
• MM: Okay. We are quickly approaching the time when we can start running tests.
• KN: We do have some test issues in the Dawn bug tracker, mostly because it’s easier for our planning internally. I can send you that any time though.
• MM: I don’t plan on auditing everything, but I am looking to see where we are missing coverage so I can start looking there.
• KN: Yea, there’s a lot of places missing coverage; I’ll be finding those places.

GPUAdapter.name considered harmful #2191

• MM: Lot of discussion on Github what people use this string for in other APIs. Use cases seem to be fairly varied. The thesis I’d like to state is:
  The relevant question isn’t do people use the string. It is “must people use this string in WebGPU?”
• MM: For questions of fast or not, we can have other solutions like performance buckets. Not necessary for that goal. It’s even misleading because if authors don’t know every device, things won’t be handled.
• MM: For bugs in browsers or implementations, we don’t know what the bugs will be since we haven’t shipped yet. We can fix them. This proposal is a fallback. We don’t know we need it.
• MM: Exposing this information as a string, certainly, but even in general, we don’t know if it is necessary, so we shouldn’t have it. If it does become important after we have shipped, then we can discuss this again. And when we discuss it again, we should include privacy groups and the TAG.
• BJ: I left a comment addressing (bugs) specifically. You’re correct we haven’t shipped yet, but I think we can confidently say that there will be driver bugs. To say that we haven’t shipped and we can’t know, is a bit of misdirection. I don’t think that’s a valid argument for avoiding exposing information to help mitigate those things. Whether that’s a string or something else is a good conversation to have. But I don’t buy the “we haven’t released, so we can’t know” argument.
• MM: Our API isn’t special - everything has bugs. Browsers are trying to reduce UA strings, so we shouldn’t add a new one.
• KG: Our API is special. The unique thing is that we run on many, many pieces of hardware with many issues. It’s a broader problem space than most web platform technologies.
• CW: I’ve heard reasons about why it’s not needed, we’re not special, etc. But what’s the concern about what might happen if information about the adapter is exposed.
• MM: There are two that jump to mind immediately: fingerprinting and we don’t want websites to forget to check for a particular device. Don’t want a website to assume only NVIDIA is fast, and forget others. Don’t want websites to have a custom shader for a particular device and not on others.
• CW: At least the fingerprinting concern is something that is a browser policy. It mostly disappears if browsers are allowed to not expose anything, and that’s spec compliant. This way the browser is in control of how much information is available. The concern is more about websites making the wrong decision because they hardcode something like “NVIDIA”?
• MM: The fingerprinting concern isn’t solved by saying some UAs can return no information, because it’s misleading. If dominant browsers expose things like driver versions, then developer will assume they can rely on it.
• KG: I’m curious as what you see as the difference between WebGPU and WebGL where we have a similar situation and everything works OK. Not saying it couldn’t be better and I’m actively trying to improve it. We have the same systems and pressure today, and we have handled it well. Curious if you think this will be different in the future.
• MM: It’s not good in WebGL either; most uses are for fingerprinting. That’s a problem. It is our view that WebGPU should be a “better” API in roughly every regard, so therefore, we expect that in the future, a new person making a website would be more likely to pick WebGPU than WebGL, and more websites will use WebGPU.
• KG: Can I ask if you could answer the question about how you think the pressure will change. I agree that we can and should be better. One of your points is that you don’t want to be in a position where you feel compelled to implement something like this. And I know that in your implementation you expose the string because you have to. But the second half of that is you say it’s an “Apple GPU”. And I want to know the degree of those problems, and how that might change in the future that you might be compelled to include something like driver version.
• MM: The first question probably is better for Dean. The second I probably can’t answer since I can’t talk about future products.
• CW: Today in WebGL, you can fake information and nothing “bad” happens. It doesn’t completely break web compat.
• KG: I know this because I recently shipped changes to the string.
• CW: Other proposals for WebGPU that return nullable information maybe are a concern because the type is different. That would make sense. But if it’s just a string, if it changes, it doesn’t break web content.
• MM: What about performance?
• KG: I think that’s an interesting one. I do not want to in FF to expose the true adapter name and info, etc. I do want to expose that there are different buckets of information. People can identify that bucket and respond to it. You don’t need to convince me that we need something more than that.
• MM: I think that would be an improvement. I think we should go that direction after we have shipped and it becomes clear we need it.
• KG: Those of us with more experience in WebGL are saying that we need to indeed have this information.
• KG: Originally in WebGL, I was in your shoes, fighting against exposing this information. And I was convinced by the need for applications to ship same-day updates in their products to be reliable. It improves the offer of the platform we’re exposing if we give people these hints.
• MM: I’m willing to be convinced that it’s impossible to write an interesting 3D graphics application using WebGPU without the vendor string. In order to do that, we need a WebGPU that is shipped.
• CW: We have the closest proxy to that which is a WebGL that is shipped which runs on billions of devices. Sure, we can ship a first version and come back and be like. Ah we need this information. But, we know we already need it. We already have experience with the closest thing possible which is WebGL.
• BJ: WebGPU and WebGL are different APIs with different characteristics. But it’s difficult anything in the delta between those APIs that actively mitigates the issues that we have been seeing that require some of this information for WebGL. If we could look at the differences and say: oh compute shaders solve this! then I would agree that let’s ship and wait and see, but we know that such a mitigation does not exist.
• KR: Concrete feedback from WebGL have already reported reasons that they need this information for applications shipping to millions of users. A more productive conversation would be to discuss how to expose the information, and in what way. I would suggest not to expose driver version though - we haven’t ever needed that in WebGL.
• BJ: Earlier we were saying to bring in PING [w3c privacy interest group] and others into the discussion. I agree, and think we should get them involved. But I don’t think we need to ship first.
• MM: There are people using WebGPU today; are any using the adapter name?
• CW: It just says “Default” today.
• KN: That’s not useful information right now. No one ships WebGPU to millions of devices.
• CW: One more data point is that we’re looking to have Google Meet run on WebGPU. There’s the whole performance discussion, etc. But what’s really scary to them is what happens if they ship, and then there’s a device somewhere, and it doesn’t work. It’s a huge issue if users just can’t use the product, and you can’t know how to fix it or workaround it. Yes, we need to improve on just a plain string, but experience shows you can’t ship something without being prepared to do targeted workarounds.

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

• #1483: Editorial
  • KN: I think this is essentially done. Already marked as Needs Spec
  • KN: There’s the question of if we add sRGB-linear? Should probably be v1.
  • CW: That can be a separate issue.
  • KN: Already exists.
• #1497: Close
  • MM: As convenience?
  • KN: Yes, and it would help a lot probably for middleware tools, debugging applications, etc. I don’t think there’s a big cost, so I think it’s worth considering.
  • MM: Can’t a tool implement this themselves with one line of code?
  • KN: They would need to override all the create functions.
  • KN: Not like an engine. A tool that takes the texture object and does something on it - like a library. They can take the texture and then get the device from it.
  • CW: Middleware will probably just take the device in. Suggesting to close.
  • KN: The descriptor probably needs the descriptor more than the device - which is the next issue.
• #1498: To be discussed for v1
  • CW: Middleware argument is more compelling
  • MM: We already have stuff in the spec that puts the descriptor in an internal slot.
  • CW: If people don’t mind, I’d like to keep this for V1. Seems useful for buffers, reflecting sizes, usages, etc.
  • MM: Also another argument which is the value exposed wouldn’t be whatever dictionary they passed it. It would be roundtripped through the implementation. It would be a way for the developer to know what it actually got.
  • CW: Ok so keep for V1 discussion.
• #1548 - to be resolved for v1
  • toDataURL behavior for CanvasContext
• #1629 - keep for v1
  • KN: Prevents applications from needing to handle device loss at literally any point, and only at one point in time.
  • KN: Want to be sure applications only need to check at specific, well known points, instead of at other times.
  • BJ: Similar to error objects instead of tons of exceptions.
  • KN: I want to review this some more so we don’t have more error cases than we need.
• #1630 - to be discussed
• #1672 - moved to needs spec
  • MM: We should do it.
• Next time start at 1842

Expose blocking operations on workers #2217

• KN: Can we bump this up from stretch? We keep delaying it, but I have people actively asking for updates.
• KN: Lot of apps would benefit from being able to do things synchronously. Mapping comes up most often. Obviously we don’t want this on the main thread. On Workers, certain sync operations are allowed that aren’t allowed on the main thread. There is some argument that this shouldn’t be the case.
  We’ve had a lot of customer requests for this particular thing, because it’s hard to be unable to readback data synchronously. Asynchronous behavior conflicts with the programming model of many things.
  We can expose sync operations just on workers. They don’t block indefinitely, it’s for a finite amount of time. There are other relatively fast synchronous things you can do on workers, like network requests or storage APIs.
• CW: There’s synchronous XHR. So we could have mapSync and waitForSubmittedWorkDone
• MM: Sorry, I don’t think I’m ready to discuss this. We don’t want indefinite, but i don’t think that’s what you’re proposing.
• KN: Other APIs don’t have synchronous versions of APIs that can take potentially forever. Everything should be completed eventually. Mapping is most important, second one would be onSubmittedWorkDone. Third would be popErrorScope. I don’t think we want popErrorScope.
• MM: I’ll discuss with relevant people.
• RC: We just also need to make sure they handle errors correctly if the device is lost.

(socialize) Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388

• MM: This is mostly a description of a problem, and I also wrote a proposed solution. But it’s mostly the problem I wanted to discuss.
• MM: Problem is that the API is designed around a discrete graphics card, specifically for buffer uploads and downloads. To use the API on a non-discrete cards, extra copies and allocations are required. It would be cool if we had an API that didn’t require this, but instead allowed fewer copies. I made a proposal about perhaps a reasonable way to solve this.
• MM: General thought is that I don’t think we want to be in a world where we support this later because then we go from two to three ways to upload into a buffer. It’s scary to have the one that works will on UMA devices is optionally supported. It would mean the default that works everywhere would work poorly on 50% of device vendors.
• CW: How many buffer uploads do you see can take an optimized path?
  mappedAtCreation is already designed to be optimal on UMA.
  Right now WebGPU has an ownership transfer mechanism for buffer mapping. You transfer whole ownership, not ranges.
• MM: Trying to solve the problem such that you still need to wait for a Promise to resolve, and then you can write to it.
• MM: Imagining something like a system where data is flowing back and forth to the GPU every frame
• CW: With triple buffering of the data?
• MM: yea
• BJ: At that point, isn’t the web app taking over the work that the UA could be doing for them.
• MM: We have two ways of uploading data. one is buffer mapping. the other is writeBuffer. writeBuffer just makes it work. The reason that that isn’t great on UMA is because that API works when the buffer is busy. But if the buffer is busy, then the data needs to be put in an intermediate buffer. That’s required, even on UMA.
• CW: DM wants to optimize writeBuffer to write directly into the buffer if the range is not in use. It seems the main concern is that if it’s optional feature, people will forget about it.
• MM: In the proposal I made, I think the changes are fairly small. They’re adding queue arguments in one place and relaxing a restriction. I think because it’s small enough, we can discuss it sooner. That coupled with the optional nature makes it attractive to do now.
• CW: I would like to find a solution that works for UMA as well. The problem is there’s lots of combinations of things to consider - and all of these need to look the same from JS side. I think we should have this conversation, but I don’t know how tractable it is going to be.
• MM: I understand the complexity, but I don’t think I agree with the adjective “insane”.
• BJ: Clarification: does the proposal try to provide a unified way of UMA vs discrete buffers. or does it ask you to do separate things?
• MM: It has no observable difference for UMA.

texture_2d_depth for loading depth values might be unnecessary? #2094

Agenda for next meeting

• Resolve offline:
  • Limit for the maximum buffer size #1371