Skip to content

WGSL 2020 11 30

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

:

 🪑 Chair

:

 ⌨️ Scribe
Google Meet

:

 🗺 Location
https://webgpu.dev/wgsl

:

 Specification
WGSL Issues

:

 Open Issues
Marked Issues

:

 Meeting Issues

Agenda

Pull Requests:

  • Introduce operator precedence table #1111
  • Reorder expression sections #1136
  • Sampling non-float textures is forbidden in HLSL #1162
  • Considering making ARROW function_type_decl optional for void functions #1219
  • Disallow implicit LOD texture methods in Compute shaders. #1221
  • Consider storage-texture "read"/"write" methods instead of "load"/"store" #1228
  • [wgsl] Unify decoration declarations. #1236
  • wsgl: Add rule that offsets must be compile time constant #1238
  • WGSL: idx -> index #1254

Open Issues:

  • [wgsl] Define the interface of an entry point in a WGSL program #774
  • Invariant qualifier #893
  • Proposal to enhance defining input/output variables. #1155
  • Placement of read_only attributes #1159
  • Out-of-bounds clamping brings big perf regression on TFJS ML demos. #1202
  • texture sampling with integer offset - portability concern #1206
  • should empty structs be permitted? #1222
  • WGSL: Use let instead of var? #1234
  • conflict between mat2x2 layout in uniform buffer and storage buffer #1258

📋 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
    • Corentin Wallez
    • Dan Sinclair
    • David Neto
    • Kai Ninomiya
    • James Darpinian
    • Brandon Jones
    • Ryan Harrison
    • Sarah Mashayekhi
    • Ben Clayton
  • Intel
    • Yunchao He
    • Narifumi Iwamoto
  • Microsoft
    • Damyan Pepper
    • Greg Roth
    • Michael Dougherty
    • Rafael Cintron
    • Tex Riddell
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Kings Distributed Systems
    • Daniel Desjardins
    • Hamada Gasmallah
    • Wes Garland
  • Dominic Cerisano
  • Joshua Groves
  • Kris & Paul Leathers
  • Lukasz Pasek
  • Matijs Toonen
  • Mehmet Oguz Derin
  • Pelle Johnsen
  • Timo de Kort
  • Tyler Larson
  • Eduardo H.P. Souza

⚖️ Discussion

Open PRs

Introduce operator precedence table #1111

  • DJ: Some comments awhile ago
  • MOD: Skip, others are working on making better
  • KN: Someone was going write the grammar rules
    DS: I believe that was RM

Reorder expression sections #1136

  • MOD: Same.
  • DJ: Again waiting for RM?
  • MOD: Depends on #1111

Sampling non-float textures is forbidden in HLSL #1162

  • DJ: Waiting for #1182 and mentioned in #1204
  • JG: I think this is awaiting specification
  • DJ: Doesn’t htis get handled by #1182?
  • JG: Don’t think so, but he said wants to wait for #1182. Moved to needs specification.
  • DM: Maybe nothing needs to be done when everything lands.

