Skip to content

Minutes 2018 11 05

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

GPU Web 2018-11-05

Chair: Corentin

Scribe: Ken!

Location: Google Meet

TL;DR

  • Ok to meet the VkPortability TSG in an IP-free zone at the Khronos F2F
  • Shading language:
    • The group agrees on high-level objectives around security, backing API support, etc. We also want to standardize WHLSL even if the browsers ingest SPIR-V
    • WHLSL decided to break compatibility when it made the parser simpler, could add complexity to be more compatible with HLSL
    • Both WHLSL and SPIR-V for WebGPU are fluid targets, WHLSL because it is still evolving, SPIRV because we don’t have the WebGPU execution environment
    • Will have recurring shading language meetings to force parties to do homework.
    • Current concerns about WHLSL: will it run on all hardware we support and will it run fast? What happens on language evolutions? Is it safe to implement in browsers? (most concerns about SPIRV were raised on the ML).
    • Meeting in 3 weeks will be about shading language.

Tentative agenda

  • Shading languages
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Filip Pizlo
    • Justin Fan
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Corentin Wallez
    • David Neto
    • James Darpinian
    • Kai Ninomiya
    • Ken Russell
    • Dan Sinclair
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Elviss Strazdiņš
  • Joshua Groves
  • Mehmet Oguz Derin

Admin

  • CW: Neil Krevett from Khronos reached out to see if WebGPU wants to meet with Vulkan Portability in an IP-free discussion at Khronos’ San Diego F2F in January.
    • We might be sharing part of SPIR-V ecosystem, would be good to share goals
    • Could share implementation strategies
    • WebGPU might be a VkPortability target
    • Khronos is coming from the direction where they see WebGPU as a VkPortability target, and the only true API is VkPortability
    • Are people interested in meeting with them at F2F?
    • On the side of the WebGL F2F
    • KN: would be useful
    • RC: as long as it’s IP Free, fine with going
    • CB: thought VkPortability was a WebGPU target
    • CW: may go in both directions. Moz looking at impl WebGPU on top of VkPortability.
    • KR: One thought was to use an hour of the WebGL F2F. Could have it Tuesday morning and then Travel to Google San Diego.
    • DM: VkPortability is Monday afternoon.
    • DJ: Happy using WebGL time to do this.
    • KR: Only time possible is Monday afternoon, unless we want to do something Tuesday afternoon.
    • DM: Not convinced we need all people. If Tuesday morning works for everyone except one-two people then we can meet.
    • KR: Tuesday morning is fine, or monday late afternoon. Don’t want to take too much of the WebGL F2F
    • DM: How about monday morning?
    • KN: Would be good because we’d have to break for lunch.
    • CW: AI to make a doodle (actually not)
    • RC: Need to have a room
    • KR: Both groups meet Monday afternoon.
    • CW: Sounds fine too, will ask.

