Skip to content

Minutes 2018 02 14

Jump to bottom
Corentin Wallez edited this page Jan 4, 2022 · 1 revision

GPU Web 2018-02-14

Chair: Corentin

Scribe: Ken

Location: Google Hangout

Minutes from last meeting

TL;DR

  • Sketch API proposal from Google: https://github.com/gpuweb/gpuweb/pull/47
    • Everyone has things they’d like to change but no concern for a sketch API.
    • Should take a look at https://w3ctag.github.io/design-principles/
    • Everyone to tap their WASM people on the shoulder to ask for guidelines on the shape of the API.
  • List of the big questions: summary issue by Dzmitry https://github.com/gpuweb/gpuweb/issues/48
  • Tack-on topic: Portability problem => Security problem?
    • Undefined behavior in native API means all bets are off and you could get data that’s not yours.
    • There are cases where UB is more controlled, like persistently mapped buffers.
    • StoreOp DONT_CARE isn’t as controlled depending on HW implementation.
    • Should be discussed on a case by case basis.

Tentative agenda

  • Sketch API
  • List the big questions
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
  • Google
    • Corentin Wallez
    • James Darpinian
    • John Kessenich
    • Ken Russell
    • Victor Miura
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
    • Markus Siglreithmaier
  • Yandex
    • Kirill Dmitrenko
  • Joshua Groves

Updates

  • Google
    • Worked on sketch API
    • Reached out to Google’s lawyers, said MSFT and AAPL had last-minute updates to the CLA, will review and get back to us. No red flag.
  • Mozilla
    • Continued work on getting graphics abstraction robust

Sketch API

  • Google made a cut-down version of an IDL that’s similar to NXT but certainly not identical. It’s in the pull request:
  • Comments so far have been relatively minor
  • JG: I like u32. Everyone knows what it means. The API is definitely coming out of NXT’s preferences, but I think it’s a good starting point. Would be happy to have it merged in so that we can continue talking about it.
  • DM: as long as we understand that it’s something we don’t all agree on, and as long as we don’t take it as the status quo going forward, fine with it as a starting point.
  • CW: the intent is definitely not to ship this, but to have a naive starting point.
  • DJ: haven’t had much chance to look at it. Myles was also out for 2 days. Expect to have lots of comments, but that doesn’t mean “no”. Understand it’s just a sketch. Think it’s fine to merge.
  • RC: will follow-up issues be issues then?
  • JG / CW: yes, and/or pull requests.
  • RC: fine with merging it as long as it’s easy to change in the future. Hope that future pull requests to remove it won’t be dismissed with “no, it’s in there already”. Have to be willing to change things.
  • CW: there’s already a bunch of things we want to change.
  • JG: want to change a lot of stuff already.
  • DJ: wasn’t on last week’s call but found doc from W3C on guidelines for designing Web APIs. Will add a link. If they were looking at this, one thing: there is an enum type in Web IDL and that would use strings rather than u32s for enum types. Relatively small things like this.
  • RC: didn’t run the sketch by Travis Leithead but did run the other issue CW put together the sampler API. He gave the same feedback as Dean about enums. Web has also been moving away from factory methods, rather prefer “new Type(device, …”). Also prefer dictionaries for creating things rather than objects.
  • CW: think we should come to consensus on the shape of the API, broad strokes, and then get the sketch to follow that. A change to the factory methods would change a lot of things in the file.
  • DJ: we’ve got something a little different from other APIs. May be able to go for something a bit more awkward because we’re targeting WebAssembly rather than just pure JS. Could put something on top to make it look like pure JS. Something we should discuss when we come to it. Also, no one knows what a WASM API should really look like.
  • CW: 1) should have different discussions about form vs. content of the API. Doesn’t matter the exact form as long as the content is the same. 2) hard for us to set a precedent for both WASM and JS APIs. Not really our goal. Maybe we should reach out to the WASM group and ask them for HOWTO / guidelines on how to design APIs that are efficient / isomorphic between WASM and JS. Or how to retrofit WASM on top of JS APIs.
  • KR: Doesn’t have to be a one-way street. In WebGL group we also have a TODO to make WebGL efficient. We should feel empowered to help design the structure.
  • CW: would rather the WASM group define the framework. So far we’ve been the one suggesting a shape. Think the WASM group should be consulting us and helping design the shape.
  • DM: we could point them at our sketch IDL and ask for advice.
  • JG: one of the rules we want to break is we don’t want to use strings for enums.
  • DM: why?
  • JG: string compares are more expensive than switch statements.
  • CW: string interning.
  • JG: still have to string compare.
  • KN: still have to do the string compare, during JIT time?
  • CW: point is that we should ask the folks who know the JIT to tell us the guidelines.
  • JG: they’re not the right ones to know our perf characteristics either. Have to work with them. Will ask Luke on Mozilla’s side.
  • CW: AI on our side: create a small document for the WASM working group saying what we want to do and what our requirements are. We’ve done this before but would be nice to have it written down.
  • JG: feel free to do that, but think it’ll be more productive to talk with Google’s WASM folks directly. Not sure we know enough about WASM to
  • KR: Agreed, we had a productive conversation with WASM folks in MTV. Talked about WebGL and made progress on the host bindings proposals and fast C bindings for C style API for WebGL. Would like to try one faster callout sequence for WebGL before formalizing WebGPU’s requirements.
  • JG: so, AIs: reach out to everyone that we want to reach out to?
  • CW: yes, everyone should talk with WebAssembly folks and get this onto their minds.
  • JG: they should all give us fairly similar feedback. Think it will be more efficient rather than trying to interface group-to-group.

