WGSL 2020 11 17

Dean	:	🪑 Chair
Dan Sinclair and everyone	:	⌨️ Scribe
Google Meet	:	🗺 Location
https://webgpu.dev/wgsl	:	Specification
WGSL Issues	:	Open Issues
Marked Issues	:	Meeting Issues

Agenda

Pull Requests:

• WGSL: describe resource interface of a shader (#1214)
• WGSL: describe memory layout rules for buffers (#1215)
• [wgsl] Add access qualifier to buffer types (#1183)
• [wgsl] Update storage textures to have template params for access type. (#1182)
• describe texel formats (for storage texture types) (#1112)

Open Issues:

• Out-of-bounds clamping brings big perf regression on TFJS ML demos. (#1202)
• Proposal to enhance defining input/output variables. (#1155)
• should empty structs be permitted? (#1222)
• Considering making ARROW function_type_decl optional for void functions (#1219)
• Disallow implicit LOD texture methods in Compute shaders. (#1221)
• texture sampling with integer offset - portability concern (#1206)

---

📋 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
  • 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

WGSL: describe resource interface of a shader (#1214)

• DN: About resource interface. Describing uniform and storage buffers and different kinds of textures and samplers and how they are part of the shader interface that aren’t parts of pipeline Input/Output. They have binding attributes and have to line up with WebGPU API side. Getting text right. Looking at a static call tree, no two different variables can have the same pair of set/binding. That’s the non-overlap rule.
• DM: Raised a few questions
• DN: Binding, non-negative literal, asked if allows spec constants, not allowed in SPIR-V has to be literal. Vulkan requirement. Asked why listed storage buffers and uniform buffers as separate but not textures. Just editorial because I haven't described texture resource variables yet. Basically couldn’t refer to an existing thing yet. Will take a suggestion there. Describing the block attribute. Is a block decorated structure allowed to be used on a var in a function? Doesn’t happen in GLSL, technically permitted. Could go either way, blockness doesn’t have any effect just like layout doesn’t have effect anywhere except inside a uniform or storage buffer store type. Would be happy to restrict it to not permitted at all.
• DM: So, you’re saying can’t use block decorated but can still use the structured type inside a function. Reads like you can’t use the type, not the decorator.
• DN: Technically allowed in SPIR-V but do people use it?
• JG: Almost duck typing, could re-write the types each time.
• DN: Yea, could re-write. Restriction of a RuntimeTime sized array can only appear at end of a storage buffer struct.
• DM: So, you want to have this limitation for now and see if we need to relax later?
  DN: Yes. Only intended to say this thing describes the content of a top level bound buffer.
• JG: Could we make it implicit?
• DN: Today, yes. When we get to arrays of resources, it becomes muddy. A bindless future we want to be able to designate this, don’t want to change the meaning. Taking away now, and adding arrays of buffers in the future we’d need to invent some concept that means this.
• JG: Sure
• DM: Land it.

WGSL: describe memory layout rules for buffers (#1215)

• DN: Now that you have uniform buffers and storage buffers this is how you byte-for-byte data layout. Starts with motivation, because data transferred between host and gpu without translation so you need to know what's in each byte. Bottom up, integer, float, up through vec and mat and composites. Then alignment and offset/stride rules. Recursive definition because types are recursive. Also depends on the storage class because uniform buffers are special and more restricted. Bunch of tables that are the rules. Fully describe stride and offset constraints. Made offsets monotonic, early members in struct come earlier in memory. Easier to wrap your head around. Defines the allocation extent of a type which is when I say buffer has struct in it, it says how big the buffer must be on the API side or it’s invalid. Includes padding at the end. Taking base case where not allowing us to tuck a value in the very end. HLSL and scalar block layout allows struct { struct { vec3} float} to pack into a vec4. So the allocation extent includes the padding you’d need. Provides rules for binding validation at the command buffer size.
• DM: So includes 1 element of the runtime array at end.
• DN: Yes it does.
• DM: Would like to make a careful review but overall sounds great.
• JG: Are these the layout formats?
• DN: Yes, uniform is std140 and storage is std430
• JG: Would be good if that was non-normative text to state that intent.
• DS: Called something else in vulkan as well
• DN: Scalar, basic and extended alignment in Vulkan. Will put in a note for what maps to what in GL and Vulkan perspective.
• JG: Almost want to say we’re standing on things we know we’re standardizing on.
• DN: Want to capture intent.
• JG: Maybe say this is intended to be the same as …
• DN: Section at front with hand wavy place to say it, can put in there as a non-normative section. Will update and can revisit next week.
• DM: Does it need to come up next week?
• DS: After DM reviews can we just land?
• JG: As long as non-normative text is there I'm happy to have fixes after the fact.

[wgsl] rename set to group (#1218)

• DM: Quick thing, shouldn’t call it set in shader if group in API.
• DN: I’m happy with it.
• DM: Will have merge conflicts. Land 1214 first and we’ll rebase on top
• DS: And land this, yea?
• Resolved: Land this after 1214.

[wgsl] Add access qualifier to buffer types (#1183)

• DS: Discussed last week. I updated it. Hopefully people happy. Does not cover type aliases at the moment, but that should be enough. Allows us to progress with read only storage buffers.
• DS: Nicer than the previous way because it allows the same decorations.
• JG: I was always happier with this on buffers, so sounds good.
• DM: I thought Jeff moved the decorations out of the grammar. This puts it back.
• JG: I would have this not part of the grammar.
• DM: So “read” etc should not be part of the grammar?
• JG: Right. There is a different table that users need to put this in.
• DS: Do we have identifier identifier as a rule? Yes. So it just becomes variable declaration. I’ll make that change.
• DS: People happy with its location?
• JG: I think it is slightly weird that we have var storage… but I don’t want to argue on it now. You have this concept of variable type that has another type. What I’d expect is var buf1 = storage…. weird to have another templated var thing. I should address that separately.
• DS: 1182 (next) enlarges this.
• Resolved: DS will update to use variable declaration but otherwise good to land.

[wgsl] Update storage textures to have template params for access type. (#1182)

• DS: Same. Extended to allow storage textures. This was for consistency with storage buffers.
• JG: I don’t love it, but I’m ok.
• DN: Same.
• JG: I would prefer it as part of the actual type rather than a mandatory annotation. Might be better as templated parameters off texture storage. I still think there is a fundamental difference between textures and storage, and thus we don’t need consistency here.
• DN: Same thoughts, but happy to move forward.
• JG: Is the current state intolerable? Do we need this?
• DS: It’s ok with me. DM was the one wanting consistency.
• JG: I would prefer to not accept it. I would like to hear a more convincing argument.
• Resolution: Hold off for the moment to wait for more arguments. Reject if nothing comes in.
• DM: Why wouldn’t we merge if it adds consistency?
• DN: I think the consistency argument is not very strong.
• JG: If you don’t feel like it is true consistency then the change isn’t making things better. Maybe even moves the concept out of the type and into the annotation. Without consensus, then it is better to stick with what we have.
• DN: Grammatically it is consistent. Is it consistent with the host API?
• JG: No. We should talk offline. The case has not been made that this is an improvement in consistency.
• DM: I’ll add my argument to the issue.
• Resolution: Discuss next week.

describe texel formats (for storage texture types) (#1112)

• DN: About describing the texel formats so they can be used as a param when defining the storage textures. Break down what channel formats are and how you convert from the bits stored in the channel to values used in the shader. Various ‘transfer-functions’ todo the conversions. Clear when going from small value out ot large values, need to raise issue for the other way. Texel format names consistent with WebGPU API. Updated some of the text for storage texture types.
• JG: Why numbers in front of the encoding. Like, 32float is equivalent too. F32. Why isn't’ it float32?
• DN: Good questions, number separate channel name from channel type. Rgba32float. Same as in webgpu API.
• JG: Goal is it doesn’t look like rgbaunorm8, but rgba8unorm.
• DN: Yup. If WebGPU wants to change their names, we’ll change these to match. Not just a WGSL decision.
• DM: PR has a lot of good stuff and we should land.
• JG: My instinct as well.
• DS: So, resolution is land?
• JG: What’s the todo about eliminating formats not used in storage images, talk about it later?
• DN: Oh, in the grammar table? We have a bunch of formats like rgba8unorm_srgb is a format on the WebGPU api side but not used to define a storage image so we don’t need it in WGSL.
• JG: Can you alias it?
• DN: The channel transfer function is different
• JG: Sure. Works for me. Storage gives access to the bytes.
• DN: Yea
• JG: K, these need to be primiltives then
• DN: Editorial question, may want to move these definitions to WebGPU and reference from here. But to get going on storage images this is what you need to know
• JG: Should be possible to do operations on srgb formatted texture via storage textures.
• DN: But the values you get would be different
• JG: Probably? Don’t know enough about storage textures. When you access the r channel of an rgba8unorm what do you get? Between 0 and 1?
• DN: FP between 0 and 1.
• JG: Is the reason we dont’ have srgb that there isnt’ hardware support int he APIs?
• DN: Yes, I think that’s the case. The srgb transformation occurs in the sampler, attached to the sampler state so don’t have access in storage. If you copied those bytes from srgb to non-srgb you’d get values but wouldnt’ be correct. Any value between 0 and 255 would give a number
• JG: Right, like copying between fp16 and int16. Would be nice to allow folks using storage textures to write raw data without a copy. Way we’re supposed to do that is format aliasing. Which I think we’ve punted on for now.
• DM: We don’t have it yet.
• JG: I’m satisfied. Thanks for writing this.
• DJ: Thumbs up.
• DM: Since our access qualifiers are read/write should the functions be read/write instead of load/store?
• DN: Read/write is good with me.
• JG: Shouldn’t this include rg16float ?
• DN: Was not in WebGPU API table.
• JG: I’ll look into that, as I think we both want/can have it
• DM: We can’t. The table is result of large investigation, if it’s not there it’s not supported somewhere.
• DN: rg16float does not have a storage usage in WebGPU.

texture sampling with integer offset - portability concern (#1206)

• DJ: Metal team said this works exactly as specified and is something you’d never want to do.
• DM: Works exactly as specified, takes the same offset between different mipmap levels?
  DJ: Does exactly what says on tin and is well defined just happens to be never what you want with mips. <example>. Offset is in whole pixels in all mips isn’t what you want
• GR: Speculative reason this may give different behaviour is different hardware has different break points between mip levels. Test machine may work fine and another machine which breaks at a different point gives something wrong.
• DM: Was wondering about that, isn't’ it already a mipmap level? Could have different content?
• GR: If you’re using different images in your mip maps you get what you deserve. You could have mip maps where it’s a simplified version of the base level but can still mess up if the hardware doesn’t work as expected. This is a tangential argument, sampling from different levels and filtering/blending is a weird thing to do.
• DJ: So, question is do we accept that folks can do this and let them get different hardware doing different things, or do we make this an error or define what should happen?
• GR: I think there are good arguments on both sides. Can’t think of a reason you’d want to do this beyond the abstract, all the alternatives allow you to do this so presumably defvelopers are aware of issues
• RM: When talking about portability issues recommend being cautious, Easier to add things in the future we forbid for now rather than going the other way would be in favour of forbidding for now and if asked for we can give to them.
• JG: Seems difficult to constrain this well.
• DM: We have to have different function overloads. May as well have them have uint level and be done with it.
• JG: Doesn’t translate to uint in the api
• GR: If not using offsets, can use floats as the mip levels.
• DN: Would force every implementation to clamp? Don’t see a good reason to restrict. Could imagine a use for this. No-one has had a problem with this so far. Not standard thing you’d do with image filtering but no-one has issue. No reason to have perf issue injected to stop this thing.
• GR: Not that we convert from float ->int but rather have different sample function overload that takes the offset and as a result the mip level is an int. And disallow for mip calculated from derivatives.
• JG: all backends would have conversion from int -> float
• GR: Seems trivial.
• DN: Trivials add up
• JG: More ops.
• GR: Not arguing strongly either way. Having extra functions that take integers instead of floats leans me against that
• JG: Is this something implementations could warn about?
• GR: You don’t what value you get until you execute the shader
• JG: Might be able to tell in debug layer that the sampler attached to the texture op with offset and also the sampler has mipmaps and at draw time in a validation layer could connect those bits of info.
• GR: Combination of sampler or texture has mipmaps
• JG: Wacky, but dont’ want to force these conversion steps to enforce things on the user. Doesn’t matter in grand scheme of things, high overhead solution to stop folks from doing weird bit.
• GR: Offers are rarely used, so uncommon perf hit.
• DJ: From the metal team, not undefined behaviour. GR said possibly on different hardware give different results
• GR: Does metal spel define exactly how to select mip level?
• DJ: Does not.
• GR: Then undefined there as well
• JG: As defined as rest of texture sampling
• DN: Lots not as defined as would be liked.
• DM: Not sure what JG wants to avoid. Arguing implicit mipmap level for offsets? Don’t want the implicit levels there
• GR: That is part of this. Mip level derived from derivatives, there is an offset param to that, they’re related. You’re saying we should remove offset from standard sample which gets offsets from derivatives. Same issue.
• JG: I think DM wants to avoid for folks using implicit derivative miplevel can we keep them from implicitly doing the wrong thing?
• DM: Doesn't’ seem usable and would be an extra overload of the function.
• JG: Just works though? Not hard to implement and everyone implements. UAs that don’t like it can complain about it.
• GR: Easier to make an mistake there as you aren’t saying this float is the mip level and offsets are integers. Maybe a reasonable way to look at it.
• JG: Feels a little too hand holdy of the API. We’re trying to balance user wants and what they think they want. Feel this comes down too far on side of user asked for it, and defined in native APIs and defined/works and D3D recommends against it, but it works.
• GR: Maybe something more confusing might push one way or other. HLSL has sample ops that allow derivatives to give mip level. Where would we lean on that if trying to avoid offers with implicit mip level
• DN: Think we should allow, interesting question is how clearly can we test. If implicit derivatives have fuzzy output dependencies, how well can we test it? If we can test it well we should permit it.
• JG: Testing some of this is novel work.
• GR: How well can you test undefined behaviour
• DN: Fuzzy ness comes from tolerance of output filter sampled result depending on the gradient.
• JG: Can bound it right, know what sample is at integer offsets. At some point between offsets there is some actual threshold where it chooses one or other. That part is teh part that’s implementation defined and we don’t know where it is. But, probably consistent for that system. I think this is testable. Test has to be done carefully. Will need to run on lots of hardware to not implicitly assume threshold is some offset.
• DJ: Would like some kind of decision
• GR: Easiest decision is allow as everyone does.
• DJ: Circle back next week.

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

Proposal to enhance defining input/output variables. (#1155)

should empty structs be permitted? (#1222)

Considering making ARROW function_type_decl optional for void functions (#1219)

Disallow implicit LOD texture methods in Compute shaders. (#1221)