Considering making ARROW function_type_decl optional for void functions #1219

  • DJ: Make -> void optional ? Remove void?
  • DN: It’s a consistency thing. I’m ok with removing it. If you want to talk about the type of a function we can make a notation outside of WGSL itself. Still exists as a concept but is outside the language. So, I’m ok with removing.
  • KN: A lot of languages if you don’t specify they infer, not void. If we want to do that someday, should be non-breaking.
  • DJ: Could be non-breaking. Sometimes infer the last statement value. Don’t mind either way. Like consistency, don’t mind typing -> void.
  • JG: Narrow, but possible backwards compat issues if we infer the type later. Depending on what we allow for returning
  • KN: Any void now should be able to infer as a void function later.
  • JG: Right but if you have foo -> void and you used return bar() and bar implicitly return void
  • DM: Can’t implicitly return void, it isnt’ a real type
  • JG: Need more thought if we want to remove void. Especially into generics, want to be able to talk about this. Huge pain in c++ is working with functions which return void or not. I think there is potential risk
  • DJ: Should we separate the questions of removing -> void and removing void?
      1. Do we assume a missing -> void is implied
      • JG: Weekly against, don’t think a huge issues. From GLSL have to say void. Having to write void not a huge deal.
      • CW: Wrote a tonne of WGSL shaders converting dawn and writing -> void is annoying.
      • JG: That’s not the typical use case
      • CW: Probably people who wrote most WGSL at this point. Granted a weird use case.
      • JG: Hopefully that’s not us in the future
      • KN: Are most -> void on entry points. Can we just say we don’t put a return type on entry points? Entry points are grammatically functions.
      • DM: If we remove it all later, can we add it back later?
      • (...): Yes.
      • DM: We should remove it then
  • DS: Returning void the return statement must not have an expression, so you can’t return bar
  • JG: Right, so not an issue now, but something to keep an eye out. This is something that is shocking in c++ when people do this.
  • CW: what about replacing void with "unit", written () ?
  • JG: Like that in general, thats how i think of functions
  • DM: Works best with tuples. Can we discuss the naming and stuff when we add back?
  • JG: Worried it becomes invisible. Feel like we’re likely to have generics, and if so shouldn’t make things harder. Could be convinced here. If others aren’t worried that’s good. I’ll add my worry to the issue.
  • DJ: We’ll tentatively agree to make -> void optional.

Disallow implicit LOD texture methods in Compute shaders. #1221

  • DJ: DM and GR agrees, anyone against disallowing this?
  • DN: Other features like derivative builtins which are excluded. So a general pattern.
  • DJ: Then leave open so someone can come up with a list or do 1 by 1?
  • DN: 1 by 1. Someone at least note there are more.
  • GR: With SM 6.6, we’re adding support for these, but increases required hardware. Everything we added to compute shaders is in that list.
  • JG: For implicit LODs and derivatives
  • CW: Quad subgroup operations in compute shaders.
  • DM: So could be for each stdlib function which stages it’s available in. Some are assigned based on feature supported.
  • DJ: Sounds like a spec editing job.

