Skip to content

Minutes 2018 05 30

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

GPU Web 2018-05-30

Chair: Corentin

Scribe: Ken

Location: Google Hangout

Minutes from last meeting

TL;DR

  • Definition of validation rules for implicit barriers
    • Google’s proposal, similar to Mozilla’s
    • The document only outlines the error cases, when there is an error, the error mechanism discussed in other meetings takes over.
    • UAV barriers are mentioned as an opt-in in the document, could be a post-MVP feature.
  • Discussion of timeline
    • Google and Mozilla feel they could have MVP prototypes by EOY
    • Shipping in stable not before end of next year
  • Test suite language discussion
    • Suggestion to worry about the test suite only after we have MVP-shaped prototypes running in some browsers.
    • Would like more test coverage than the original WebGL CTS
    • Discussion of people using WebGPU directly in WASM vs. through a native API translation layer to WebGPU.
    • Concerns about test suite in WASM: hard to debug, arguably not producing a WASM API
    • Either the group will make a C header, or Google will make one and an emscriptem shim to go with it.

Tentative agenda

  • Formal definition of validation rules for implicit barriers
  • ISV / IHV feedback
  • Test suite language
  • Agenda for next meeting

Attendance

  • Apple
    • Myles C. Maxfield
  • Google
    • Corentin Wallez
    • James Darpinian
    • Kai Ninomiya
    • Ken Russell
    • Victor Miura
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Jeff Gilbert
    • Markus Siglreithmaier
  • Elviss Strazdiņš
  • Joshua Groves

