Skip to content

Minutes 2019 01 07

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

GPU Web 2019-01-07

Chair: Corentin

Scribe: Ken

Location: Google Meet

TL;DR

  • Status updates on shading languages:
    • Google
      • Completing the WebGPU env spec for SPIR-V, updating spirv-val for it
      • Filing bugs against WHLSL
      • Looked into small-step semantic using the K framework.
    • Apple:
      • Working on implementing WebGPU in Safari between a flag
      • Reimplementing the WHLSL compiler in C++
      • Updating the WHLSL spec with more validation rules for uniform control flow
  • For the MVP we are likely to choose to either have browser advertise what shading language they accepts, or accepts both. Can reach consensus during the MVP period.
  • Need a basic test suite before we advertise experimental flags that enable WebGPU
  • At the F2F we should have discussions around small step semantics and the memory model.
  • For WHLSL compatibility and real-world use cases come before making a better SPIRV-translator. Google could possible help with the WHLSL->SPIRV backend.

Tentative agenda

  • Shading language starting with status update
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
    • Robin Morisset
  • Google
    • Austin Eng
    • Corentin Wallez
    • Dan Sinclair
    • David Neto
    • Kai Ninomiya
    • Ken Russell
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
  • Joshua Groves
  • Mehmet Oguz Derin

Administrative items

  • CW: Happy new year!
  • CW: Register for the F2F
  • DJ: no progress on forming WG. What was next step? Have to check previous minutes.
    • CW: we can talk about organizational aspects at F2F
    • DJ: will create a charter where WG will take finished specs from CG, etc. Will look into payments group to see how they do it.

Shading language status updates

  • DN: Updated WebGPU env spec for SPIR-V
    • MR 8: Reduced TBDs by educated guesses of what WebGPU will support. Spawned:
      • Gpuweb issue 162: Support "uniform texel buffer" and "storage texel buffer" ?
      • Gpuweb issue 163: What image formats are supported? What sampling options?
      • WHLSL issue 292: Identifier length limits (token length limits). (Really a testing issue)
    • MR 10: Adapted Vulkan data layout rules for uniform buffer object, storage buffer
      • Assumes “relaxed block layout” is available
      • This has historically evolved over time. This is an area where there are lots of bugs in drivers. Even discussed internally about a vendor whose GL drivers still have bugs in this area. Boring and mechanical, but still needs to be nailed down. From DXC work, have heard desire for more relaxed layout rules for vectors, etc.
      • Lots of open holes for defining shader interface. E.g. interface between vertex / pixel shaders, which also overlaps the API side. Maybe I should put something down so we can discuss?
  • DN: Tooling for SPIR-V
    • Progress on validation specific to WebGPU: list
      • Still need to update for these latest editorial changes
    • WIP: Adding spirv-opt recipe to downgrade a Vulkan module to WebGPU
  • DN: FP had filed a bug against the env spec about adding small-step semantics. There’s something called the K framework; seems feasible. The small-step semantics for WHLSL have something separable, which is: can separate actions of memory and what to do in edge/undefined cases. Can have separate discussion about undefined behavior. Could refactor our discussions in this area.
    • DJ: did you look at the WASM spec? What’s more similar to SPIR-V?
    • DN: the framework is, how do you define small-step semantics. Apple used OTT for WHLSL. K framework has nice side-effect that it provides an executable for the shader, if you can set up the surrounding environment with the data. Lots of other things you ultimately need to add, like concurrency. That’d be the direction I’d prefer to go.
    • CW: would the K framework support multithreading?
    • DN: haven’t seen that.
    • RM (Apple): K framework is great. FP was asking for more precise semantics. Wasn’t expecting something too precise though.
  • CW: we do have other updates like fuzzing for spirv-cross, etc., but not too relevant to this group.
  • MM: spent last couple weeks working on an impl of WebGPU that we would be interested in shipping behind a flag in the next Safari Tech Preview. This means: (1) an impl of the API itself, and WHLSL->Metal compiler. Our goal is to be able to show some nontrivial graphics with those things very soon.
    • DJ: that’s almost a second implementation of WHLSL. It’s not the ref impl in JS; Myles is rewriting it.
    • MM: I’ve been reimplementing the compiler in C++ and making it faster.
  • RM: working more on the spec. Trying to clarify validation rules. Talk more about uniform issue. Want to discuss uniformity with you. There are places where it’s defined that some binding be dynamically uniform, or there’s undefined behavior. Want to avoid UB at runtime by statically inferring where it’d be dynamically uniform or not.
  • MM: also have tabled the backwards compatibility with HLSL until we can get an implementation out there.
    • DM: will you bring something to show at the F2F?
    • MM: we would like to.