Consider storage-texture "read"/"write" methods instead of "load"/"store" #1228

  • DM: Some discussion but mostly agreement.
  • DJ: Seems like MSL and SPIRV has read/write. HLSL and GLSL have load/store. I’ll vote yes.
  • DM: MSL and SPIRV vs HLSL and our attributes which are read/write
  • JG: KN had a good point we should make sure read/write are too overloaded. As long as you can read something ReadOnly and write something WriteONly it’s fine.
  • DN: I think it’s ok. SPIR-V has imageFetch as well but OK to lump in as well as differentiate based on texture type.
  • CW: BC you have a PR with read/write
  • BC: Can go with either. No preference.
  • DJ: Seems like most everyone is happy, would like someone from Microsoft to say OK.
  • GR: Just a namilng convention, no behaviour effect? Should point out, we refer to read write textures as RWTextures but it’s store/load. So, not entirely consistent. Don’t create either way
  • JG: GLSL also does it differently.
  • DJ: Of our target languages
  • JG: For our purposes our target languages don’t matter. The issue is what we call it fo our uses and what hte users have to type. We have predominant HLSL users and then GLSL is probably second.
  • DJ: Right, most shaders written will use load/store
  • JG: So for that reason, weakly for leaving as Load/Store.
  • BC: … More common to say AtomicLoad/Store then Read/Write
  • JG: The other aspect is barriers and do we still have stubset/superset we use read and we may or may not use ReadBarrier later. To that end, load/store feels safer. More semantically distinct. If we think it’s close enough and fine, can use read/write
  • KN: Would like a consistent taxonomy of terminalogicy. Therse are the ops you can do to read, these are the ones forwrite. For read we have texelFetch and sampling. There should be aword that refers to texel fetch or sample. Read is the obvious choice
  • JG: Yea.
  • GR: Would you advocate for atomicWrite?
  • JG: Probably
  • DN: Yea.
  • KN: Depends. If read/write are the generic teams, then each individual op should be more specific. These are the ways you can read, and these you can write. The ways to read adn write shoudl be different words then read/write
  • JG: Saying a texture is read only we then say you can only read from it. What Read means is you can read or fetch from it, or sample. Sort of nicer to have Load then it isn’t ambiguous when saying Read or read as a concept.
  • GR: Weakly convinced by JG in teh spirit of the principle of least surprise
  • DM: Our readonly attribute doesn’t mean you can sample. ReadOnly in attribute is not same as KN is talking about
  • JG: Yea, just think it’s confusing. Muliplej overloads for what read means that are context dependent. Saver to have it independent. This is what people are typing, no-one is typing PSIr-V. Everyone is using load/store.
  • DM: MSL as well which uses read/write
  • JG: That’s true, a minority but real.
  • DM: Would be fine with Load/Store as long as hte attribute names are consistent but so far they aren’t.
  • DN: I think attribute names of load/store would be unusual and would be against. Don’t think we need the consistency.
  • KN: Which attribute? Access on the storage texture?
  • DN: Yea
  • KN: I think it’s onk to say a storage texture is read only and the types of operations you can do on a storage texture is Load.
  • DN: Already in the memory model need to enumerate what memory operations occur based on expressions on teh language. Sometimes hard as they’re implicit when you load/store. Some time you have to explain what the memory ops are. For buffer variables some expression you have to explain. Don’t see need for consistency here.
  • DM: I see. If you see a read only storage texture user looks up Raed which is load or sample but then have to lookup what it means for storage texture where it only means load. Do you read for a sample texture? No, it isnt’ specified in the language for a sampled texture. This is only in the spec text for easier explanation, seems a little weird.
  • KN: Fundamentally everyone would suspect that a load is a read and a store is a write.
  • JG: Difference between read as an adjictive and a verb. ReadOnly doesn’t mean you can only ‘verb’ read, just that you can ‘adjictive’ read. A category filter, no saying you can only Read from this.
  • DM: So main argument is that GLSL programmers are going to be porting shaders and more used to Load/Store and that’s why we should keep it?
  • JG: 2 pronged. That’s strong prior art. Also useful to keep read from being a verb then there is no confusion on how read is used. Always a type of operation, never an operation. Never an operation read of operation type read.
  • DM: Read isn’t in the spec, up to the spec editors to decide what is in there. They could say read and sample everywhere. This is hypothetical at this point
  • JG: What about read-only storage texture. A storage texture has a load op and a store op. A read only one means only a Read operation, load is a read operation and store is not. If they’re called read/write they get messier to explain. Read is the operation and the type of operation you can do.
  • DM: If it’s the only operation it’s even simpler.
  • JG: Sort of. While it can be tempting to simplify when you merge the concepts you have to worry about when you want to unmerge them. Do you want to read from that object or Load from that object. We’re explicitly calling it a load and people will use the nomenclature Load and translate that into Read or we could follow HLSL and GLLS and just call it Load.
  • DM: GLSL uses fetch and load as different instructions
  • DN: Fetch is for sample
  • DM: Yea, and we use Load for everything. People will need to translate the GLSL fetch as load. So not 1-1 anyway.
  • JG: That’s fine. Still more clear when people are talking about load taht they know it’s one of those two things. No the concept of loading in general. When talking about readability, read encompases fetch and load and sample. Nice to not overload read even though it’s the same set.
  • DN: I find JG persuasive.
  • DM: Ok, don’t want to hold this issue, we can move on.
  • DJ: Anyone else want to comment?
  • BC: If no-one else complains, i’ll update PR to switch to Load/Store.

