Skip to content

WGSL 2020 03 03

Jump to bottom
François Daoust edited this page Dec 2, 2020 · 1 revision
Clone this wiki locally

Chair: Dean
Scribe: 𐰆𐰍𐰔: Mehmet Oguz Derin
Location: Google Meet

Tentative agenda

  • Introductions
  • Meeting Time
  • Editors
  • Design Principles (design and bijectivity)
  • Comma operator / Continuing construct
  • for() loop
  • preprocessor
  • Other open issues
  • Agenda for next meeting

TL;DR;

  • Meetings will be in the same time slot, Tuesdays at 2pm EDT.
  • Editors:
    • 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.
  • Bijectivity
    • 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
  • Agenda
    • Tag items in the bug tracker if you wish them to be discussed at the next meeting.

Attendance

WIP, the list of all the people invited to the meeting. **In bold the people that have been seen in the meeting:**
  • Apple
    • Dean Jackson
    • Fil Pizlo
    • Myles C. Maxfield
    • Robin Morisset
  • Google
    • Dan Sinclair
    • David Neto
    • Kai Ninomiya
    • Ryan Harrison
    • Sarah Mashayekhi
  • Intel
    • Yunchao He
    • Narifumi Iwamoto
  • Microsoft
    • Damyan Pepper
    • Rafael Cintron
    • Michael Dougherty
  • Mozilla
    • 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

Introductions (especially new people)

  • 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.
  • MOD:
  • 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.

Administration
  • 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.

Meeting Time

  • 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.

Editors

  • 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.

Design Principles

  • DJ: OK to start with Design principles?
  • DJ: Let’s start with 586
  • https://github.com/gpuweb/gpuweb/issues/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?

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.

  • https://github.com/gpuweb/gpuweb/issues/582 (bijectivity)
    • 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.

Wrap up

  • 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.

Agenda for next meeting

Comma operator #581

for() loop #569

Preprocessor #568

Scribes script. ■