Shading languages

  • CW: seems both the WHLSL and SPIR-V camps are working on the sticking points for each other.
  • CW: Should we discuss at the F2F? What should be the deliverables by then?
  • MM: haven’t had a coherent story about what the CG is going to pursue. Should try to have a story for this.
    • Meaning: four possible outcomes:
      1. Browser accepts WHLSL
      1. Browser accepts some form of SPIR-V
      1. Browser advertises what it accepts
      1. Browser accepts both
    • Should come to some agreement about not necessarily what is best but what we’re going to aim for.
    • Both Google and Apple are starting to become close to shipping this, and it would be a shame if we didn’t figure out what the story is.
  • CW: on our side I don’t think we’re close to shipping. There’ll be an initial impl, but later, making everything work. The first time we ship WebGPU we are guaranteeing it’ll break. The MVP can be broken between that and the first version. Also, shading language and API side have very little intersection. (In Dawn, there are ~5 files out of hundreds that care about the shading language.) Should try to reach consensus at the F2F.
  • MM: I’d like to bring up the historical example of the WebMetal impl we put into Safari ~2 years ago. Some people picked it up and made amazing examples. Just having it behind a flag will get people interested in it.
  • KR: The POR has been that the MVP won’t be a stable API.
  • MM: right. The MVP should be representative though of what we intend to ship.
  • KR: Is it a stake in the ground to put WHLSL behind a flag? “There are three users using it so we have to put it in the standard”
  • DJ: that would be a stupid argument for us to make. We just want to put something out behind a flag, and give something to users that they can actually start using. Not about forcing the working group in a particular direction.
  • CW: I think the shading language is less relevant to the MVP. Real (larger) content ported to it will be using transpilers. Won’t rewrite the whole shading language codebase on a non-standardized shading language. There will also be people who will just be trying things out. I’m not too worried about this.
  • KR: thanks for the reassurance.
  • DJ: given what you just said, that the decision on shading language isn’t something we have to make before shipping experimental flags, the choice is: option (3) or (4). Apple won’t be in a position to turn something on that accepts spir-v for a while.
  • MM: we don’t have a spir-v compiler yet. Lot of opcodes, declarations, etc.
  • CW: there’s something open-source though. People can transpile from one to the other. We’ll already have SPIR-V to HLSL (for Dawn D3D12 backend); you could just WASM that and have it output WHLSL.
  • DJ: agreed.
  • MM: so we’ve narrowed it down to options (3) and (4) for the MVP?
  • DJ: not necessarily for the MVP but we’re saying it would be OK to ship something experimental that does (3) or (4). Also don’t want to give the opinion that (1) or (2) has been decided.
  • MM: guessing that we won’t have the ability to ship something that supports both in the near term.
  • DJ: also we haven’t investigated using the code in Dawn yet. We’re probably closer to being able to accept both in the short term because (1) it’s in JS and (2) we have a sort-of-done Metal and SPIR-V backend (?...)
  • MM: think it’s valuable to go over what would need to happen to both of the languages for the other to implement it.
  • CW: we went through that 2 months ago. The answer was SPIR-V needs to be more defined both in formal modeling, and no “spec” that links it to WebGPU per se. WHLSL needs to more appropriate for real-world use cases. That’s what we’ve been working toward on both sides. Our concerns are still the same.
  • DJ: are you asking, assuming we’re happy with these options, what do we actually need to do to implement?
  • MM: I’m asking the CG whether we should be focusing on HLSL compat, or an impl that runs on real devices?
  • DJ: MM said we’re hoping to ship an experiment behind a flag. Does anyone have a concern about it?
  • CW: I have concerns about the public visibility and hype factor of the WebKit blog posts. Everything posted there is considered truth by web developers.
  • DJ: news to me - I should post my flat earth article. :)
  • DJ: one reason we accelerated our impl plans was that you mentioned you were hoping to ship Dawn by the end of 2018.
  • CW: not ship, integrate.
  • DJ: you mentioned you were hoping to have an executable..
  • CW: I’d like us to agree on the last pieces of the API side at the F2F. Once done, we can put something that works in Chrome enough. Not before April/May.
  • KN: I think we should have some confidence that there’s reasonable similarity between our impls before there’s any publicity at all of these flags. At least a basic test suite, make sure the JS API behaves in similar ways, before it goes out in a dev preview even behind a flag. I don’t want a flag in Safari “Enable WebGPU” before there’s something published.
  • MM: that was what I mentioned. Even behind a flag, it’s a weak signal that people can start using it. I agree with you.
  • DJ: we have flags, they are available, they can turn it on. We won’t encourage anyone to turn it on (blog post, tweet) for now.
  • MM: the old WebMetal impl is still there behind the same flag we’re using.
  • DJ: we’ll remove that as soon as we encourage people to use WebGPU.
  • KN: 1) how big is the sea of flags people have to find this thing in?
  • DJ: not a very long list.
  • MM: 18 flags.
  • KN: that’s small. 2) we’ve talked with a lot of webgl developers that see the webgl 2.0 flag in safari and think safari has partial support for webgl 2.0, but it’s not complete at all. People take it as an indication that they can do stuff with it. It’s a big problem and we should avoid doing it again.
  • RC: think we should keep going and work out our differences. Should ship any MVPs behind a flag until it passes tests and we agree what it should be.
  • DM: think we’re mixing two stages here. Kai’s talking about MVP; multiple impls, test suite. Apple’s talking about a tech preview of stuff, not even MVP, like they did for WebMetal. Don’t think we should restrict technical previews, assuming we don’t advertise it as something ready to use.
  • DJ: we won’t use the existence of the tech preview as an excuse for not changing things.
  • CW: think we should discuss the CTS at the F2F, and planning availability of things in browsers.
  • DM: 2 mo. ago I advised a point of compatibility. If WHLSL is compatible with HLSL it gives motivation for developers to use it. If we’re not prioritizing that, then I don’t know whether WHLSL has that advantage or not. For me, compatibility is one of the stronger reasons to go with WHLSL. If that’s not there then I don’t see an advantage to converting to WHLSL instead of WebSPIR-V.
  • MM: I think you’re right. Our current plans were putting something behind feature flag in next Safari Tech Preview. If the timeline was longer we should do both. Think we should focus on compat in following Tech Preview. The only concern is how do we assign our resources.
  • DM: makes sense. Just wondering what criteria we’re going to use at the F2F to make this decision. I’ve been pushing for us to make a decision about whether HLSL compat is going to be a criterion or not.
  • MM: fair point.
  • CB: compat is a long-tail problem. There will continue to be improvements in compat probably for another decade. We definitely want to move toward consistency.
  • CW: any deliverables people would like for the F2F? we have 2 weeks in front of us.
  • MM: think we could make a pass to figure out what we need to show a triangle.
  • CW: was thinking shading language.
  • DN: tooling stuff we can keep progressing on, but prob not interesting to group. Could have that refactored discussion about how memory behaves, separate from small-step semantics inside the single thread. Don’t know if that’s useful F2F. Or, saw Apple taking steps to integrate a Vulkan memory model; could have discussions to facilitate that.
  • DJ: how impt is it to you that WHLSL ref impl can generate SPIR-V that actually runs in Vulkan?
  • DN: my default assumption is that when ingesting WHLSL, if it’s compatible with HLSL we’d pass it through dxc’s Vulkan backend.
  • MM: it’s not going to be the same language. Have its own spec, etc. Differing requirements. Not sure that strategy will work.
  • DN: I haven’t thought a ton about that path.
  • DJ: are you confident that WHLSL generate SPIR-V?
  • DN: yes.
  • MM: yes.
  • CB: have discussed making WHLSL frontend changes for this standards body.
  • CW: concerned that (dxc) executable will be too big to ship in a browser.
  • MM: Dean and i worked on a SPIR-V backend for WHLSL. Compiles >0 programs. Part of the ref impl. Doesn’t require dxc. Small enough that it could be shipped in a browser. Haven’t gotten it to production quality yet. Should we look at real-world use cases?
  • DN: I think compatibility is more important than completeness. Completeness has several options, including finishing the compiler you’ve started. Compiling to SPIR-V is something people know how to do, but accepting real-world HLSL illuminates lots of edge cases (as it did for Vulkan).
  • CW: since this group will standardize WHLSL it’ll have to have a SPIR-V translator anyway. Google’s preferred platforms run Vulkan so we need SPIR-V anyway. I agree with David that compatibility and real-world use cases come before a better SPIR-V translator.
  • MM: would you potentially be willing to help with a SPIR-V backend? (regardless of whether it’s in the browser or in the application)
  • DN: possibly yes.
  • MM: look forward to working with you.
  • CW: will need SPIR-V translator for the conformance suite.
  • DS: how are you releasing the compiler?
  • MM: currently as part of webkit, but easily separable. Only difficulty is that it’s built on top of the WTF library.

Agenda for next meeting

  • CW: think we should talk about buffer mapping. By end of F2F would really like to have a way to upload data to the GPU. It’s useful. :)
  • MM: has been some discussion on compressed texture format issue.
    • CW: let’s discuss next time.
  • CW: prepare agenda for F2F.
  • MM: anyone want to do ray tracing work?
    • CW: not yet.
    • CB: there’s likely to be some changes in how ray tracing works, as it comes to more vendors’ hardware.
  • DM: buffer views, that DN raised? Somebody needs to do the investigation of how we expose uniform and texel buffers.
    • CW: let’s put it on the agenda. These were features I was considering punting until after the MVP.
    • DM: that’s something that’s been available since D3D11. Seems fairly basic. But currently prioritizing something on implementation. Have a work-in-progress; don’t have triangles on the screen yet.
Clone this wiki locally