Skip to content

WGSL 2020 04 07

Jump to bottom
François Daoust edited this page Dec 2, 2020 · 1 revision
Dean Jackson

:

 Chair
Mehmet Oguz Derin
  1. Scribe’s Preface: I am new to scribing, and I tend to write using telegraphic sentences. Please let me know or edit where needed.

:𐰆𐰍𐰔 :

 ⌨️ Scribe
Google Meet

:

 Location
https://webgpu.dev/wgsl

:

 Specification
WGSL Issues

:

 Open Issues
Marked Issues

:

 Meeting Issues 


## TL;DR;
  • Spec editing process has been decided upon and will get sent out as an email soon.
  • dneto@ did a presentation on canonicalization of SPIR-V to help clarify the bijectivity constraints
  • Revised previous decision to require StorageClass on all module scoped variables and to have no storage class on Function variables.
  • Resolved to accept change to have dxdp_coarse instead of the generics version
  • Resolved to remove regardless and premerge

Tentative Agenda

📋 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
    • Greg Roth
    • Michael Dougherty
    • Tex Riddell
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Joshua Groves
  • Mehmet Oguz Derin
  • Timo de Kort
  • Lukasz Pasek
  • Tyler Larson
  • Lukasz Pasek
  • Pelle Johnsen
  • Matijs Toonen

📑 Prior Cheat Sheet

Aggressively summarizes (strictly) only the updates from YYYY MM DD - 6 to YYYY MM DD.

This cheat sheet was built by the scribe who would hugely appreciate and improve based on feedback, contact using [email protected]

Reconsidering the approach and design of this section as it got too explicit and littered to speak to the eye, the sheet will start to cover all topics again soon. 😴😴😴

📐 Meta

  • GR: Trying to work out exact protocol for spec editors. Getting feedback on it. There is something in charter on how decisions are made. It seems standard but documenting makes sense to avoid misunderstandings. Trivial changes should be straightforward to approve and merge. More controversial changes should be marked and discussed accordingly.
  • DN: So changes always occur by merge?
  • GR: A question would be do the decisions made in these meetings get accepted directly or does someone make a reflection later? Adds a bit of bureaucracy.
  • DM: We aren’t resolving issues just after they get discussed in meetings.
  • DJ: No, we will just note as discussed.
  • DM: So will there be a room for discussion later?
  • DS: We discuss at meeting, label as discussed, someone creates a PR (where you can have more discussion)...

⚖️ Discussion