wsgl: Add rule that offsets must be compile time constant #1238

  • BC: A fun one around the definition of const. Feels based on discussion that const means slightly different thing based on scoping. Module scope seems different from function scope. What we want is a value known at compile time. C++ constexpr type definition. Don’t really want to add language features just for offset params. Could for now just have a literal or vector literal for the param for offers. Would be nice to figure out how to put into a named variable of some sort.
  • JG: Yea, think we’d need a language feature for that
  • DN: BC convinced me they’re different adn that we haven’t articulated that. Aways embedded in my head. In a c++ program a previous definition that you re-use that isnt’ ambiguous. In this case, for it to be a compile time constant you can’t depend on input or buffer variables so have to exclude various names. End up with constexpr. Which is the right concept for module scope. Think that’s the direction we should head. In SPIR-V, it allows the expression of constexpr. Don’t have that inany proposals or draft text but think we should go in that direction
  • BC: Slight issue with offset as a spec constant. Was hoping we could do shader compile time validation that they’re inbounds. With spec constants you need to validate at pipeline creation time which adds more compillcations. Would lean to disallow that
  • KN: Don’t know about offsets, but bindings don’t allow spec constants in spir-v. Would assume offers are the same way
  • DN: Looked it up, they’re allowed.
  • BC: You would then need to backtrack on the suage to see if it’s used on an offset and they apply the constraints. A lot of work.
  • KN: Would be awesome for certain use cases if we had spec constants in offets and binding points but maybe later.
  • DM: What if we go the other way around. What about instead of const foo you use var<constant> foo and we say whatever you pass here needs to be a constant or a variable with a storage class of constant.
  • DN: They don’t have storage. A var has storage so you can make a pointer and then a bunch of un-written rules to deal with them. No different then adding constexpr.
  • KN: I like the idea of just adding constexpr as a keyword and concept.
  • DM: Just think constexpr is a lot of complexity and just adding a storage type is less.
  • JG: That’s talking about looking forward to spec constants or for this here?
  • DM: I am looking forward to spec constants.
  • JG: Thought you ment for var<constant. would be a spec constant approach.
  • DM: For all constants, and then spec constants you’d add the constant_id
  • KN: In general a spec constant is constexpr right?
  • DN: Yes.
  • JG: Need to be careful how we add that, would be cool to have constexpr like stuff.
  • KN: We have it in the grammar already.
  • JG: Like reserved?
  • KN: Not he keyword. There is a const_expr concept in the grammar.
  • DN: Lets you make literals and type constructors of constant expressions.
  • JG: Just need to be careful we don’t drift too far from constexpr. For this BC I think just going down to a literal is the right idea for now.
  • BC: Yea, hovering around the idea of const, being new, getting head around const was confusing. Would be good if we could shore up some of that documentation
  • KN: Could come up with consistent terminology that makes sense. Constexpr isnt’ really teh clearest name. What we call const is really value as it represents a value and not a constant variable. Not that it usually matters but feel like there is constat value and var
  • DN: Lots of places things can get frozen. Ends up having to invert something abovce normal single threaded cpu code. MM Has said don’t make val as val and var is confusing. Lots of subilty and we need to improve.
  • KN: Static const.
  • BC: That’s the closest mental model I got
  • JG: If we want to be clear, even if we had compile time as an annotation. Static is less clear but the right conceptual direction. Can bikeshed the name later.
  • BC: Would we be happy with one of these const_expr expressions as a first step to fill in the hole? A literal or a vector of literals. Or got the whole way?
  • DN: Baby step for now and figure out the constexpr later.
  • JG: Plus 1.
  • KN: With constexpr there is the question of if they can appear inside a function to be lexically scoped in a function. But, still constant.
  • BC: Don’t know why they wouldn’t.
  • KN: Came up because const outside is one thing, const outside is another think.
  • DS: Const inside and outside can be hte same depending on how it’s initialized
  • KN: Right, that’s weird.
  • DJ: Next step for BC to take another pass?
  • BC: Will go over the PR again and we can file an issue for constexpr.

[wgsl] Unify decoration declarations. #1236

  • DS: Approved now. Can be merged.

WGSL: idx -> index #1254

  • DS: Copied from SPIR-V, I think we can merge.
  • DJ: Approved.
  • JG: For curiosity sake, it sounds like we can’t just use ID in places we use IDX?
  • KN: I don’t think we do that?
  • GR: Don’t think we have that
  • DN: they mean different things. ID is a tuple, IDX is linearized.
  • JG: Sure, more of an offset to me but that’s fine.

Open Issues:

