-
Notifications
You must be signed in to change notification settings - Fork 304
WGSL 2020 03 24
François Daoust edited this page Dec 2, 2020
·
1 revision
| Dean Jackson |
: |
Chair |
Mehmet Oguz Derin
|
:𐰆𐰍𐰔 : |
⌨️ Scribe |
| Google Meet |
: |
Location |
| https://webgpu.dev/wgsl |
: |
Specification |
| WGSL Issues |
: |
Open Issues |
| Marked Issues |
: |
Meeting Issues |
- Proposal for multiple literal values in case statements was accepted. Next step is for the proposed spec change to be put up for review
- Discussion around loads/stores and how to handle multiple loads of the same value. The proposed answer is to leave it to the driver to optimize away and, an implementation can generate multiple OpLoads for a single expression
e.g a = x + x + x; - Decision to close out the entry point input/output issue with no change. They can be computed and have to be computed to be verified so no benefit to having them be explicit.
- Decision to pull builtins/intrinsics out of the grammar and into a builtin section in the spec.
- Decision to use gramarkdown to validate the grammar as it's simple and covers what we need
- Decision to setup a github project to track spec work.
- 🔗 Issue #630 - Propose switch-case permit multiple literal values per case
- 🔗 Issue #622 - Variable loads and stores
- 🔗 Issue #592 - Entry point input/output global variables
- 🔗 Issue #616 - Builtins/intrinsics are unnecessarily part of the WGSL grammar
- 🔗 Issue #578 - Validation on CI
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
- Mozilla
- Dzmitry Malyshau
- Jeff Gilbert
- Joshua Groves
- Mehmet Oguz Derin
- Timo de Kort
- Lukasz Pasek
- Tyler Larson
- Lukasz Pasek
- Pelle Johnsen
- Open pull requests
Aggressively summarizes (strictly) only the updates from 2020 03 18 to 2020 03 24.
This cheat sheet was built by the scribe who would hugely appreciate and improve based on feedback, contact using [email protected]
| ❓ Issues | ❗️ Pull Requests | ||||||||||||||||||||||||||||||||||||||||||||||||
#561 Offset Decorations on Structs
#621 Redundant Layout Decorations
#624 Shader Reflection
#620 Do WGSL and SPIR-V seamlessly convert?
#630 Multiple Literal Value per Case for Switch
#631 Function Declarations
#578 Validate Grammar on CI
#600 Plan for Expansion
#622 Variable Loads and Stores
#592 Entry Point Input Output Global Variables
#616 Separate Builtins/Intrinsics
|
**#682 Match example to definition**
|
🔗 Issue #630 - Propose switch-case permit multiple literal values per case
- DN: I put an example of switch cases and right now it follows a C-ish syntax. The idea is essentially having multiple literals in a single case to make more concise code.
- MM: So the case will be checked for being literals?
- DN: At first.
- RM: I generally agree. Both trivial to implement and convenient. All for it.
- JG: Useful but doesn’t seem necessary to me.
- DN: I have prototyped before posting it. Prototyped both ways from SPIR-V to WGSL and vice versa. It is kind of trivial to do. Thus proposed.
- JG: how is this different from a painful chain of ifs
- DN: (explains painful chain of ifs)?
- DN: There’s switch in SPIR-V, isomorphic to LLVM’s. A lot of compilers will lower to a chain of ifs.
- JG: So this is exposed and I am for it.
- DJ: Everyone for it, no one spoke up? We will call it thumbs up!
🔗 Issue #622 - Variable loads and stores
- DM: It is about the existing implicitness of load/store operations. This makes things ambiguous and makes it less trivial to have an two way conversion from WGSL to SPIR-V. I think this is concerning.
- MM: You should get it back if you do convert without explicit operators.
- RM: I don’t expect much of a performance difference because the drivers will run compiler optimizations and these are trivial passes.
- DN: glslang always generates a ton of loads and stores and later down the pipe, these get reduced. If the author has to count number of loads, should do const load. The more concerning case is where you can eliminate the variable.
- JG: We might end up having a language where using const makes things faster rather than being just a compile time construct.
- DM: I think at the moment it is convincing that we can do OpLoads for now. Should document that we recommend using const for loaded variables.
- JG: Resolved, do nothing. Actually resolved, document.
- DP: I think spec should describe one way to do it to have semantics set. Then compiler can do what it wants to do on top of it.
- DS: I think we should take the DM’s example and work through it.
- JG: We should say that const will have performance benefits.
- MM: Well, only on SPIR-V backends.
- JG: I still think this is an outlying approach, it is not normal for const to be a runtime impacting optimization, we should document that.
- DP: I think we should document this properly in spec in one way and that will make it easier to build upon.
- DJ: So are we not adding any normative text?
- DS: We should work through DM’s example and set the case using that walkthrough.
- RM: I think the idea is a non-normative explanation can make it clearer to the reader and why const might have performance benefits.
- DS: So we don’t have to put to the spec that const will make things faster. Just that many load stores can cause problem.
🔗 Issue #592 - Entry point input/output global variables
- DS: I think we came to the conclusion that we can scan our way through this and just not have the user type them.
- MM: Agree.
- DM: Yep.
- JG: So closing the issue.
- DJ: Everyone agreed?!
- MM: Will file a new bug about writing a section in the spec around the interface
🔗 Issue #616 - Builtins/intrinsics are unnecessarily part of the WGSL grammar
- JG: Right now we have the intrinsics as part of the grammar, which is surprising to me. My general proposal is that have them as invisible keywords and they are already there.
- DM: So if they are not in the grammar and user wants to use the same name. How would that work?
- JG: If you have these built in, then it is up to the other details of the signature and if it is reserved by the builtins, then it will give an error.
- DM: What are you trying to achieve by removing the intrinsics from the grammar?
- JG: They don’t need to be there. Makes the grammar easier.
- MM: I agree with JG.
- DS: The reason why I put them there in the first place was because it was trivial.
- JG: I’ll put a PR to move them out of the grammar. But this leaves out the question of operators.
- DS: I think these also could be moved out.
- MM: There will be really many of them. They should not be a part of grammar.
- JG: I like the idea of having basic operators in grammar and having more nuanced ones to library is better. Also there is the SEO aspect. Operators are hard to search.
- DS: So we can move them out.
- JG: Will do. But we should also clarify discussion about explicit and implicit conversions. Is there an opinionation about that?
- DS: We should be fully explicit.
- DN: Agreed to be explicit.
- MM: We should discuss this in a more proper context like in an issue because it is a great deal.
- DN: Let’s first make an issue and move it from there.
🔗 Issue #578 - Validation on CI
- MOD: Gives an update on the validation tools that are available. The choices come down to grammarkdown and k-framework (sp?). The four forthcomers: Grammophone, Rascal, Grammarkdown, K Framework.
- Grammophone is easy to eliminate, syntax is distint from what we have done so far and what it builds upon is no longer maintained, as the Grammophone itself isn’t.
- Rascal puts much more weight to being a general metaprogramming language, syntax definitions are just a module for it, which would be OK but there are alternatives that put much more weight syntax definitions. But still, it is important to note that Rascal and K Framework share an ancestor. Also it has a distinct syntax for syntax definition.
- Grammarkdown actually isn’t the compared tool here, it is just a wrapper around Ecmarkup which is what we should be comparing to. Grammarkdown is (at the moment) an undermaintained wrapper around Ecmarkup which is better maintained. Ecmarkup solely stems from industrial and practical needs, it has a well-defined scope and never steps out of it.
- K Framework is a robust semantics definition tool that makes it possible to extract a ton of formalism from the least amount of definition. What makes this actually work is the combination with rewrite rules. That choice adds an incredible dimensionality to K Framework, bringing it to the competition to the likes of Agda, Coq and Lean while having a quite easy to comprehend (well, compared to the aforementioned theorem provers really easy to comprehend) way to build in it.
- MOD: Grammarkdown is derived from the tool used to validate ECMAScript, Ecmarkup.
- MOD: I think K framework has a robust syntax. Other advantages has rewrite rules to provide semantics. I experimented and it wasn’t too hard to integrate. This could help us resolve more contentious topics using objective measures. For example, comma operator as an expression-level token can be tested out using rewrite rules even if we don’t go around trying to define the whole language’s semantics, which would be quite a stretch. I think K framework is the clear winner.
- MOD: Going back to the level of comparing K Framework and Grammarkdown’s syntax, it is important to note that Grammarkdown’s syntax can be observed as a result of Omit(x) function, evaluated at PutEmphasisToTabs(Omit(K Framework)). This omission denies the years of research K Framework is built upon and is a clear step back.
- MOD: It would allow us to add rewrite rules and evaluate syntax changes to the language. We could also extract the examples from the specification and validate them without any extra effort.
- JF: I would like the grammar to be small enough to understand in your head.
- MOD: The rewrite rules are completely optional, and can be put in a separate module. Once you do that it becomes very similar in appearance to grammarkdown. And at that point, both are quite similar to what is in the bikeshed file. The differentiator there is: K Framework has many (forgot to mention: Python, C, C++, K itself, Java, [insert some blockchain languages]) implementations which are done using literate programming and has proper tutorial material built for it.
- JF: My preference: be able to validate the grammar, validate the test cases, and easy to install.
- DN: I tried to use the K Framework a while ago and was unable to get it working. So I am slightly nervous about using it. Although I haven’t gone down the road of having it inside a Docker image.
- MOD: I was able to set up a Colab Notebook (pre-set Jupyter environment) with a few bash commands.
- MOD: I know, repeatedly mentioning semantics here is out of place but it is important to note that it is an emerging field. As a next generation shading language, we should leave the door open or create incentives for next generation analysis. Last year, Coq and Lean had its first (notable) GPU semantics work, which support the thought of emergence.
- JF: That’s cool research, but this isn’t the forum for research. Let’s just satisfy our pure needs.
- MOD: Agreed. I think it is just a benefit from our standpoint, just mentioned to put things in context because earlier I said the syntax of K Framework is more robust, this stems from the fact that it has such effort baked for the semantics. Thus enforcing the user to stay true to some strict rules when it comes to writing constructs, which are very easy to keep up but hey, you can forget it while you are working.
- JF: I don’t think it is, because I want to be clear that we are not going to use them. My tendency is towards using grammarkdown because we can install it with one command.
- DS: Yes. Everyone here probably has JS tools.
- JF: Also, since ECMAScript is using it, I know I can find colleagues who know about it.
- MOD: (Explains the benefits of K). The way it works makes it more useful. It was not too hard to set up compared to setting up node, npm from distribution rather than the managed package repository.
- JF: Just looking at the dependencies of the toolchain, grammarkdown is much more simple. We only need to verify the grammar and host that on CI, and the easiest path to that is grammarkdown.
- DS: I agree.
- JF: Thanks for the investigations.
- MOD: Since I couldn’t digest many tutorial material in Grammarkdown, I’d like to drop.
- DN: I just read the grammarkdown rules. Please, can we ban the tab character?
- JF: Yes.
**📐 Administrative: **GitHub Project
- DM: Should we have a new GitHub project for tracking changes to the specification?
- e.g. https://github.com/orgs/gpuweb/projects/1
- Discussion as to whether the existing GPUWeb project is enough, or it should be a new one.
- Resolution: DS will create a new project in gpuweb