WGSL 2020 11 10

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

Tentative Agenda

Pull Requests

• WGSL: Begin drafting textureSample builtins (v2) (#1204)
• Add data packing builtin functions (#1189)
• Unpack builtins (#1196)
• Change SPIR-V memory model (#1216)
• Update storage textures to have template params for access type. (#1182)
• Add access qualifier to buffer types (#1183)

Open Issues:

• Proposal to enhance defining input/output variables. (#1155)
• WGSL: Proposal - square brackets for constructing an array (#1178)
• Restrictions on function parameters (#1139)
• texture sampling with integer offset - portability concern (#1206)
• WGSL: function parameters act like const declarations, not var declarations (#1171)
• Out-of-bounds clamping brings big perf regression on TFJS ML demos. (#1202)

---

📋 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: Begin drafting textureSample builtins (v2) (#1204)

• BC: Done what was asked last week, this is the expanded form where optional params are part of the method name. All comments currently addressed.
• DJ: Do people want to take another look, or merge as is? We can land once we get reviews.
• DM: Main concern, how flexible is non-comparison sampling from depth textures. Blows up the number of functions by a factor of 2 if same things as regular textures. Most usages are not practical. Depth can have mipmap but can’t interpolate, do you want bias? Non integer level. Don’t seem practical.
• JG: You could do nearest mipmap. Feels sorta silly.
• BC: For this PR pulled out all the ones that were controversial as it’s add to add new ones later.
• JG: Which were controversial?
• DM: The fp level and bias are the ones I pointed out. Maybe more. Overall, I think we can proceed.
• DS: I’m good
• JG: This is what we wanted.
• DJ: Wait for 2 ticks then hit go button.

Add data packing builtin functions (#1189)

• DJ: Resolved last week, then new comment from DN:
• DN: Was over confident in backend support. Checked MSL and SPIR-V but HLSL and D3D do not have direct mappings. Have 16->32 bit conversions. Wrote out translations but there is some arithmetic that needs to be done when translating to D3D.
• DM: Can we assume the builtins are faster?
• DN: Yes we can.
• DJ: Thanks for doing this.
• DS: So, question is there issue with emulated D3D or can we land?
• JG: In favour of landing. Builtins are there to surface functionality that’s at least as fast as doing it ourselves. If that’s what we have to do on HLSL that’s fine. As long as it’s faster in some cases.
• DJ: Then let’s accept.
• JG: YOu filed an issue for the fp16 stuff?
• DN: Yes.

Unpack builtins (#1196)

• DJ: Follows on, similar. Assume we accept that too.
• JG: This is the text?
  DN: Previous was pack, these are unpack with a blurb on why you might want to use them.
• DJ: For unpack 2x16 that’s the one metal has to emulate.
• DN: I forgot that one.
• DJ: Very last bullet.
• DN: Yea, directly use as type from packed half value. Fairly straightforward construction.
• DJ: Merged.

Change SPIR-V memory model (#1216)

• DS: I sent a new patch this morning, as resolved last week.
• DJ: Happy to land now, was pretty clear what to do.

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

• DJ: Continued from last week. DM has a straw-person. DN went back to first principles.
• DM: Wasn’t able to review DNs response yet.
• DN: The overarching part of argument is textures are opaque. Reason to use type isn’t to look into and manipulate the internals, the type is for selecting what builtins apply. Buffers are the exact opposite, they content is described by the struct type and a lot of machinery in the spec on that. The read-only-ness is attached to the storage that contains the data. More about the variable then the struct type. To me false economy to strive for consistency between the two. That’s the overall argument, but it’s a design choice.
• JG: That more formalizes what I was thinking last week.
• DN: Comes more to the for due to the other PRs from this week on alignment constraints and layouts. All about the struct type. Don’t want to have to list, or have in the developers mind, this is a uniform buffer, this is a RO storage buffer this is a WO storage buffer. A struct is a thing you can deconstruct in these operations.
• DM: In this case, having consistent decorations on the types would also work?
• DN: Probably. It would work, but it depends on whether you can pass a texture or pointer to a texture into a helper and have the same helper serve multiple kinds of textures. Like, querying the size in a function instead of stamping out multiple times for different texture kinds you’d use a single type and have qualifiers. Then rule that you have type matching on the param as long as you ignore these attributes. Get into game of having a list of adjoining rules based on qualifier instead of type. Not a great fan of that.
• DM: Didn’t we conclude we can’t pass textures into functions?
• DN: You can pass pointers to textures into functions I believe.
• DM: Is that something WGSL supports today?
• DN: We haven't written the function param docs yet
• DM: That’s the plan? User constructs pointer and passes to function?
  DN: Yes, pointer is the reference to the thing, in inout param basically
• DM: Do you have more details like what would htat helper function for the RO and WO textures do?
• DN: I don’t, I’m just cloning functionality. Don’t know enough about HLSL to know if permitted or desirable. If D3D closes this off we disallow it.
• DM: They aren different types in D3D so what you described isn't’ possible. Given most AAA games are HLSL, no-one would use that usecase.
• DN: You mean passing textures as params to functions or different kinds of textures?
• DM: Function that works with RO and WO textures.
• DN: Happy closing this off, so embedding RO into texture type is good. In template param or attribute on type. Aesthetically prefer in template params on type.
• DM: Except if we want it to be consistent with buffers, then it should be in decorations. Sounds like straw-person 1 is compatible with your principles given discussion.
• DN: Technically 1, it’s a lot of typing
• JG: Sort of disagree. Difference between operating on const T* vs T* or just reading from a const T*. For storage buffer, it feels like it should be a modifier to the type that you’re reading via. The struct type you’re viewing it with. I’m using this in a read-only sense. I don’t really like using it for textures that way. I want it to be part of the really real type, feels weird to use annotations like that.
• DM: Why do you want it part of the type?
  JG: because it is part fo the type
• DM: Up to interpretation. Can go either way
• JG: Can say it isn’t, but for matching definitions it’s part of the type checking rules.
• DM: Doesn’ effect the other types, just limits the functions you can call on it. Trivial to specify that.
• JG: Don’t follow.
• DN: Limiting what methods can apply to a texture type. That’s the only use of the type so you may as well embed it all in. For realsy reals.
• JG: If I was writing a program and wanted to restrict viable overloads I’d use the type system to do it, this is using the type system and also having this modifier.
• DM: It’s a trade off. We can make it a type but we’ll probably end up with both RO, WO and RW textures. So, that’s a lot of overloads. The spec maybe more complex if it’s part of the type. From a user perspective they won’t notice.
• JG: We have to define it anyway. You have to define somewhere it’s RW access
• DM: Just say, this set of functions requires this decorations. Don’t have to spell out how the grammar treats it.
• JG: Don’t have to spell out the grammar the other way. You have to specify it either way, regardless of the letters you use. Sounds like you’re saying it’s easier to spec the attributes because you can wave your hands and say use ro with readonly. Not really true you have to spell it out.
• DM: Main benefit is trying to be consistent. From the point of view of users, textures and buffers contain data they can try to mutate. Trying to be different on how you're going to mutate it is complexity that isn't needed. All things being equal, keep it consistent.
• JG: Don’t feel it’s all equal. In my head, translating RO is const which makes sense for storage buffers as you have a view into the const struct Foo. When reading out those inherit the const. With textures it’s const <texture handle> but those aren’t copyable or readable. So you can use the type system that way but it’s weird. It’s not really an access modifier on the texture handle.
• DM: I don’t get that. Writing the C++ system you’d do the same thing. Const texture and some methods would take const textures and others wouldn’t
• JG: Don’t think you would, this is the classic STL construct mistake. If you make the container const the contents are const as well but that isnt’ what you want. We have a texture which has const contents. The texture isn’t RO, it’s the contents of the texture which are RO.
• DM: User does not create a pointer here so they’re talking about the contents.
• JG: You're’ implying that
• DM: Users just declare a texture and use it, there are no pointers. RO isnt’ talking about opaque handles or pointers.
• JG: Not talking about that either, but the contents. Texture_storage_1d isn't’ the contents but using a type contents like it is. This is a texture containing rgb data that is read only or write only. You can draw the equivalency between the two, but that’s what the stl did and it was a mistake. This precludes us from having reassignable texture handles.
• DM: Ok, now you’re talking about assignable handles. This effects your explanation but not clear.
• JG: Falls out of how these things are different. Proposing we should do exactly and only what we need to do and not imply more constraints because it’s convenient now.
• DM: Is it implying more constraints? Aren’t they equivalent?
• JG: Only equivalent today. Saying if you have a const vector you can only read from it.
• DM: Don’t think using the decorations will stand in the way of assigning texture values if we want that happening. These are entirely different things. In the spec is const vs var which defines if it’s assignable.
• JG: But what is the access qualifier talking about. For Storagebuffer it’s a modifier to the type of the struct. You can only read or write to it. For Textures you can only read from this or write to this but it isn’t indirecting into it the same way.
• DM: It’s just data in GPU memory, same indirection
• JG: Core is using access modifier feels like making const vectors only read only. If you had a vector or container that was readonly and the contents become readonly. But sometimes you want a mutable pointer to const data and sometimes a const pointer to mutable data.
• DM: Don’t get the analogy, understand what you’re saying but dont’ think it applies
• JG: It applies here because it can't be misinterpreted. It could come back to bite us later. We should do exactly what we need here.
• DM: In rust, a const container means the data is const as well. Just a different paradigm. Neither applies to shaders
• JG: The container having the same modifier as the view into the thing you restrict what the language is able to do.
• DJ: Anyone else have opinions.
• DS: The var vs data explanation made the most sense to me when it was made
• DJ: Lets hold for next week
• DN: You may want the same struct type for a ro and rw buffer and would be silly to make the user define two different types which to me is why it’s attached to the variable.
• DM: As in duplicate the struct?
• DN: Yea
• DM: The strawperson doesn’t require that, it’s only defined once.
• DN: Ok.

Add access qualifier to buffer types (#1183)

• DS: Skip.

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

• DS: Skip it.

WGSL: Proposal - square brackets for constructing an array (#1178)

• BC: This is more important when we had named fields. Would make the gradient params which had a single param for 2 vec types. Having an array constructor in a common function call wasn’t great. No urgency unless people like it.
• DS: Post MVP.
• DJ: Yup.

Restrictions on function parameters (#1139)

• DJ: Discussed at F2F and some comments since then
• DN: Greg gave D3D info, common pattern to call helper and pass stuff in and come back out. Wasn’t sure what putter was for. For me, it’s explicitly saying it’s a ref. We have more info then before and that’s helpful. Next this will go to proposal to write something concrete we can argue about.
• DJ: Ok.
• DN: Will assign myself.

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

• DM: The problem is that when sampling with integer offsets if the mip level is not integer you may get undefined results or it says worse “Does not translate well to hardware” don’t know what that means. Was trying to figure out how other APIs handle, but couldn't find specific text referring to this issue. So, maybe we can get confirmation from Microsoft on that quote. And then possibly limit where int offsets can be specified.
• DJ: The question is what does “does not translate well to hardware” mean and should we restrict to only int mip level. Do we know what Vulkan and Metal do?
• DN: For VK would need to go read the Image Operations page of the spec.
• GR: Where did the quote come from? Wondering if old information?
• DM: Will post a link https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-to-sample in the description of the offset.
• GR: Don’t know enough to say, will ask TR but not sure if he’ll know. Sometimes docs are hard to pin down.
• JG: Is this talking about an inherent issue with applying to the hardware. What you want is combined fetch for optimization purposes? You may want to fetch a kernel around a sample point but can only give int offsets but not useful if sampling in between LODs as you can’t sample the kernel anymore, just doing a bunch of fetches from the filter points around where you’re pulling from. That’s what I suspect it means. You would be able to restrict this for explicit lods but not for non explicit lods. Don’t know if we can do anything here.
• DM: We could have the variants which take FP level as well as ones that take Int level and only the other ones would have offset.
• JG: Right but don’t we have versions with implicit LOD? Or is it only explicit LOD?
• DM: We do have implicit LOD options, yes. Maybe we just don’t get the offset ability to do with them? If you only have 1 mip level, then use the one you specify the mipmap level with the offset.
• JG: Inclined to have this be already true in all the languages and user beware.
• DM: Other question is how useful is non-integer mip level for these cases. If it serves no practical use then no need to follow native APIs to provide that ability.
• JG: Don’t think we can determine that. Looking at the GLSL builins there is support for everything. Feels like if everyone supports it and has this warning “texture fetch may not be what you want in all cases” i think it’s a useful comment to have.
• DJ: Where would you put the comment?
• JG: Honestly, in a best practices document. We could make a note about it in the spec if we wanted, but it’s a thing that’s inherently true with hardware and how we interact, not with our API per-se.
• GR: Just the expectation of how you’d use an offset within a mip level. You have more complicated sampling options. If you’re splitting between mip levels you’d expect that to require 2 offsets, so not something folks would do much.
• JG: We’re going to have ti for the implicit lod case.
• GR: In implicit LOD you probably dont’ want offsets as you’re doing something weird and you may get sub-optimal results.
• JG: Won’t be slower then doing it yourself.
• DM: We can’t fix the rasterizer. In this case, not exposing implicit lod of the function is the easy thing we can do.
• GR: Then they have to try hard for hte suboptimal behaviour.
• JG: Suboptimal on some hardware
• DM: Using on miplevel 1 they could use but then just use the texture function. Also faster as the texture unit doesnt’ have to compute the lod level.
• JG: Worry there are corners folks are using this, not in the steady state frame but linear interpolation between lod levels and using offset and want to keep same shader paths and you’re at an int mip level for a while and linera interp to the next mip level. But, in the middle your perf isnt’ great, but you now ahead of time and that’s fine.
• DM: Maybe post-MVP? We can always overload later.
• JG: More work to not do the thing. Default option is to do what all APIs allow. Doing this would scare them off something they may not want, but in other cases folks do want and they know about it.
• DN: Can add VK colour. The integer offsets are applied once for each level used in filtering. Will be done to both. Don’t know about 2 levels with same offsets will be weird, but it’s well defined in VK.
  • Vulkan: https://www.khronos.org/registry/vulkan/specs/1.2/html/vkspec.html#textures-normalized-to-unnormalized “This transformation is performed once for each level used in filtering (either d, or dhi and dlo). …. and where (Δi, Δj, Δk) are taken from the image instruction if it includes a ConstOffset or Offset operand, otherwise they are taken to be zero.”
• DM: Can we make an action item to spec metal and d3d 12 what the expectations are?
• GR: If they match what DN said?
• DM: Yup.
• DJ: Does someone want to take that?
• GR: I can look into it. Summarizing what DN said. You don’t get great results but it does work. Is there a form of that which is more specific which will change our opinion? Can look into it.
• DJ: Lets look into and keep it on the agenda.
• DM: DJ can you get Metal feedback?
• DJ: Yes.
• JG: Any other concerns we want to ask those folks about sampling stuff? What i expect to hear back is everyone will say it’s weird and we support it and probably not what you want to do
• DS: If we want folks to not do this we should push it post-MVP
• JG: We can’t decide folks are wrong to do that
• DS: Not what I’m saying
• GR: That’s what I’m saying, you can do wrong things in HLSL and you shouldn't do that
• JG: We shouldn’t restrict folks from doing things they could do before. Will write down example of usage.

WGSL: function parameters act like const declarations, not var declarations (#1171)

• DJ: Thou shall not change the value of a function param.
• DN: Yea, was always the intent that they’re const.
• DJ: Only feedback was that it’s unlike other languages but easy to understand when it happens.
• RM: Agree it’s much more reasonable to have the args as const and as noted in comment might make it easier to pass pipeline inputs directly as arguments.
• DJ: Anyone against? Accepted.

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

For next meeting

• 1202
• 1214 (dneto)
• 1215 (dneto)