conflict between mat2x2 layout in uniform buffer and storage buffer #1258

  • DN: When doing layout, followed OpenGL rules which has matrix stride constraints. A mat2x2 is different in UBO then SBO. This is a pain and don’t think any of our target APIs have that restriction. Would like to change mat2x2 to be more compact form.Think it simplifies a bunch of stuff. Wrinkle is porting from GLSL and compiler flow may need to be watched out for. Simpler to have compact 2x2s.
  • DM: Even in vulkan UBO?
  • DN: Yea, one of the folks at Google pointed out the Vulkan rules where different
  • CW: When targeting GL we can paper over with a vec4.
  • DN: Right.
  • JG: Taht sounds risky but if you think we can do it thats’ a good idea
  • DM: Out of scope anyway
  • KN: It’s OpenGL. If we have to in compat we can say no mat2x2.
  • JG: K, since vulkan says you can use?
  • CW: Vulkan says where OpenGL says matrix is array of vectors, Vulkan says array of scalars and aligned that way. Matrices have the alignment of the scalar.
  • JG: Is this tested …
  • DN: We will test this.
  • JG: This sounds like you re-wrote the rules based on a slightly off understanding of what happened in GLSL and wrote then in Vulkan and IHV’s signed off thinking it was STD140.
  • DN: We will test this and if it ends up not working we’ll revisit.
  • JG: I think it’s the case people will see this is a problem because we force them to show the work on offsets?
  • DN: Don’t force to show the work on matrices. Say only RowMajor and as compact as possible.
  • JG: Problem if matrix is at end of buffer and no-offset after that.
  • DS: Yes.
  • JG: Offset has to be tightly packed?
  • DN: We allow packing
  • CW: Would trip folks up if they think it’s 8 scalars and add the 8 offset when it’s more.
  • JG: This shows an issue who allowing folks to have padding as they may not realize they have padding.
  • DN: They are being explicit about padding with the offset
  • JG: Not really
  • KN: Wasting space
  • JG: If they read std140 and see a mat2x2 is 8 elements due to stride and they embed into the offsets and we have this rule as 2x2 is vec4 they’re wasting 4 elements every time.
  • DN: That’s the linters job to tell them.
  • JG: That’s why we asked for hte offset in the first place.
  • DN: We asked them for hte offsets as the rules shifted over time.
  • JG: I feel this is a case where the rules have shifted coming from GLSL std140. Will assume it takes 8 words and it would compile even if i have something after it as the compiler woudln’t care and I’d have a bug. But if we ask to show the work and you want padding you have to be explicit then it will protect
  • DN: Sounds like what you want is the person to have a member to fill out the padding.
  • DS: Do we want matrix_strdie so you put in it’s 16 and we fail validation that it’s 8.
  • JG: That would solve hte problem
  • KN: You waste space but is that an issue?
  • JG: If the compile told me I’d know to load into the 4 words instead of 8 words as the size would be wrong.
  • CW: We can surface warnings to the user
  • JG: …. (implicit padding)
  • CW: Liek you have padding after a mat2, do you really want that?
  • JG: Try to avoid warnings that would generate in reasonable code people would want to write. I guess the answer is if you get that warning and don’t like it you can put the padding in explicitly. Could be OK with that. This feels like a mistake I’d make.
  • CW: I think fixing it to be vec4 is better and should add the warnings. Otherwise there is weird validation. You can’t use this struct in a UBO and SBO at the same time unless you said matrix stride. Developers want type in UBO and SBO to work.
  • JG: Is that true with ther types?
  • DN: Other types align to vec4, as vec3 is vec4.
  • JG: What about mat3x2. Can’t think about row vs column major. Will write in issue.
  • KN: Someone suggested having a matrix_stride that is required and has one value just to make sure you know what hte value is. If we allowed and required on 2 and 3 sized things and didnt’ require on 4 size as that’s the most common and no ambiguity. So, if required on 2 and 3 may make sense.
  • JG: Good idea to explore.

Out-of-bounds clamping brings big perf regression on TFJS ML demos. #1202

[wgsl] Define the interface of an entry point in a WGSL program #774

Invariant qualifier #893

Proposal to enhance defining input/output variables. #1155

Placement of read_only attributes #1159

texture sampling with integer offset - portability concern #1206

should empty structs be permitted? #1222

WGSL: Use let instead of var? #1234

Clone this wiki locally