List the big questions

  • JG: resource and heap allocation.
    • All 3 APIs now have ideas about creating heaps and then allocating objects in those heaps. They’re not all the same but they are similar. A big part of the heaps is: where and how do we allocate objects? Not like CPU side allocation like Vulkan side, but when we allocate a buffer, where does its backing store go.
    • Is this exposed at the API level? Do we have pools like D3D12? Different memory heaps / types like Vulkan? Metal uses memory locations?
  • CW: is it using some sharing mode?
  • JG: yes. Shared, managed, or private.
  • CW: another question: Myles suggested whether we have to specify what the resource is going to be used for, or not.
  • CW: the big memory barrier / multi-queue question.
    • DM: this one is formed of related questions.
    • DM: barriers: completely implicit? NXT’s way with destination state only? Or D3D12/Vulkan where you state both source and destination state? Will probably have 1 of these 3.
    • DM: with queues, the big question is whether to expose 1 or multiple. Metal has 1 and does implicit parallelization.
  • CW: whether virtual pipeline state subobjects can be created, or are they part of some other pipeline descriptor, or both.
  • JG: Vulkan has both. Often create much of this as part of the pipeline state, but can mark certain fields of the pipeline state as dynamic.
  • CW: In Vulkan you can take the scissor rect into the pipeline, or set it via command buffer. Unique to Vulkan where the state is part of the pipeline but can also set it dynamically.
  • JG: thought that was in other APis but could be wrong.
  • CW: render targets, tile control. Think everyone agrees that something like Metal renderpasses are necessary. Otherwise is really expensive to compile pipelines on Vulkan and Metal.
  • DM: currently can be inspired by two things: Metal 2 renderpasses, Vulkan with explicit tile control. Don’t know how to compile Metal 2 to Vulkan. Suggest multiple renderpasses.
  • CW: agree. Want to see when D3D12 has some tile control what it looks like. Or come up with some temporary solution to be revisited when D3D12 comes up with something.
  • DM: do we know whether D3D12 is actually going to come up with something in this area?
  • RC: D3D12 folks know this is a feature request, but they don’t have anything to announce yet.
  • DM: what’s the approximate timeframe?
  • RC: no timeframe. Can decide something but will have to revisit it later. Have to come up with an API that can be easily implemented on all of them. Also, avoiding least-common-denom effect as much as possible.
  • DM: knowing our constraints, think RC has the best chance of telling us what will be most compatible.
  • RC: if we express a preference of API shape, we can take it back to the D3D12 team and ask for feedback.
  • CW: for this, I’m suggesting that we start without tile control, and maybe once we have an MVP, we can figure out tile control.
  • CW: buffer mapping.
  • JG: data upload/download/migration.
  • CW: once we’ve solved all these questions, think we have a good start. Other questions like are textures linear or swizzled, queries, fences, etc.
    • This stuff is mostly independent.
  • KD: on JS side of things: API available from web workers?
  • JG: haven’t talked a lot about this but expect the API to be exposed there.
    • Still ground that we have to cover here. This is an area where we don’t have good prior art from WebGL.
  • KD: sub-questions too. Make buffers / textures transferable? Or even be able to issue draw commands from workers? To be able to build multithreaded apps.
  • JG: it’s almost a requirement for this class of API to be multithread capable.
  • KN: it was an early requirement that this API be multithread capable. Just haven’t brought it up in a while.
  • CW: it is a big question. Think we all have the same basic understanding that it’s needed.
  • JG: shading languages.
  • DM: they don’t seem to affect the design much. Just a question of whether we have an entry point for accepting SPIR-V / GLSL . Something we could decide 2 days before shipping.
  • JG: not quite trivial. Questions about resource binding to shaders. Can’t be a last minute decision. Shader compilation / caching another question.
  • CW: pipeline caching is another question.
  • CW: other questions from Microsoft / Apple?
  • RC: this list is pretty complete in my mind
  • DJ: list sounds good.
  • JG: web page integration / canvas integration. Stretch goal: WebXR integration.
  • RC: that goes into general integration with other DOM elements.
  • CW: that’s something we covered in Chicago. Mostly on the same page but need more detail.
  • CB: questions about what we change in the security realm with respect to WebGL.