Formal definition of validation rules for implicit barriers

  • CW: Google put in our proposal. Pretty similar to Mozilla’s. Not sure whether it’s exactly what Mozilla thought.
    • Basically: if you forget about UAV, then inside render passes, we ensure that each resource is either R/O or an output attachment.
    • If you add UAV, if rsrc is writable UAV, there’s a data race in our proposal, which is allowed.
    • You can only use a subresource as a writable or readable UAV at any time, and not in any other way.
    • Compute passes: suggest similar to Metal: as though there were automatic mem sync between dispatches. Feel it’s imp’t to provide some sort of knob so apps can decide not to have that and do sync themselves inside a compute pass. Maybe after MVP.
    • Assuming we don’t have copy passes: in cmd buf you have copy passes, compute passes, etc. Everything’s well ordered between two top-level commands. Impl is responsible for inserting correct memory sync. Validation rules will ensure we can’t in the same command copy from the same region we are copying to.
    • There’s more discussion of the cost of it. State tracking cost seems tractable.
    • Barriers at the top level will be hard. Competitive advantage of different implementations.
  • MM: Q1: there are usages for buffers and textures. Who dictates the points at which a resource can transition from one to the other?
    • CW: there’s no such call.
  • MM: so you look at how these resources are used / attached? and infer usage?
    • CW: exactly. At top of document there’s a list of usages, and what commands make use of that usage. SetVertexBuffer for example would require creation with VERTEX usage. Second part says: each of these buffers is used as a vertex buffer for the duration of that pass.
    • Usage validation would say, the only combination of usages allowed in this render pass are this and that.
    • MM: sounds great. What is the purpose of, at creation time of the resource, explicitly stating the allowed usages?
    • CW: that’s important for drivers. I wrote an answer for one of the issues (#37) with details about this. For example, in Intel Vulkan driver, for every usage there might be a call to “MakeSurface” which would increase the memory footprint of the texture. Used to allocate add’l planes controlling clear values for entire blocks of texture if renderable, multisampling info, Hi-Z depth values, etc. If the app doesn’t tell us how it intends to use a resource then we have to assume the worst case, allocating all of these planes and increasing memory footprint.
    • MM: not that arduous to say what the resource is allowed to be used as at creation time. But, before we bake it in stone, we should figure out the memory cost so we know what we’re losing in terms of flexibility.
  • CW: let’s look at second example, vertex buffers on Intel. They only look at the bottom 32 bits of the address in their vertex cache. If you have a >4 GB heap containing vertex buffers, they might alias. They have a small heap on which vertex buffers can be, and a larger heap where everything else can be. Here, for every buffer we’d have a 1 GB heap, because we declare the VERTEX usage on the buffers we create.
    • Even Metal declares the capabilities of textures (ShaderRead, RenderTarget, etc.).
    • CW: hope you’re convinced, but somewhat orthogonal to the proposal. If we assume every resource has every usage, the proposal still works.
  • MM: what happens if we detect something bad?
    • CW: the error handling mechanism takes over. Generate an error, entire command buffer is no-op’ed.
  • MM: is that true for both compute and render passes?
    • CW: yes.
    • MM: rules are different for them.
    • CW: doc describes conditions under which errors are generated. Then error handling takes over.
  • MM: LGTM.
  • RC: will need more time to review.
  • MM: sounds like: step 1, figure out without UAVs. Step 2, talk about UAVs?
  • CW: proposal actually talks about UAVs. If used as writable, can only use them as either writable, or read-only UAVs. Want to cast non-const ptr to const ptr.
    • Inside render pass, if using UAVs, any data race is a data race. An escape hatch. Because of GPUs’ tiling nature can’t have any synch.
    • MM: doesn’t look like there’s a usage for a UAV.
    • CW: it’s the STORAGE usage.
    • MM: if something is a UAV, it can’t be anything else in the same pass?
    • CW: for textures it’s more complex. Different sub-resources might be allowed, or not, depending on what we choose.
    • MM: data races this proposal discusses. Render passes and draw calls. Compute passes and a single dispatch. Relaxed compute passes (I want data races between different dispatches in the same compute pass). These are the only undefined behaviors in this proposal.
    • MM: so this proposal doesn’t have that relaxed compute pass concept?
    • CW: it does a bit, there’s an opt-out in the ComputePassDescriptor. ManualStorageBarrier. Could be post-MVP.
    • MM: think we should separate that out, needs more discussion. Aside from that, sounds fine.
  • JG: need more time to go over it.
  • RC: there’s a “cost of implicit barriers” at the end.
  • CW: I forgot to delete the to-do list.

ISV / IHV feedback

  • Not enough feedback, gather more and talk about it again?

Test suite language

  • CW: on the mailing list Google opined for C++. But people voiced concerns, so let’s discuss.
  • JG: maybe it’s not too early to talk about it, but feels a little on the early side. For now, think we should do prototypes and make tests in whatever language we want. As we bring things together, we should figure out how to standardize those tests. Say we started with a bunch of JS tests and then decided to switch to C++. We probably wouldn’t have made so many tests that we couldn’t just port them.
  • JG: I’m basically in favor of kicking this can down the road.
  • CW: what’s WebGPU’s timeline in your mind?
  • JG: would like to be working with in-browser prototypes before the end of the year.
  • CW: would that be MVP?
  • JG: yes
  • CW: what about maybe shipping WebGPU?
  • JG: error bars on that are pretty large. Seems like early next year
  • CW: early next year? Writing a test suite takes a long time.
    • Our timeline guesstimate is: MVP behind flag end of this year. End of next year, maybe V1 is poised to be shipping in stable browsers.
  • JG: that sounds like a reasonable guess. The error bars are pretty high. Would like to put it out sooner rather than later. Early-ish next year, I mean landing in Nightly/Dev and trying to get stable to ship it. Shipping in stable browsers, not before mid next year.
  • CW: WebGL test suite is huge. WebGL 1.0 test suite was insufficient. We really should not ship with a test suite that’s as small as WebGL 1.0.
  • JG: it worked well with WebGL.
  • MM: we shouldn’t compare the number of tests. We will know whether they’re sufficient or not.
  • CW: talking about coverage of the tests. The WebGL 1.0 test suite (the first one) did not cover WebGL functionality enough.
  • MM: that’s a different API written by different people.
  • JG: wouldn’t be too worried about it. Will take time. Should keep in mind how and when we’re going to write this. Will write it in concert with MVP and prototype. For the most part, no-one has an MVP-shaped prototype in browsers yet, so it’s not surprising we don’t have a standardized test suite. Would rather go work on trying to implement a prototype than try to hash out which specific language we want to write the test suite in.
  • CW: for Chrome, this means we’ll write whatever C header we like that’s close to WebGPU. Once we have the MVP in browsers and need a shared test suite, we can re-discuss. At that point, we might need to change our ANGLE-for-WebGPU to match that header.
  • MM: did we decide whether we want to make a native WebAssembly API?
  • JG: the WebAssembly committee hasn’t decided the decisions that would let us make that decision.
  • KN: there’s been no forward motion about a native WebAssembly API yet.
  • JG: sounds like they want to get the FFI between WASM and JS to run better right now.
  • CW: that’s similar to an FFI. Functions with number and type of arguments. In terms of ecosystem, think this group should provide Emscripten bindings from C to WebGPU so that you can link against it.
  • MM: it might be needed but we don’t need to specify it.
  • CW: I didn’t say specify. The group should produce it though.
  • KN: I think it’s essential for someone. Maybe not an essential product of this group. But somebody in this group is probably the one to do it.
  • JG: probably. But if we don’t do it then someone else probably will. The WebGL WG didn’t do that.
  • KN: but the API is OpenGL ES and already existed. That isn’t the case for WebGPU.
  • JG: don’t think this is that interesting to discuss.
  • MM: the WebGL WG didn’t produce the API.
  • KN: the OpenGL and GLES WGs did.
  • JG: think someone would probably write a Vulkan or Metal interface to WebGPU.
  • MM: that would be a great success story. There would be no native WebGPU library.
  • KN: that Vk/Metal compat layer does not need to be part of Emscripten. Doesn’t need to be the layer going out ot WebGPU. Think it makes the most sense to get WebGPU bindings into WASM and then have that shim live inside the WASM heap, instead of having it be part of the build toolchain.
  • MM: why would anyone want to go through this shim API?
  • CW: assume this Metal/Vk shim is written in C++ and uses WebGPU. You need a way to have it talk WebGPU through the Emscripten bindings. But you need a C FFI to talk to the thing, so you need a header. Also, there will probably be some people that don’t want a Vulkan shim, and won’t want to use Metal because of Objective-C. Maybe D3D12 shim will be the best. Anyway, some people will probably use WebGPU directly from the browser. If you have Unreal Engine, you “just” add a new backend which targets WebGPU.
  • MM: the argument isn’t that people should write their software with a particular architecture, just that it’s out of scope. CW and KN can write it but we don’t have to do it.
  • JG: think we can have a good ecosystem without this.
  • CW: depends on how much we want to support the ecosystem. for example Vk WG provides validation layers, compilers, etc. as part of their group. Think we should provide the basis of a good ecosystem.
  • MM: WebGL has a great ecosystem.
  • CW: not by design, by accident. If you look at Three.js, it’s a helper library Mr. doob did for himself which became super popular and a standard, not by design.
  • KR: Talked about the overall ecosystem. People ported GLES code to the Web with WASM and emscripten, that was because GLES already existed. If it is a contentious discussion maybe we should just go ahead and make both a header and NXT match it. If maybe this groups result is a JS API, if NXT is a C version of this API that is efficient and has validation it will have a space in the market of native APIs.
  • JG: think building the ecosystem is useful, just not sure this is useful.
  • KN: you and Myles have different disagreements.
  • JG: sounds like a good idea, please do it, I just don’t see it as a blocker.
  • RC: there’s a difference between building an ecosystem and when various people do some work and we want to test it on different browsers. If not for the ecosystem, fine, but we have to agree on a common language or way to write tests that we can run in different browsers easily. Kai’s way of a C header and WASM compilation can work. But it doesn’t provide a good debugging experience (unless you’re running NXT natively, outside the browser). But if you do find a problem with your JS bindings, it’s not a good enough way to debug that sort of issue.
  • MM: Apple’s position is simple: if we’re going to write a JS API then we should test it in JS.
  • CW: I don’t agree it’s purely a JS API. We define the API so that it’s efficient to have WASM host bindings for it. It’s also a WASM API. But the point is well understood.
  • RC: not saying the WASM thing won’t be good. It might get better. But today, right now, the debugging situation isn’t good enough.
  • CW: summary:
    • We roughly think we have a timeline.
    • We can’t write a test suite until we have things running in-browser, end-to-end.
    • So we should have a discussion about this again once we have things running in the browser. End of year?
      • JG: maybe 3 months from now.
    • There are concerns about test suite in WASM:
        1. It’s hard to debug
        1. It’s not written that we’re producing a WASM API
    • There are discussions about the C header
      • Either this group makes a C header for its own testing purposes, or:
      • This group doesn’t make a C header, and Google will make one, and an Emscripten shim that goes with it.
  • RC: will the Emscripten shim be more debuggable than the dEQP stuff that Kai showed?
    • CW: it’s an Emscripten shim. Translation of the C API to JS calls.
    • KN: will probably take a different form. The ES-to-GL conversion is currently done in JS. If you’re debugging C++ code, you have C++ on the stack, then Emscripten’s JS, then the browser. Hopefully the JS shim will disappear, simplifying things. Will have a different shape from WebGL.
  • CW: something we really need in the WASM is fast / incremental linking, instead of whole program linking every time. And proper debugging support (Mozilla probably already has this).
  • MM: don’t think you mentioned – keeping the existing JS tests but running them in a headless V8 that’s bound to your library.
  • CW: the concern with that is that the web-platform-tests have a lot of HTML files. Not sure Node can handle that without a full-fledged browser engine.
    • MM: we’re writing the test suite, so one way we could architect things would be to allow this use case.
  • RC: a lot of tests will be drawing stuff. What does headless mean?
  • MM: most tests render, then read back the framebuffer.
  • CW: many of these don’t even need a canvas. You can just render to a texture and then copy to a buffer and read from the buffer.
  • KN: from it not being a browser you don’t get e.g. canvases, but our tests should probably be written to not rely on that.
  • CW: Kai had an idea about using an intermediate language to generate both C++ and JS.
  • MM: now we have two problems. :D
  • MM: is there anything left to talk about on this topic?
    • CW: we’ll take Jeff’s suggestion and wait for 3 months.
  • MM: also starting on a WebGPU spec. I can’t put it anywhere b/c it doesn’t belong in WebKit and the CLA’s not done.
  • KN: should be able to put it in gpuweb?
  • CW: your lawyers might tell you not to do it, but the CLA doesn’t change anything about the spec. The spec license is unchanged. The CLA only covers additional code artifacts beyond the spec and test suite.
  • RC: what Corentin said is what our legal contact told us, too.
  • MM: OK. I’ll go as fast as I can on this.
  • KN: as a W3C group, this works like any other W3C spec. You don’t need any special approval to start on a spec.
  • CW: but we’re not Apple and not lawyers.

Agenda for next meeting

  • CW: we should talk about organization of the spec. Who does what, etc. is pretty loosely defined. Once we start writing a spec, maybe we should have a formal spec leader position and “other stuff”?
    • MM: in other W3C groups: there’s an editor or collection thereof in charge of the documents. Raise issues in weekly meetings, come to consensus, then formal resolution to add it to the spec. Editor’s job to do that. Editor can make changes that aren’t resolutions, but not big ones.
    • CW: can other non-editors make contributions?
    • MM: yes, but editors can reject.
    • RC: and all contributions are made by pull request anyway?
    • MM: yes, anyone can make a PR. In CSS, more people than just the editor can actually push to the repository.
  • RC: if we don’t have conformance tests, then we should at least have some samples. “Hello World, WebGPU”.
    • CW: right now the sketch IDL doesn’t compile. But we should strive to reach that state and get the same example working on 2 different browsers.
  • MM: seems futile to make a spec before we have working implementations and a test suite.
  • JG: think things are still in flux, so think carrying any large test suite along is a lot to bring along.
  • CW: seems we really don’t have much to talk about. Things are less in flux than a year ago. Too much in flux though. Cancel next week’s meeting, give people time to code stuff?
    • Agreed to cancel next week’s meeting.
Clone this wiki locally