WGSL 2020 09 08

Dean Jackson	:	Chair
Everyone	:	⌨️ Scribe
Google Meet	:	Location
https://webgpu.dev/wgsl	:	Specification
WGSL Issues	:	Open Issues
Marked Issues	:	Meeting Issues

Tentative Agenda

• Move texture methods into an import? (#1018)
• Rename 'as' to bitCast; remove 'cast' (#1047)
• Remove duplicate grammar rule: global_constant_decl (#1051)
• Various grammar related updates to WGSL (#1054)
• Entry point fix, describe workgroups (#1046)
• Separate linear sampler binding type? (#1034)
• Are entryPoints namespaces per module or per stage per module? (#1023)
• Disallow fragment atomic ops on texture storages (#728)
• Invariant qualifier (#893)
• WGSL should use thread instead of invocation (#1031)

---

📋 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
• Pelle Johnsen
• Matijs Toonen
• Hamada Gasmallah
• Dominic Cerisano

---

⚖️ Discussion

Move texture methods into an import? (#1018)

• Let’s skip this - missing DS and anyone from Microsoft.

Rename 'as' to bitCast; remove 'cast' (#1047)

• JG: bitCast (camel case) seems weird to me; bitcast feels a lot better. They’re often separate words so I see why it was camelCase, but there’s prior art (SPIR-V) for treating it as one word. Hard to describe why except it “feels low level”, an integral part of the language, and this is. So better to me if it’s all lowercase.
• KN: +1
• DN: +1
• DJ: Accept bitcast as lowercase.

Cast/constructor vs function call

• DN: Another issue raised by Myles. The current grammar (for e.g. i32(x)) is ambiguous with function call (e.g. myfunc(x)). I and Myles preferred merging the two rules “ident ( x )” so the same parse rule applies to both.
• DM: I want to know if any logic is happening.
• MM: Two different productions - one for function calls, one for casts.
• DN: And they can be used in the same place.
• RM: Interested in DM’s question - is there any logic?
• DM: It’s always lossy - you have to know what will happen, or assume. foo(1) is obvious if you know the type of 1.
• DN: floating point to integer is actually doing work.
• RM: Both casts and functions can be lossy, and can do work. So I see casts as a particular class of functions with particular semantics.
• DM: I’m more concerned with construction, not the type conversion.
• MM: I think all the casts we have today are scalar casts. If we didn’t use as<>, and instead used ident(), you wouldn’t be able to cast to a complex type e.g array<3>. grammar would forbid.
• DN: We added vector construction out of scalars a while ago.
• MM: If we wanted one production for construction and casts calls, then use <>. Functions could not accept <>.
• JG: Makes bitcast a templated built-in. One production in the grammar to handle both.
• KN: Vector constructors too.
• …
• MM: Right now the grammar knows what all the texture types are. I think it should live outside the grammar (simplify the grammar).
• KN: DS had opinions here. Maybe wait for him.
• DN: Moving things out of the grammar means having to write more explicit type checking rules etc.
• DN: I would like to know more of the proposal. I am not a fan of using ident() as a constructor.
• Resolution: use bitcast as lowercase. Continue discussion next week.

Remove duplicate grammar rule: global_constant_decl (#1051)

• DN closed this, as #1054 already fixes this

Various grammar related updates to WGSL (#1054)

• DN merged this.

Grammar validation / ambiguity (#1063)

• MM: Wanted to see if the grammar is ambiguous. (I didn’t realize this until recently, but it turns out that’s undecidable.) The approach I took was to just take the grammar and transcribe it into a parser generator’s format (Bison, because it was already installed). Found some typos. Doing this exercise led to three different observations.
• 1. There is an ambiguity in the grammar.
• 2. The grammar is not LR(1). In particular, LR(1) (Bison) isn’t able to understand the difference between a function call on the LHS of an assignment f ( 1 ) = 2 ;, and a function call statement f ( 1 ) ;.
  • MM/DN: Not allowed (or intended to be allowed) by the language, but allowed by the grammar.
  • MM: Path A: Let the grammar be non-LR(1).
  • MM: Path B: Massage the grammar to be LR(1).
  • MM: Advantages of LR(1):
    • Ambiguity is decideable.
    • Parsing is faster.
• JG: Why is assignment ambiguous but addition not?
• MM: Bison has specific allowances for things like addition.
• RM: (I think this was an explanation of why addition is LR(1)?)
• RM: When does it make sense to have function call on the LHS?
• DN: Not valid because functions can’t return l-values.
• MM: Might want to allow it someday. Can modify the grammar then.
• GR: Can you share the bison file?
• MM: If we think LR(1) is valuable, then sure.
• (agreement it is)
• MM: There is another thing bison claims to be ambiguous, but I think it is a mistake. I’ll look into it. It doesn’t like statements that can either be if/else or a body. Doesn’t make sense.
• MM to file an issue to track grammar ambiguity.
• Also an issue to disallow function call on the LHS (in grammar).
• DM: Are we going to maintain the Bison grammar? Can we validate the official grammar?
• MM: With the spec, we have a tool to extract the IDL from the snippets. I suggest we do the same for WGSL. And as such, maintained by pull request and checked by CI.
• DM: But how would you create the Bison?
• MM: I will replace the current grammar in the spec with Bison.
• KN: Is our grammar in a specific format or is it an ad-hoc format?
• DN: This is what we originally had. It is ok to change it to Bison.
• KN: There are lots of web specs with grammars (JS, CSS); can we use their grammar languages?
• GR: Most important thing is to have automation for detecting problems like this.
• KN: Automation is definitely more important; but those specs probably have automation too.
• DJ: I’ll investigate this.
• DN: Happy with any of the other potential restrictions .e.g LALR(1)...

Entry point fix, describe workgroups (#1046)

• DN: Probably jammed too much into this PR. Was trying to address MM’s comment from a while back. DM suggested we do something more generic and I agree.
• DN: I started describing compute shaders, so we needed an attr on the function, workgroup is a triple and we need them all. Corentin pointed out that the API requires one, two or three dimensions. DM made some comments on workgroups (about dispatch forming). I made that update.
• DN: Two things:
  • what do we want the declaration to look like?
  • workgroup size?
• DM: Why not put stage as an attribute over the function?
• DN: This is the first time we have attributes on functions.
• MM: No strong opinions here.
• DM: My motivation for putting it as an attr is that it describes the host interface. It allows you to link it to the host side. So include stage.
• DN: I can go with that. I’ll rework it that way.
• MM: Even if compute is an attribute, the set of programs hasn’t changed.
• DN: stage vertex
• MM: Would prefer stage=vertex, but spaces are fine.
• DN: Other issue is workgroup size. Do we force people to spell out all three dimensions?
• MM: I don’t see the need to that.
• KN: The numbers in JS are the numbers of threadgroups, these numbers are the numbers of threads per groups.
• DN: What about “workgroup_size X Y Z”?
• DM: Let’s stick to “key space value”. No strong case for deviating from current rule.
• JG: Alternative?
• DM: “workgroup_size (1, 2, 3)”?
• MM: workgroup size(1, 2, 3)
• MM: workgroup_width 1, workgroup_depth 2, workgroup_whatever 3
• JG: workgroup_size [1, 2, 3]
• MM: I lean to the suggestion from DM.
• DN: JG’s has a potential ambiguity. Needed context dependent tokenization.
• JG: This has to work.
• JG: I prefer “workgroup_size X Y Z”. Just loosen the grammar slightly.
• MM: One benefit of the parens, is that it becomes more extensible.
• JG: You can still do that.
• MM: Yeah, but it quickly becomes mushy. e.g. workgroup_size 1 2 3 5 2 3 6 2
• JG: I don’t think the parens changes anything. Except allows commas.
• KN: Personally I'd prefer if attributes weren't comma-separated and just were attr 1 attr 2
• DN: We decided that this was too fussy. I’m happy with either DM workgroup_size(1,2,3) or MM’s workgroup_size 1 2 3
• JG: These are not really function calls. They are tuples.
• DN: I will update the PR to MM’s last suggestion and we can discuss.
• MM: I think having a grammar is more important than what it exactly is.

Separate linear sampler binding type? (#1034)

Are entryPoints namespaces per module or per stage per module? (#1023)

Disallow fragment atomic ops on texture storages (#728)

Invariant qualifier (#893)

WGSL should use thread instead of invocation (#1031)