Tack-on topic

  • CW: one big question: how much do you shield against undefined reads that come from memory which you own. This will be a question that comes up over and over again.
  • KN: there are a lot of questions there. Really don’t see how we can have portability problems without security problems. So many things you can do. For example: most of the operations in Vulkan that can give you old cache memory of your own can give you old cache memory of someone else’s. (I think.) Also: if you are able to read things from a cache that is old then you can figure out when cache eviction occurs, which is a very direct way to do side-channel attacks. Think it’ll be difficult to have undefined behavior without security issues.
  • JG: disagree somewhat; you can have undefined but still secure behavior.
  • CW: like robust buffer access, maybe.
  • JG: if you invalidate a framebuffer and don’t clear it, you might get data back from another process. May still be able to provide sufficient security while still leaving a little undefined behavior in for performance. Especially when it comes to things like parallel queue execution.
  • KN: aside from multiple queues, think that it’s difficult to leave in undefined behavior safely.
  • CW: undefined behavior in graphics APIs -> no guarantees. In Vulkan, “undefined” really means all bets are off. If you want to allow undefined behavior in Vulkan and make sure it’s still safe, you have to look at basically every hardware implementation out there and ensure it’s safe.
  • JG: ex: for data buffer uploads, can have shared memory between client and server (for out-of-process web gpu implementation). When you map / copy / read, you could have an API where you map for write, but then actually read from it. Undefined behavior, but contents of your own shared memory segment which your process wrote previously. Still secure.
  • DM: another issue: DONT_CARE for color attachments. We can make sure that the contents are either cleared, or previous contents that we rendered.
  • KN: we can’t send the DONT_CARE to the driver; can’t take its benefit.
  • CW: we could do a lazy clear in this case. Next time the attachment’s used, can clear if user didn’t.
  • KN: we can do that even if the application specified a clear.
  • JG: if you spec that the data’s cleared, you want it cleared to something user created. Don’t want raw invalidation, because not making it clear to our impl whether you’re going to use those buffers. If you were clearing to invalidate vs. clear to actually draw, it’s different.
    • Think there is room between portability and security.
  • CW: case by case basis. Our biggest worry: if we have explicit memory barriers and they aren’t really validated. While the application wrote the data, some metadata gets attached to the resource. Not clear whether came from the app’s memory heap. I’m mainly worried about unvalidated memory barriers. Think it’s a big security concern.
  • JG: think we can do this on a case by case basis. Most progress would be made by handling these during API design.
  • DM: nobody is arguing to use explicit memory barriers without validation or without robustness for them. Went to Vulkan WG to ask about this. Can’t assume that nothing will break if we mess up mem barriers. But if we don’t have explicitness then we won’t benefit from robustness later on.
  • CW: OK, but Vulkan 1.0 doesn’t have this, so we can’t rely on it.
  • DM: Kai: if we have an image, clear it, then issue DONT_CLEAR call to the driver -- you’re saying we can still get data from a different process as result?
  • KN: yes. That data could be fetched from a cache, and there are no guarantees to that cache’s contents?
  • KD: but do you have access to it from the API? Reading it from a shader, etc.?
  • CW: depends on the architecture and how the cache is implemented on the GPU. If the cache doesn’t distinguish between different virtual memory spaces then conceivably it could return data you should not see. These things are heavily undefined to let HW vendors do different things. If the driver’s behavior is undefined then we can’t rely on it.
  • JG: underlying APIs offer different ways to specify optimization opportunities. We’re going to want our applications to be able to do the same.
  • CW: one thing that would be OK is if a WebGPU app says DONT_CARE and we give it back cleared to black.
  • JG: if the data’s only known to your process then I don’t see why we have to clear it.
  • CW: because metal and d3d have no guarantees that the data actually belongs to your process. If it’s not spec’ed in the native API that DONT_CARE only gives you data you produced, we can’t use it.
  • JG: think this is something we should talk about when we get to it and not as a high-level discussion.

Agenda for next meeting

  • Go back to buffer mapping and re-discuss persistent mapping. Possible to do in a data-race-free way?
  • People with opinions about the sketch API can comment on the workspace or put up pull requests.
Clone this wiki locally