Shading languages

  • DJ: question: should we have a summary of where we think we are? Maybe there are things we agree on that are forgotten.
  • CW: things we think we agree on:
    • Security model
    • A standardized HLSL would be a good thing for the ecosystem
    • MM: authors targeting WebGPU for new applications should be using WHLSL
    • CW: for apps that don’t have any existing shading language code
    • The shading language needs to be a compilation target for existing shading language codebases
    • CB: isn’t that a new requirement?
      • FP: that’s been our assumption all along developing WHLSL.
      • KN: don’t necessarily have to compile HLSL to WHLSL
      • JG: goal should be minimizing porting pain, not require completely rewriting shaders.
    • CW: We should target the language to support existing hardware and drivers. There is differing support in for example support for general pointers.
  • FP: think we have agreement on security model in coarse-grained terms, but haven’t hashed out whether we agree on specifics. For example: the semantics for each individual operation.
  • CW: fair point. But we agree that apps shouldn’t be able to read data that’s not theirs, but can’t prevent DoS, for example.
  • FP: agree
  • DJ: thanks, answers the question.
  • CW: how do we go about deciding (between SPIR-V and WHLSL as the shading language ingestion format)?
  • DJ: we’re talking about what the API should accept for WebGPUShadingModule constructor? Options are: SPIR-V with WebGPU environment, WHLSL, or both?
  • MM: another option: could be both (every browser is supposed to support both languages), or something like canPlayType() function for HTMLMediaElement.
  • JG: recommend against that one because it will cause fragmentation.
  • FP: important to understand what the options are before we choose one.
  • JG: fair
  • DM: existing WebGL users are more likely to go through SPIR-V path, where existing native users are more likely to go the HLSL path.
  • CW: that’s a bit qualitative. Could see people using ANGLE translator to convert GLSL to HLSL, for example.
  • JG: point is: the majority of content on the web today is more disposed to GLSL. Could use a shader translator, but it’s not super common.
  • FP: it’s more common to translate GLSL to SPIR-V. Could become common to translate GLSL to something isomorphic to SPIR-V. Today the SPIR-V translators exist so you might guess that’s the path most people would prefer, but we don’t have the data to know whether that’s what they want.
  • KN: there’s already a GLSL to HLSL translator in ANGLE that all the browsers are using.
  • DM: what I’m saying: if we accept SPIR-V then the current WebGL content producers will still have to convert. Native developers who use HLSL will also have to convert. If we use WHLSL then native developers will have less friction.
  • JD: that’s only true if WHLSL is a superset, and that’s not the case right now.
  • MM: we can discuss that. The only reason we’ve diverged from backward compatibility is because of changes we thought that were good for the web. But can revisit.
  • FP: in areas we’re not currently compatible, it was to keep the spec simpler. Not married to that path. Would be possible to add in features we think we want. For example, LL(*) parser, which would get you all of HLSL syntax.
  • DN: I think having WHLSL being compatible with HLSL is a good goal. Already will have pain for developers coming to this API.
  • CB: we’re open to changing HLSL to match the web’s requirements.
  • FP: we’ve been talking about taking a corpus of HLSL shaders and changing the design to make them work. We simply haven’t invested the time to do that yet.
  • CW: think Dan was looking at the WHLSL compiler and found that only few HLSL shaders compiled, but most failures were all the same thing.
  • DS: I ran it over the SPIR-V HLSL corpus, but it was mainly all the same parse error.
  • FP: could you give logs?
  • DS: can run it all again.
  • DN: could file a bug against the WHLSL repo with the data.
  • DS: will do.
  • DN: expect that the changes to make all shaders pass have no conflicts with making it work with the web.
  • MM: should we proceed under the direction that WHLSL changes in such a way that most HLSL shaders are valid?
  • FP: seems so. Not sure why we got hung up on making the spec simple. Happy to go for compatibility.
  • CW: seems to be the consensus, esp. if we want WHLSL to be able to influence HLSL.
  • DM: hard to reason about WHLSL. Were saying it would be safer than SPIR-V, now saying that it’ll be compatible with HLSL. How solid will the parsing be on WHLSL? It’s much simpler to parse and validate SPIR-V.
  • FP: this is the heart of the issue. IMO, SPIR-V doesn’t have a validation process that would satisfy web platform security.
  • CW: in the SPIR-V spec there are several places where it’s too flexible for WebGPU. Multiple execution modes, for example. If you look at SPIR-V in Vulkan, it describes valid usage of SPIR-V in Vulkan. It says that these are solved with a WebGPU environment spec. In the same way WHLSL is a fluid target, we don’t have a WebGPU environment spec yet. The onus is on us to produce that, and we are starting to work on it.
  • FP: WHLSL in its current form has complete and formal verbiage about security model. Things we’re talking about being fluid: syntax for this operation, etc. Syntax desugaring would be in early part of language; not changing semantics for loads, for example. Will keep changing WHLSL based on feedback, but not the core semantics.
  • DN: WHLSL is still incomplete. The memory model is ~10 lines and not adequate; will provide feedback. If you want to take Iteration 0 for WebGPU environment as the Vulkan env spec, we’ll keep iterating on it.
  • FP: this conversation would be easier if you’d produce the WebGPU environment spec. Think that you know what it’d look like and we have no idea. In order for this conversation to be meaningful you need to show us what this document looks like. It might be that in producing this document, one or more of us will have an a-ha moment.
  • DN: I agree with you!
  • DS: someone started today whose responsibility is to produce this document. Ramping up now.
  • CW: having a first draft of the WebGPU environment spec would be helpful. It might not be set in stone by WebGPU 1.0, but hope that we can produce something soon and add more details to it.
  • FP: it would be impossible for us to use SPIR-V without that document. Not promising that we can agree to SPIR-V with it, but definitely can’t without it.
  • DM: that makes sense. Apple has done amazing job at analyzing SPIR-V spec; thank you for the results.
  • CW: there are somethings that Apple noted that are probably SPIR-V spec bugs; please keep them coming. We’ll do the same on the WHLSL docs.
  • CW: we all have a lot of homework to do. Not going to solve the shading language issue today. How do we make progress?
  • JG: we have some unknowns. Everyone wants documents, everyone needs to do homework.
  • KN: think that if we produce this document, probably nobody is going to have an aha moment.
  • FP: think someone will capitulate eventually. Would homework have been more useful if we’d made one of the choices on the table. For example, if we use SPIR-V, we think we’d still want to use WHLSL as a blessed frontend language?
  • JG: we missed that as something we agreed upon.
  • FP: the homework that we’re taking isn’t a waste if we go for SPIR-V. Alternatively, the homework to be done on SPIR-V isn’t a waste because SPIR-V and WHLSL need to be isomorphic.
  • CW: maybe we should have separate API and shading language meetings. Need to discuss common security model, what we want from the memory model, requirements for SPIR-V or WHLSL bugs / enhancements. Would be good to have these in recurring fashion, to force each other to do the homework.
  • DJ: think this is a good idea.
  • MM: maybe we can start on this now? Would like to know: what would WHLSL have to produce to be the language that the API accepts? What would SPIR-V have to produce to make everyone agree that should be the ingestion format?
  • FP: maybe easier question is: we’ve said, we wouldn’t use SPIR-V unless it does this. What can we do for WHLSL?
  • DN: want to make sure memory models line up. From text: you’re assuming memory is coherent, and that’s not true for most GPUs. It’s true for x86 and HSA models, but not for ARM and GPUs in general. Want to make sure that promises WHLSL makes are implementable. Also, no sequentially consistent atomics on Vulkan. Not sure what Metal’s model is. Details like this.
  • DN: also: “optimizations should not be observable”. but everything I’ve seen in graphics is that fastmath is the norm. Reassociation, etc. These are contrary to that principle.
  • DN: little concern about pointer stuff. Will have to look: like slices, array references, etc. Think raw pointers are duplicate of that. My impression is that would like pointers to be removed from the language.
  • DN: having compilation preserve semantics is super important.
  • DN: I view a pointer to an object as a reference to a 1-element array, and if you model it as an array slice, you’re good to go.
  • FP: that’s exactly what a pointer is in WHLSL. An array slice with static size of 1. You’re right that if we removed that feature, you could use array slices where you would have used pointers now. There were some things that were syntactically uglier that way. There were thoughts that pointers in WHLSL were less safe; that’s not the case.
  • DN: so you can’t advance to something further along?
  • FP: correct
  • DN: OK, that makes me happier.
  • MM: you can use (*pointer) rather than pointer[0].
  • CW: WHLSL looks very much like a CPU language in some ways because of the “simple” memory model. David’s concern is, will it run on actual GPU hardware, and will it run fast if we put all of these constraints?
  • FP: think that the optimizations being observable is a bug. Need to be more nuanced. Math shouldn’t be able to produce any outcome, but reassociation should be allowed. For memory model, we’re strongly considering using SPIR-V memory model. That one allows undefined behavior in some situations; we would like this defined in a way that it wouldn’t allow escaping of the security model. Think SPIR-V is further along, but neither is perfect. If you can close that hole that would be ideal.
  • DN: think we’re both in the same place. A shader’s not the only thing running. There’s an invocation of the pipeline from the WebGPU context. That defines the allowable accesses. Anywhere where SPIR-V says “undefined behavior”, WebGPU spec should say “if this occurs, shader can do any execution, assuming it doesn’t violate the security perimeter”. If we get that wording correct, think that’s the implementable and high performance solution.
  • FP: that sounds like a credible direction.
  • CW: to go back to Q of using WHLSL at API level:
    • Upgrade path for the language. How does the language evolve? How do apps take advantage of new language features?
    • How easy and safe is it to implement the language in browsers?
  • DJ: regarding performance: almost at point where we can produce Metal and SPIR-V output from WHLSL. At that point we’ll know the performance hit. SPIR-V won’t be optimized in any sense, so would be interesting to know how well underlying drivers do on SPIR-V code. Maybe generator has to be smarter. This is all the reference implementation. It’s not fast but it is correct.
  • DJ: Apple would also like input from the community about what the SPIR-V workflow would be for their applications. People that are building existing tools have workflows. Haven’t tried using Three.js and those tools. Not sure how they can give us input without having anything to play with.
  • CW: this is why we want an MVP sooner rather than later.
  • DJ: existing sketch API takes an ArrayBuffer for input. Could change this to DOMString.
  • MM: Q about upgrade path: are you referencing a specific upgrade event in the past?
  • CW: in JS, everyone uses Babel and converts to ES2014. Lots of browsers out there. Everyone has a compilation step.
  • DJ: yes, but WebGPU is only on browsers that are on ES6.
  • CW: when we add templates, we need something that monomorphises the language back to the non-templated one.
  • FP: I hear you. Two thoughts: as a JavaScript VM person, I think use of Babel is because it results in code that still runs faster. Babel can be told to take shortcuts on impl of language. There’s more going on. Also, if we took SPIR-V, there would be people who want to use new SPIR-V and run on the old one. This works fine. If we have a language tightly defined enough then this might be the solution.
  • KN: SPIR-V only needs an upgrade if you add hardware features. WHLSL needs an upgrade if you add either hardware or language features, and we don’t add hardware features very often.
  • CW:
  • KR: One thing about WHLSL, nice analysis about the trapping behavior that happens when the code does something bad. With WHLSL being more implemented, would be worth benchmarking. Concerned about the perf in deep callgraphs / loops. Would like to have a better analysis.
  • MM: we’ve done this analysis. About half of GPUs found that trapping was faster; the other half, clamping was faster. Some impact on uniformity rules.
  • FP: I don’t think we should have either SPIRV or WHLSL mandate trapping behavior. If there are GPUs on which trapping is empirically faster, would like SPIR-V to allow trapping. Not required to implement this.
  • KR: Concerned about string processing being “inherently unsafe”. Like the approach of having the compiler in Javascript because it is sandbox. Need to think about implication of rewriting compiler in C++ and needs to be in a secure area to validate WHLSL in the GPU process.
  • FP: browsers have many text and binary inputs. We’re seeing more security issues in the binary input parts. There are emotions and feelings around text parsers being less secure but it’s not the case based on our data.
  • CW: people seem OK with a recurring shading language focused meeting. How about 3 weeks’ time, and hopefully we’ll have a draft WebGPU execution environment?
  • MM: is this instead of the webGPU call or in addition?
  • CW: thinking instead of, at first.
  • DJ: any time is OK with us. 3 weeks from now is Thanksgiving.
  • CW: let’s schedule it for 3 weeks.
  • DJ: do we agree that apple should document the security model and that Google should document the SPIR-V WebGPU execution model well in advance of the next meeting?
  • DN: yes. Will file an issue on the WHLSL repo.

Agenda for next meeting

  • December 3 will be the next shading language discussion
  • Push constants
  • Multisampling investigation from Intel
    • Has a proposal in-line
  • Other ideas?
  • JG: could go through pull requests after that
Clone this wiki locally