Skip to content

WGSL 2020 05 26

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

:

 Chair
Mehmet Oguz Derin

:𐰆𐰍𐰔 :

 ⌨️ Scribe
Google Meet

:

 Location
https://webgpu.dev/wgsl

:

 Specification
WGSL Issues

:

 Open Issues
Marked Issues

:

 Meeting Issues

Tentative Agenda

  • vec4 is too hard to type on the keyboard (#736)
  • Updating loop section to include for (#757)
  • Workgroup Size builtin decoration restrictions. (#750)
  • Requiring integral-valued float literals to have .0 seems gratuitous (#739)
  • Add .rgba aliases to .xyzw (#754)
  • Assignment of swizzled values should be permitted (#737)
  • WGSL should have a shuffle builtin function (#748)
  • type foo = struct is unfamiliar (#735)
  • Task: Define pointers (#672)
  • Remove break if in favor of if () { break; }. (#643)
  • Allow e.g. if (cond) break/continue/return/kill; without brackets. (#705)
  • Explicit layout needs more than Offset: ArrayStride and matrix attributes (#773)

📋 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
  • Lukasz Pasek
  • Pelle Johnsen
  • Matijs Toonen

📐 Meta

  • DJ: David pointed out that we need some way to indicate that an issue needs work before it can be discussed at the meeting. How about a “Needs Action” label?
  • KN: In the main group we use the first (left) column in the project for this.
  • DN: OK by me.
  • DJ: Resolved. Let’s do that.

⚖️ Discussion

vec4<f32> is too hard to type on the keyboard (#736)

  • MM: Talking to internal teams about WGSL and a request was the vector syntax is too hard to type. Three numbers and 2 shift key presses. Having one digit separate different types is difficult to see. Proposal is to add built in aliases, float4, half4, int4. Then authors can pick which one they wish to use.
  • DN: So, requesting a set of aliases to the existing mechanism?
  • MM: Yes. Originally wanted to change the names, but willing to fall back to adding aliases.
  • DN: That takes away the extensibility float. If we have bfloat16 in the future, then if we have to use the general mechanism then that’s ok. Standardizing the size of int and uint was a good thing in Java.
  • DS: I don’t mind the aliasing thing, but we should be cautious about th words we use e.g. float, short. It might introduce the inconsistency with using things like f32 and i32 everywhere.
  • MM: Makes sense. Two options, swallow that or introduce more aliases. Either are ok.
  • DS: I don’t know which I prefer.
  • JG: Hopefully in practice we are not writing those two often because we have inference.
  • [multiple people saying we are very close to inference but there are still issues open]
  • JG: With inference you’re not typing it too often so it isnt a big deal. Aliases for float4 seems fine. Slight concern about people not realising what that means.
  • DS: What do people feel about float, int, char, etc vs what we have now?
  • JG: I do not think we should have the historical names, but maybe float4 is ok. New types won’t get the aliases.
  • KN: Agreed. I would like to add that we should stay away from “long”. Means 32 or 64 depending on where you are. “int” seems to pretty consistently mean 32.
  • DS: Myles, if we had a limited set of these would that be enough?
  • MM: Right now we only have 32-bit types… I would propose vec2, vec3, vec4
  • DS: What about new types?
  • MM: Discuss those when we get there?
  • KN: Might as well do it now?
  • MM: So we have a proposal for float16s, I think they would be in vectors… so that would be float4 and half4.
  • KN: I’m ok with that, less ambiguity with floating point sizes
  • JG: Need to be careful to to distinguish between common and popular… I think by the time we get to vectors of half-float, then that is rare enough to make people type it out in full.
  • MM: What about just doing it for integral types?
  • JG: I see what you’re getting at, but I think we should just cheat and say int4.
  • MM: I think half4 will be more common than int4.
  • DS: I think if we accept this, then we only really need it for the float vectors (float and half). They would be the more common ones, do you think?
  • JG: I’m not sure we know. Especially since half is an extension for us. I’m ok with us typing more code for an extension.
  • KN: I think we should err on the side of fewer aliases.
  • KN: I’m not that opposed to having float4 and f32. But it isn’t that hard to use the GLSL style and use “ivec4”, “fvec4” etc
  • MM: I just looked in my HLSL corpus… float4 is 20x as common as int4.
  • KN: Half storage is useful on mobile, but half computation is also useful on desktop.
  • JG: In the last three years we’ve seen hardware with dedicated half precision computation.
  • GR: Very wishy-washy and hand-wavey. We’d like to convince everyone that it never happened. (w.r.t. precision)
  • JG: Going back to Kai’s proposal for naming… makes sense.
  • DS: I like it.
  • DN: There is an extension for GLSL that adds explicit width types with all these names. Putting it in chat. e.g. f32vec4. https://github.com/KhronosGroup/GLSL/blob/master/extensions/ext/GL_EXT_shader_explicit_arithmetic_types.txt
  • KN: Here we’re are trying to make convenient shortcuts
  • MM: I’m ok with fvec4 but I would like hvec4 too.
  • JG: But it is in an extension.
  • MM: Reserve the keyword.
  • DS: We should reserve them all in advance.
  • KN: Just reserved type names.
  • DN: What if people what to type alias them before do?
  • JG: If we do it now, they should get a warning.
  • DS: That’s why we need to reserve them now.
  • MM: Could we say that redundant type aliases are valid?
  • JG: People might not do that.
  • DM: If they are part of the grammar it would just stop compilation…
  • JG: It would mean that we can’ t introduce e.g. svec4 without an extension.
  • MM: General point… not specific to this topic. We will add more types.
  • KN: I think it would be cool to reserve a list of type names, but also say what they are. If you type alias them you must do it to what we say. So they are not initially visible, but it would be an error.
  • JG: Could we make it just a warning if it is a redundant alias?
  • KN: If we didn’t add dvec4 now, how could we make it an error?
  • DS: We put them in a namespace now, and require people to import the namespace and a mechanism to use them without the namespace prefix. e.g. using std
  • KN: We don’t add them to the prelude, since that will always be breaking.
  • MM: I think namespaces are awesome and we should have them. But does this solve the problem? e.g. they define the name, and include std, and then we add it to std… still an issue.
  • DN: Break it down into smaller namespaces. Not just “std”. Make a new prelude.
  • KN: That’s right - add a new namespace.
  • MM: Won’t that cause infinite namespaces?
  • JG: It’s a finite amount of work.
  • MM: But doesn’t it require us to all ship at the same time?
  • JG: Only if you want to use it.
  • RM: We could also have imports that bring other imports along with them. e.g. std2025 includes std2024.
  • DS: Summary of where we are:
    • Add the namespacing mechanism
    • ivec4, bvec4, fvec4 dump into that namespace
    • allow that namespace to be imported
    • something like “using” to allow the namespace to be used without prefixes
  • DS: Would that work for you Myles?
  • MM: Too hard to answer now. We’d need to take a look.
  • GR: Another possibility is a #pragma (e.g. give me vec types)
  • KN: That’s basically extensions.
  • DJ: Could we take Dan’s proposal and give Myles a week to provide feedback?
  • MM: Yes.
  • GR: Does this mean we’re adding namespaces?
  • DS: We already have namespaces.
  • MM: IIRC we have an outstanding resolution to change what we are importing with namespaces. We need meaningful names.
  • DN: That was about partitioning into modules, not about the mechanism. There are several good working models that we should follow.
  • DM: In Rust, global import is discouraged. Should only be used in testing. Not everyone wants us to include the whole prelude.
  • DN: Google’s C++ coding style discourages blanket “using”.
  • DM: I would also like someone to explain how this will work with extensions.
  • DS: In my mind, part of the extension would describe how the aliasing works in its own namespace.
  • MM: I think that needs discussion.
  • DS: Just what is in my head right now.
  • MM: Hearing some enthusiasm for adding namespaces and aliases.
  • DJ: I suggest:
    • Myles take Dan’s summary above and write it into the issue
    • Myles provides feedback on that summary (by next week)
    • Kai adds his comment to the issue
  • MM: OK.
  • DN: Issue #600 has discussion on the general mechanism.
  • DN: https://github.com/gpuweb/gpuweb/issues/777 is for namespaces

Updating loop section to include for (#757)

  • MM: In the syntax the loop initializer should allow assignment and the increment doesn’t have to be an assignment statement, should be able to be a function call. Dan proposed adding different types of statements in the loop clauses and this proposal is acceptable.
  • https://github.com/gpuweb/gpuweb/pull/757#discussion_r421484430
  • DS: I didn’t know you’d accepted it, so hadn’t done the work to update it.
  • DS: I’ll update and put it up for review.

Workgroup Size builtin decoration restrictions. (#750)

  • DS: I misunderstood DN’s table and said you could add Workgroup Size. The way it is in the spec right now will not work. It needs to be a constant.
  • MM: SHould be part of another issue, where the decorations should be on the entry point.
  • DS: Makes sense.
  • DN: Has anyone asked how to modify the workgroup size?
  • MM: I think it has to be fixed because of D3D, can someone verify this? Repeating question, is it possible to change the workgroup size in the D3D API, as opposed to the text in the shader.
  • GR: I believe the answer is no.
  • DM: As long as we know at pipeline creation time we can put it in the shader. We discussed this a while ago in the context of some workgroup sizes don't work in some hardware and we’ll get a pipeline creation error. Did some investigation but didn’t find an answer. Don’t know how to make it guaranteed to not fail.
  • DN: In OpenCL you wont’ know about that error until you try to compile the kernel. Need compiler generation information to determine
  • MM: PIpeline creation time as opposed to shader module creation time.
  • DS: We need to remove the bit of the spec which says you can attach workgroup size to a variable, since it won’t work. It should then be merged into the entry point decoration discussion.
  • [general agreement]
  • JG: In the spirit of keeping our options open, we should think about if we could do it via a specialization constant, for example, in the future.
  • DN: I believe that HLSL -> Vulkan does it via specialisation constants.
  • MM: I heard that you can put an attribute on a root constant to indicate the value will never change. I believe all three apis have some affordance for specialization constants.
  • JG: I feel like workgroup size is a place where you would want spec constants.
  • MM: Oh, for D3D it is only for data.
  • DJ: Resolution - do what Dan said above (remove this from the current spec text and resolve it as part of the entry point).

Add .rgba aliases to .xyzw (#754)

  • MM: Pretty common to use .rgba instead of .xyzw. Colours are usually vectors, so more natural to write that. We already have multi-component swizzles so infrastructure is already there. Would just be more multi-letter swizzles. I.e. a member of a type that doesn’t appear in the type, created by the compiler
  • GR: One compilation, you can’t mix and match right?
    MM: Right
  • JG: We could …
  • DN: Let’s not allow that
  • MM: We’ll add tests and add normative text that it’s a compile error if you mix and match rgba with xyzw.
  • DS: Tint already supports xyzw and the stpq one. I didn’t realise they were not in the spec.
  • MM: Never seen the stpq used, so happy to not have them.
    • DM: v.xyrb is bad but (v.xy).rb is good?
    • MM: Yes
    • KN: Yes
    • GR: Yes
  • GR: There were GLSL calls, but were they swizzle names?
  • JG: Yes, there were 4 types. (missed what they were)
  • KN: Agree with rgba and xyzw and no stpq..
  • DM: What about matrices. Are swizzles ok with matrices?
  • MM: I say no, because people don’t put colors in matrices.
  • GR: If you have a matrix of vectors, and are accessing the data in a cell, sure. But should not be able to access rows/columns via swizzling.
  • GR: If you want an array of vectors of colours - use an array, not a matrix.
  • DN: In GLSL 4.5 swizzles only apply to vectors.
  • Resolution:
    • rgba and xywz
    • they mean the same thing
    • no to stpq
    • you can’t mix the swizzles e.g. rybz is a compilation error
    • vectors only
Clone this wiki locally