🔗 Presentation by dneto - Preserving developer trust via careful conversion between SPIR-V and WGSL

  • Slides: Preserving developer trust via careful SPIR-V WGSL conversions 2020-04-06
  • DN: Comes up based on bijectivity discussions. SPIR-V module is one that is only using WebGPU model. Developers fight with shader compilers, out of their control and have to work around issues. Want more control, mirrors what happens at API level. Authoring flows are complex, 4 or longer steps to compile. Can take years to update authoring toolchains. Increases complex and cost as new steps are added. Had private messages of SPIR-V or nothing, that’s not going to happen, but want to take that into consideration. Devs want to understand what’s happening after the WGSL compiler boundary. So, if you go SPIR-V1 -> WGSL -> SPIR-V2 you should be able to take SPIR-V1 and canonicalize it and that is identical to a canonicalized SPIR-V2 module. In this world, the WGSL is human writable, and those canonicalizations are byte identical and the SPIR-V -> WGSL is simple and understandable. Want to bound the complexity so folks can understand what is happening
  • DM: The tame this beast still applies if we follow proposal as there is not just SPIR-V coming out but MSL and HLSL. Having canonical SPIR-V just solves part of the problem. This also applies to other backends which we have to make robust and usable.
  • DN: Valid concerns. Can’t speak to them. At least with this lets us know that the WGSL didn’t get in the way of programmer intent. The canonicalization won’t change the meaning of the thing. Equality means highly testable hypothesis. Could write automated testing to verify we didn’t break things. Conversion from SPIR-V to WGSL is non-obvious.
  • MM: Some responses, on slide 6 diagram is relevant for some targets but not all, in fact not majority. Most won’t have diagrams that look like this, the right side will be different on Metal and D3D. Diagram reflects some of the solution space but is incomplete. Developer trust is valuable and one way to gain is to not do anything and ship what they already have. Not the only way to get developer trust - at least one other way is to provide good software that does what it claims to do. Providing good software doesn’t require only shipping the tool developers already have. We could make a high quality language that doesn’t look like SPIR-V. A good job of that language would satisfy the developer trust criteria.
  • RM: What is considered OK in canonicalization? Would be good if it preserved performance. Not clear that ‘obviously’ is a good enough standard. Would need to measure and test. Discussions on constructions have had questions of what matters and does not matter for performance
  • DN: Obvious isn’t strong. Sliding scale of changes … Not something that can be argued crystal clear. Writing down list it should be able to see why each one isn’t performance degrading. Should be validated by measurements. Responding to Myles, the right hand side is only applicable to browser handling SPIR-V on the inside.
  • RM: Generally agree on it being a sliding rule on how obvious things can be. Instead of looking and saying what’s obviously and not obviously fine actually measuring things would be more principled. Would allow progress to be made
  • PJ: Would prefer to be WGSL now, but instead currently GLSLang going to SPIR-V and using that. When WGSL comes online, may want to go with GLSLang outputting WGSL directly if that’s possible.
  • DN: GLSLang now has an HLSL complication path to compile to vulkan SPIR-V. Emits non-valid SPIR-V which get transformed into valid SPIR-V in SPIRV-Opt. GLSLang auto invokes that flow. Will probably build tooling to make that flow similar. Bigger question what would be the original language of authorship.
  • PJ: As a developer don’t care too much about SPIR-V as working at a higher level
  • MM: Another piece here, question at the heart is what goes on in canonicalization. Already said ID’s don't have to match,already in a series of degrees. How do we draw the line on what is allowed inside canonicalization and what isn’t. One of the criteria is they should be understandable to developers. Not going to disagree but a more valuable way to draw the line is can you demonstrate with behaviour or performance claims that a transformation has no effect. Numbers and validations are a stronger argument then understandability.
  • JG: Don’t know if you can prove it with numbers, can only falsify, can’t prove. Have to do theoretical work and make estimations.
  • DN: Concrete example, premerge existed during workshopping found a case and added syntax to WGSL draft. Removing premerge means we have to hide that case, canonicalization can hide the premerge. So a simpler WGSL is a larger canonicalization
  • MM: Not sure what canonicalization is. Why is the canonicalization step valuable.
  • DN: No one has to run a canonicalization step.
  • MM: Is group defining the canonicalization step or WGSL
  • DN: Only WGSL. This lets me make promises to the developers I have to speak for
  • RN: In order to prove SPIR-V M0 has same performance of SPIR-V M1. Proving canonicalization doesn’t change performance is a shortcut in the argument. The WGSL tile doesn’t have to be all of WGSL, just the WGSL generated from SPIR-V. Syntactic sugar doesn’t fall into the block as it isn’t generated by the SPIR-V frontend.
  • TR: Seems that SPIR-V supports higher/lower level ways of expressing programs. Those higher level ways need compilation to lower level for drivers. DXIL has other constraints, everything inlined, etc. The constraints aren’t met by SPIR-V. Just saying SPIR-V does that mean a driver constrained SPIR-V. Don’t know the driver constraints. Difficult to do this canonicalization without having control over the compiler which is compiling the SPIR-V. Are we trying to build an assembly language for SPIR-V or a writable language authors can write by hand. Seems to be a conflict between those two. If just SPIR-V then can see a conversion but difficult to write.
  • JG: Don’t think it’s difficult to write, we kinda do it now. If i look at WGSL can i know what it’s going to generate in terms of SPIR-V and if i look at SPIR-V would I know what WGSL will it produce. The argument is that the canonicalization is possible and the intent is preserved between M0 and M1.
  • TR: Like the idea of doing this, WGSL is basically a human readable SPIR-V but doesn’t have concepts that need to be compiled down to something different
  • MM: No, it’s OK if WGSL has things that wouldn't be emitted by the SPIR-V to WGSL compile. Syntactic sugar is allowed
  • JG: One example, is we talked about multi-break. One of the reasons to withdraw is there is no zero-cost abstraction in SPIR-V we could create for this. Is that true on all backends, we don’t know but it’s true in SPIR-V. Pressure to not add things to SPIR-V for things that don't’ have low-cost abstractions.
  • MM: PJ mentioned they won’t write and don’t care about SPIR-V. It’s confusing to hear that developers care about SPIR-V transforms when developers don’t see or use SPIR-V.
  • JG: We heard from one developer and value the input but to extrapolate from that to all developers is not accurate. We’ve been, certainly David has, from developers. There are multiple consumers for the API. Some just want to rotate a triangle, some want to make full games in JS and do everything in JS. Also have folks who have lots of existing content and want to move whole sections on the web. The third category is the one that wants the guarantees. They already fought those battles on the guarantees with the native APIs and don't’ want to do it again on the Web.
  • MM: Agree with what was said, will restate: the author made some trade offs when writing source code on memory bandwidth ALU and parallelism. Should try to preserve their choice and not ignore tradeoffs. This is a different thing than saying the canonicalization step needs to be trivially understandable to developers.
  • DN: THere is a big gap between those two. One way we can help is to give this stronger guarantee. Early was said we can give confidence by writing high quality software. Agree with that but graphics world has a bad track record.
  • GR: Perhaps instructive to look at the transition from GLSL being submitted to the drives to the Vulkan change to SPIR-V. Some parallels there, not a perfect analogy.
  • MM: One of the strongest tools we have is using performance analysis. Surprising to hear someone say we shouldn't use it.
  • JG: It has limitations, sometimes we have to work in theoretical space. We lack ability to do exhaustive performance analysis but can make good guesses given the folks here being experts in industry and technologies without exhaustive performance analysis.
  • MM: Not looking for exhaustion. Premerge was a good example as it isn’t shown to be beneficial for performance or correctness. Not saying it should be shown in all corner cases of a particular construct, but at least should be shown in some cases.
  • JG: We should find that out, but main tools should be outreach to folks who made the decisions before us. Various native working groups and teams have made these decisions previously. Usually know why they did things and can point out when things were mistakes.

🔗 Issue #654 - var declaration without storage class: spell out rules, infer Function storage class inside a function

  • DN: Tex had example of private variables. But when working on notes, I noticed this doesn’t apply since we are more similar to GLSL.
  • JG: I prefer undecorated one be default.
  • DS: It makes syntax consistent too.
  • JG: in absence of strong opinions we should default to explicit
  • DJ: Resolved if no objections

🔗 Issue #655 - Move builtins and intrinsics out of the grammar

  • JG: It removed decoration syntax from grammar, latest update fixes that.
  • DS: Does this change dpdy? Now we have three keywords, with additional underscore.
  • DM: I think it is better to not use generics? unless no reason.
  • JG: Then we can assume resolved.

🔗 Mail #public-gpu/2020Mar/0024 - Test for round-trippability

🔗 Issue #640 - The set of functions which have to be imported seems arbitrary

🔗 Issue #643 - Remove break if in favor of if () { break; }

🔗 Issue #559 - Lexical scoping

🔗 Issue #677 - C-like declaration order

🔗 Issue #658 - FP16 support

🔗 Issue #662 - entry_point_decl should be an annotation on the function

🗓 Next Week

Clone this wiki locally