WGSL 2020 09 15

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

Tentative Agenda

• Should we use the core WebGPU meeting for bonus WGSL time?
• Adding texture_sampler_types to type_decl (#1058)
• Move texture methods into an import? (#1018)
• Rename 'as' to bitCast; remove 'cast' (#1047)
• Determine the syntax for attributes (#1067)
• Consider binding(n, m) instead of set n, binding m (#1068)
• 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)
• read-only image storage type declarations: examples inconsistent with grammar (#1056)
• Fixing textureLoad for read-only storage image (#1032)
• Method of ensuring GPUShaderModules can contain MTLLibraries (#1064)

---

📋 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
• Kris & Paul Leathers

---

⚖️ Discussion

Should we use the core WebGPU meeting for bonus WGSL time?

• DJ: Core webGPU meeting has volunteered to let us use their time for WGSL topics. We have more work then them at the moment, but it is another meeting. 23hrs before this meeting. Wouldn’t be every week but when needed
• DN: Some topics overlap with API and would be good to cover during that time. Would prefer more review coverage if we have more meetings, often land patches in middle of this meeting.
• DJ: Two parts to progress, discussion and landing the patches. Mostly coming from David and dan at the moment. Would it be OK with Greg and others if this was OK?
• DM: I suggested it so I’m OK.
• GR: Can show up.
• DJ: As David said, can make a lot of progress on the patch landing part of it. Will negotiate with CW when topics come up, or make every 2nd week WGSL meeting.

Adding texture_sampler_types to type_decl (#1058)

• DS: This is us implementing the texture stuff. Tomic suggested a better way. Treat textures as types. No special rules for texture variables. I think this makes sense.
• DM: Do we need a separation of local and global types. Textures can’t be local.
• DS: I think that is a validation rule.
• DJ: Please submit this PR!

Move texture methods into an import? (#1018)

• DJ: Unclear what we’re waiting on here.
• DS: From last discussion we had some options, easiest is “import X as Y”.
• JG: Gets into another general question. This “import as” isn’t my favourite solution. Custom aliases is ok to move to MVP. What is our pseudo namespace requirement?
• JG: Call something by name. What is our forward looking plan? Why not make it now? Can we add “using” now?
• DS: Are you asking if we could just assume the stdlib is there, and you use it with std::?
• JG: Similar yes. GLSL has a #pragma version and then you can just use them. We thought a namespace was good because we’d be the only ones adding. But maybe we don’t need that.
• DS: This is basically what we have now with texture functions. They are in a global namespace.
• DS: This is fine. Maybe some of the GLSL ones could be moved there too.
• DS: I don’t mind. I just want consistency.
• KN: DOn’t mind either way. Slight preference for “import”
• GR: I don’t mind either, but we’ve been told that named imports would be helpful.
• DN: I prefer named imports too, because I think it will be our final solution. As for global namespace, I think it would helps for things like math function where we could have different libraries with different accuracy.
• JG: I just wonder if we really need this now. We have a tendency to define taxonomies.
• DS: I think that everything we have right now would be in the single namespace.
• KN: Two topics - moving texture functions into an import, and how to import that.
• JG: I think texture fns should go into the “standard” namespace.
• DS: I would keep “texture” in the name. e.g. s::textureLoad.
• JG: I want to avoid people having to add a prefix for obvious things like t::textureLoad. We’ve said that people won’t be able to add to the std namespace. Sure, we want to avoid creating new global symbols that conflict with user code. But we also don’t want to change std functions that breaks existing code - no way to feature detect.
• KN: I think that “import * from” helps with that. And another way to specify which version of the std library you import. Versioning the stdlib seems better than versioning the language.
• JG: Since we’re on the web we have very little latitude to drop old versions. We can’t add things to the stdlib without knowing we’ll have to support them forever.
• KN: If we don’t have language versions, we have pressure to never change the language.
• JG: We need a way to allow this. I think that we’ll have a way to select a language version. Since we’ll have to do that, i don’t see a strong difference between language version and namespace versioning. i.e. my proposal is that everything sits in the global namespace and we use a global language version to identify. I don’t think it is that useful to have namespaces on the stdlib. And I don’t see a strong usecase for having to import the stdlib anyway.
• KN: I think the core thing to figure out is “do we want stable versions of the language + stdlib” or “do we want to make changes that can be detected”? I would prefer a single language version with feature detection. THis is effectively what we do with the API surface.
• JG: Fwd v Backward compatibility - if we don’t have strong versioning, people might write content on a newer browser and never check older versions.
• KN: We can’t say that a new browser will tell you if your code will run on an old browser.
• JG: We do want to maintain some concept of stability for older content/browsers.
• DS: You don’t have to maintain multiple versions.
• KN: We’re asking “should old version of WGSL work in new browser?”
• DN: If you ask for the old version? Would require flags.
• JG: My suggestion is that if we have stdlib as an import, then I would like it to be used without the prefix, and thus like “import *”. So the names would be similar to GLSL.
• DN: Seems like if we had the two options:
  • import std as s
  • import * from std
• DN: … then that would satisfy your requirement?
• JG: Would prefer not having to import the stdlib at all. It’s a bit gross. Makes gluing various scripts together difficult.
• DS: Copy and pasting scripts together is something important to think of. I agree.
• DS: Suggestion - leave textures where they are for now (global). See how many of them we will have and make the decision later. I would also move the GLSL stuff into global for now as well. This removes the need for import.
• KN: Except that we started with namespaces to avoid changes that conflict. Would we put this decision off until we want to make a breaking change?
• DS: We could decide to use a version tag at that time. But I wouldn’t worry about it now.
• [lots of virtual head nodding]
• DS: OK. I will convert that into spec stuff.
• Resolution: For now, textures and GLSL fns go into the global namespace, imports essentially are removed, we may want to come back to namespaces if we have a large number of things in the global namespace. May want to investigate versions in the future as well.

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

• DN: Pushed the first part recently. We had “as” for imports, but no longer needed.
• JG: Minor change - naming in commit message.
• Squished and merged.

Determine the syntax for attributes (#1067)

• DJ: Followon issue from other issues.
• KN: Sounds like more or less everyone is happy with c++ style of identifier(args, args).
• [[workgroup_size(1, 2, 3), stage(compute)]]
• DS: Does this allow multiple attributes?
• KN: Yes
• JG: I would prefer to allow multiple tags too.
• DS: Can we punt that for now?
• JG: No real reason. Grammar wise it isn’t important. Allow multiple tags, or multiple attrs in a tag.
• DS: I found function style so much easier to read.
• KN: It would be interesting if we had sufficient constexpr support….
• DJ: Proceed with c++ function style, multiple attributes in a tag and multiple tags are allowed.

Consider binding(n, m) instead of set(n), binding(m) (#1068)

• DS: Strong preference to NOT do binding(n, m) because I have to work out which is which.
• JG: I will say that separating them is a lot to read, and a lot of typing.
• KN: I think the ordering is confusing because prior art has made binding first and set 2nd. I think that’s unfortunate.
• JG: One way to address this would be call it “group_and_binding(g, b)”, then the order is obvious.
• DN: Why are we making this compound?
• JG: Typing both is kind-of gross. And you need both.
• JG: There is also a good chance that if you get this wrong you’ll get a validation error.
• DS: I like “group_and_binding” - you need both, it is clear it is both.
• DJ: I like that too
• DM: Name is kind of gross. We have a precedent for required variables. I would just have group and binding separately.
• JG: I think they are linked, so it makes sense to pair them.
• DN: I think separate is ok. Agree with DM.
• Resolution: “group” and “binding” as separate attributes. Consider adding a combined helper/alias later if necessary.

Separate linear sampler binding type? (#1034)

• DM: Suggestion from last week was no shader changes, just validate at pipeline creation time. PR up for API side, nothing to do on WGSL side. Reason to not touch WGSL is it’s easier to write shaders and convert from SPIR-V.
• DS: Resolution remove from WGSL project, API side only

Fixing textureLoad for read-only storage image (#1032)

• DS: I think we just need to merge this. Any complaints?
• JG: I’m surprised that we allow pick and choose of hte number of coordinates.
• DN: Based on the texture type.
• JG: I would say that the entry point allows up to a vec3. Surprised that we accept int and vec2.
• JG: Can I use a vec3 to sample from a 2d texture? What happens? GLSL would just ignore the out of bounds ones…. oh, no, there are different sampler types.
• DS: Merge PR. And Jeff will followup with another issue.

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)

read-only image storage type declarations: examples inconsistent with grammar (#1056)

Method of ensuring GPUShaderModules can contain MTLLibraries (#1064)