WGSL 2020 03 03
Clone this wiki locally
Scribe: 𐰆𐰍𐰔: Mehmet Oguz Derin
Location: Google Meet
- Meeting Time
- Design Principles (design and bijectivity)
- Comma operator / Continuing construct
- for() loop
- Other open issues
- Agenda for next meeting
- Meetings will be in the same time slot, Tuesdays at 2pm EDT.
- Dan Sinclair (Google)
- Myles Maxfield (Apple)
- Possible 3rd (Microsoft)
- Design Principles
- Entries from #586 are accepted; PR has been sent to update the README and Goals section.
- Discussion around what bijectivity means
- Need to be able to adapt to conversion to multiple shading languages.
- Want to try to preserve performance characteristics but there are trade offs
- Myles to send a PR to update the README with bijectivity notes
- Tag items in the bug tracker if you wish them to be discussed at the next meeting.
WIP, the list of all the people invited to the meeting. **In bold the people that have been seen in the meeting:**
- Dean Jackson
- Fil Pizlo
- Myles C. Maxfield
- Robin Morisset
- Dan Sinclair
- David Neto
- Kai Ninomiya
- Ryan Harrison
- Sarah Mashayekhi
- Yunchao He
- Narifumi Iwamoto
- Damyan Pepper
- Rafael Cintron
- Michael Dougherty
- Dzmitry Malyshau
- Jeff Gilbert
- Joshua Groves
- Mehmet Oguz Derin
- Timo de Kort
- Lukasz Pasek
- Tyler Larson
Latest specification: https://gpuweb.github.io/gpuweb/wgsl.html
- DJ: I thought it would be nice to start with introductions.
- DS: Wrote current spec of WGSL, wrote Tint impl
- SM: Worked on Tint impl worked on type check
- DN: Helped DS validate WGSL stuff
- RH: Help bring stuff together
- RM: Apple for the JS core team. I was working on WSL when that was the proposal.
- MM: Worked on WHLSL (WSL)
- DJ: (Not) Boss of Myles, temporary chair of WGSL group
- YH: Working on API, observer
- NI: From Intel
- RC: Work on WGPU WGSL on behalf of Microsoft
- DP: Also work on impl on Microsoft
- MD: HLSL dev lead
- DM: Work on Mozilla’s implementation, build shader stack for Mozilla’s engine
- JG: Also on Mozilla. Here to contribute.
- TdK: Enthusiast. Working with WGPU in Rust. Developer.
- DN: We’ve had some interactions on Twitter with people who want to provide input.
- We need a forum for when we tell people on twitter etc to “take it back to the committee”, so we’ll need a valid way to do that.
- DJ: Let’s try using github labels to mark things for the meeting agenda. To nominate an issue or PR for the meeting, add the “For Meeting” label.
- DJ: Deciding on timing is crucial.
- Doodle/Web App for picking a time: https://doodle.com/poll/24z9q49ednkgbqf5
- MM: Would like more input on the Doodle.
- DJ: It displays in your local time by default.
- DJ: This time looks good.
- MM: A concern that I have is if this timing is bad for YH then we won’t have any input from Intel
- YH: Maybe one hour earlier?
- DJ: I propose we stick with this time for a while unless...
Resolved: Meetings will be 11am PST each Tuesday.
- DJ: I think we should limit it to 2 or 3 editors to make it easier to manage
- DS: I have nominated myself as an editor.
- MM: I’d like to nominate myself
- MD: I know an individual that might be interested unfortunately not on the call. Many experience at NVIDIA, I’ll shoot an email. Ray Williams.
- DJ: Let’s give it some time, for now let’s say DS and MM are editors.
- MM: Any reason for absence?
- MD: Just this week, he’s on vacation.
Resolved: Dan and Myles to be editors. Microsoft may nominate a third editor during the coming week.
- DJ: OK to start with Design principles?
- DJ: Let’s start with 586
- DS: I listed a bunch of topics
- text based language
- writable by programmers
- cost free bijection #582 between WebGPU SPIR-V and WGSL and back
- The bijection is simple and efficient, doesn't require an optimizing WGSL compiler
- Directly represents structured control flow
- Language is as small as possible to represent what we need
- The burden is always to show why we must add something
- DS: DN noted that it should be strongly statically typed
- DS: And other comments
- MM: Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too
- DN: [missed]
- DJ: Treatment of the language is a point of heated discussion
- MM: Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point
- DN: I think human readability is achieved already by the initial proposal despite its subjective nature. I think we are well beyond talking extremes and down to a more narrow field of discussion.
- DJ: We agree with DS’s list
- MM: Burden-proof is the responsibility of group, not something that is needed in the language specification.
- MM: I added simple compilation to MSL and HLSL because omission is simply incorrect
- DN: We just have different wording, I am fine with mentioning MSL and HLSL explicitly
- MM: I believe there is some subtle conflict, there needs to be a more explanation
- DP: We need to take all into consideration, that’s the balance
- JF: That’s implicit
- MM: E.g. continuing block. That’s a relatively more trivial construct in SPIR-V compared to MSL and HLSL. I want it to be a balanced effort across all.
- JG: I also want it more balanced
- DS: Me too
- DN: Agreed
- DM: Targeting all languages is important but we give weight to SPIR-V because of semantic similarity
- DP: SPIR-V has a special place here
- DM: So do we mean all three need to be efficiently generated?
- RM: I think we need all three simple/efficient to generate, just with an extra constraint of using SPIRV for semantics, and possibly requiring something about SPIRV->WGSL->SPIRV.
- MM: How do we judge how easy it was to generate?
- DS: I listed a bunch of topics
Resolved: Dan’s initial list of principles from #586 will be accepted. Some of them in the language, some in the README. Dan will send a pull request for this.
Resolved: Incorporate “Supporting simple and efficient compilation to MSL and HLSL” item.
- DN: Just 10 min before meeting I added comment on bijectivity issue, can give a briefing. Comment is https://github.com/gpuweb/gpuweb/issues/582#issuecomment-594108572
- MM: Cool! I have a bunch of responses. Thank you!
- MM: First one is we have other target languages. When an author writes a program, exact register pressure won’t be applicable. We should be able to adapt to this.
- MM: Authors might take a specific tradeoff but we target all the devices on the web. I don’t propose that author shouldn’t have degrees of freedom on optimization but…
- MM: We should rather be data driven and build around it.
- MM: I think byte-to-byte conversion is infeasible and the group also probably agrees.
- NI: Is integrated GPU in consideration? The bigger GPUs and internal modules diverge on many specifications. What level of abstraction are we looking at?
- DN: We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime.
- MM: I think we are agreeing more rather than disagreeing. We can build data with devices and take decisions using it to reduce the search space.
- JG: We should also take expertise into consideration. We have access to a lot of experts.
- MM: No denying to that.
- DN: We should be reductionist for level of sophistication of driver. I think there’s a world we can optimize less for the backends.
- DP: That’s optimistic.
- MD: Driver authors will definitely optimize.
- DN: I want to make optimization as easy as possible.
- NI: [missed]. I was wondering if we were thinking of adding another level above this.
- MM: I’ll make the point that Web Assembly started with this goal, but ended up with each implementation having a multi-level optimizing compiler for Wasm.
- RM: We should try to preserve as much of possible as performance and semantics from WGSL and SPIRV.
- DN: I liked Maciej’s point about trading complexity in places.
- DN: “Unless” operator prevents an extra pass in resolving flow. But going forward, we can implement and then make engineering decisions.
Resolved: Myles to send a pull request for the bijectivity rules in the README.
- DJ: We don’t have much time left but we had a good first meeting. If you want an issue discussed, please label it to be discussed at meeting.
Comma operator #581
for() loop #569
Scribes script. ■