Add the uniformity analysis to the WGSL spec by RobinMorisset · Pull Request #1571 · gpuweb/gpuweb

RobinMorisset · 2021-03-29T19:06:29Z

This is spec text based on my previous uniformity analysis for WSL, you can see the previous version at:https://lists.w3.org/Archives/Public/public-gpu/2019Jul/0000.html (and the detailed version in the doc at the bottom of that email). The main difference is adding support for "discard", which somewhat complicates things, but still slots reasonably well into the overall framework.

The analysis currently does not support pointers (since it is a part of the spec that is still in flux). When we do add pointers, every read of a pointer will be considered non-uniform, and every taking of the adress of a variable will make that variable non-uniform (improvable later if it proves crippling, but it would be fairly complex).

It has a couple of other limitations:

It cannot infer the uniformity of global variables, so it currently assumes that none of them is uniform. We can easily improve it by adding an annotation on global variables, declaring them as uniform. In that case, we would check that every store to them is uniform (preserving soundness), and consider every read of them to be uniform.
It does not split the lifetimes of variables. What I mean by that, is that if there is any non-uniform store to a local variable, then every read of that variable will be considered non-uniform as well, even those that happen before the store. Correcting for that in the context of loops would be extremely painful, and I don't consider this limitation particularly major (in any case where it bites the programmer, they may easily split the variable into two).

There are still a couple of TODOs in the uniformity section of the spec:

One about the treatment of infinite loops, I will do more research on that
One about double-checking the rules for loop. I will test them on a bunch of examples in the next few days as I add tests to the test suite.
One about the list of functions in the standard library that have interesting uniformity requirements. This one should be straightforward to fill.

I am very interested in getting feedback on this PR, both on the analysis itself and on its presentation. I've tried to explain it as clearly as I could, but I realize that I probably failed in quite a few places; I've just spent long enough working on this that I don't know which parts are hard to understand.

Preview | Diff

github-actions · 2021-03-29T19:12:03Z

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
_c6cf71b

litherum · 2021-03-30T05:37:53Z

wgsl/index.bs

+
+### Uniformity analysis overview ### {#uniformity-overview}
+
+In this section we specify an analysis that verifies that functions which are only safe to call in uniform control flow (barriers and derivatives) are only called in such a context.


"e.g." barriers and derivatives

litherum · 2021-03-30T05:38:44Z

wgsl/index.bs

+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.
+An expression is said to be uniform if it is in uniform control-flow, and all invocations compute the same value for it.
+The location of a local variable is said to be uniform, if all invocations have the same value in that variable at every program point where it is live.


Do you really mean "location" of a local variable? Why not just a variable?

I'll try to replace it with just variable, I can't remember why I went with the more complicated phrase.

litherum · 2021-03-30T05:40:55Z

wgsl/index.bs

+      - If the analysis refuses a program, it provides a straightforward chain of implications that can be used to craft a good error message
+</div>
+
+The analysis analyzes each function in turn, verifying that there is a context where it is safe to call this function (otherwise it rejects the program), and computing metadata about the function to help analyze its callers in turn. This means that the call graph must first be built, and functions must be analyzed from the leaves (functions that call no function outside the standard library) upwards (toward the entry point), so that whenever we analyze a function we have already computed


Nit: there are a lot of parentheticals here. I think reading them is required to understand the paragraph, so they should be promoted to regular prose.

thanks, will fix.

litherum · 2021-03-30T05:41:34Z

wgsl/index.bs

+</div>
+
+The analysis analyzes each function in turn, verifying that there is a context where it is safe to call this function (otherwise it rejects the program), and computing metadata about the function to help analyze its callers in turn. This means that the call graph must first be built, and functions must be analyzed from the leaves (functions that call no function outside the standard library) upwards (toward the entry point), so that whenever we analyze a function we have already computed
+the metadata for all of its callees. There is no risk of being trapped in a cycle, as recurrence is forbidden in the language.


Why is there a newline here? (Throughout the rest of this PR, you seem to be putting paragraphs on single lines, except for this one specific place.)

It might be valuable to use the term "topographical sort" to make this more clear

The newline is just an accident. Explicitly using the term "topographical sort" is a good idea, I'll add it.

litherum · 2021-03-30T05:44:03Z

wgsl/index.bs

+The first phase walks over the AST of the function, building a directed graph along the way.
+The second phase explores that graph, resulting in either rejecting the program, or computing the constraints on calling this function.
+
+Note: Each vertex in this graph corresponds either to the statement "The control-flow at a specific program point must be uniform" or to "The value of a specific expression must be uniform" or to "A specific variable must always hold a uniform value" or is one of the special vertices True and False.


What does "corresponds to" mean here? Does it mean that each vertex holds log2(5) bits of state? Or does each vertex actually just hold 1 bit of state, and the meaning of that one bit is different depending on what kind of AST node it corresponds to?

Also, paraphrasing each of these 5 values, I see:

Something must be uniform

Something else must be uniform

A third thing must hold a uniform value

true

false

So how does a vertex indicate the possibility of non-uniformity? None of the states (except for "false") seem to be able to describe that.

"Corresponds to" means "here is how I think about the meaning of this, and why the rules look like they do". The vertices hold no information, they can be represented by a single integer, and edges are just pairs of integers.

Something having to be uniform is indicated by having a path from True.
Something that cannot be guaranteed to be uniform is indicated by having a path to False.
I will try to make it more explicit.

litherum · 2021-03-30T06:06:17Z

wgsl/index.bs

+
+TODO: do we need an extra behavior for possibly infinite loops? I should check whether some form of reconvergence happens after something like `while(tid mod 2) {}`.
+
+If the set of behaviors for a statement is a singleton, we take that to mean that reconvergence happened, and we pick the vertex corresponding to control-flow at the start of the statement as the vertex corresponding to control-flow at the exit of the statement, overriding the other rules below.


Should we be using words like "we" in a spec? Maybe instead of "we take that to mean that" we should instead say "this means that"

good point, will fix.

litherum · 2021-03-30T06:13:58Z

wgsl/index.bs

+
+### Uniformity rules for function calls ### {#uniformity-function-calls}
+
+The most important and complex rule is for function calls:


Should we really be ascribing importance to individual rules? It's certainly the most complex, but "important" seems like a value judgement.

Right, I guess for a spec it might be inappropriate phrasing. I'll try to rephrase it.

litherum · 2021-03-30T06:17:15Z

wgsl/index.bs

+      <td>
+      <td class = "nowrap">*CF*, *s1* -> *CF1*, *B1*<br>
+          *CF1*, *s1* -> *CF2*, *B2*
+      <td>*B1* \ {Nothing} U *B2*


Can we use the actual Unicode characters for these operations?

U+2229 INTERSECTION

U+222A UNION

U+2208 ELEMENT OF

U+2209 NOT AN ELEMENT OF

U+2216 SET MINUS

U+2205 EMPTY SET

U+2282 SUBSET OF

https://www.unicode.org/charts/PDF/U2200.pdf

Yes, I took the shortcut of staying with ascii, but I probably should replace all of these. Thanks for the link.

E.g. ∩ -> ∩? Fancy!

https://www.toptal.com/designers/htmlarrows/math/
∩ ∪ &xcap; &xcup; ∈ ∉ &setminus; ∅ ⊂ &nsub; &sube; &supe; &nsup; ⊃
∩ ∪ ⋂ ⋃ ∈ ∉ ∖ ∅ ⊂ ⊄ ⊆ ⊇ ⊅ ⊃

litherum · 2021-03-30T06:24:08Z

wgsl/index.bs

+<table class='data'>
+  <caption>Uniformity rules for statements</caption>
+  <thead>
+    <tr><th>Statement<th>New vertices<th>Precondition<th>Behaviors<th>Resulting control-flow vertex<th>New edges


for loops don't seem to be listed here. We should either
A) Describe the desugaring in a more robust way in the "for statement" section of the spec, and link to it here
B) Add a row in the table for the for loop.

I got confused by the "new vertices" column heading of the chart, because the "resulting control-flow vertex" is a new vertex, but doesn't appear in the "new vertices" column.

I'm having trouble understanding the "precondition" column. Above, you say

In the table below, CF1, S -> CF2, B means "run the analysis on S starting with control-flow CF1, apply the required changes to the graph, and name the resulting control-flow CF2, and the resulting set of behaviors B".

And these CF1, S -> CF2, B rules are inside the "precondition" column of the table. How can a precondition involve running an analysis and modifying a graph? I always thought a precondition was just a claim that either is true or untrue, and didn't modify state or anything.

I did not list the rules for "for" loops, because they are supposed to desugar to "loop".

The "resulting control-flow vertex" may be a brand new vertex (in which case it will also be in the "new vertices column"), but it may instead be the result of the application of a rule on a sub-expression.

You are right that "precondition" is a bit of an abuse of language here, I should not have kept it from more conventional type systems. Maybe "recursive analyses" or something like that is a better name for this column.

litherum · 2021-03-30T06:39:27Z

wgsl/index.bs

+          *CF1*, *s1* -> *CF2*, *B2*
+      <td>*B1* \ {Nothing} U *B2*
+      <td>*CF2*
+      <td>


How can there not be a new edge between s1 and s2 in s1; s2? I think I'm missing something fundamental here.

Oops, there is a typo here: it should be *CF1*, *s2* -> *CF2*, *B2* on the second line, I accidentally repeated s1 instead of s2.

I guess it did not help with understanding, sorry. To further clarify things:

s1 and s2 are statements, not vertices in the graph, so it makes no sense to have edges between them.

the first line says that CF1 is the vertex corresponding to the control-flow at the exit of s1.

the second line says to then use it as the control-flow at the entrance of s2, and name the vertex corresponding to the control-flow afterwards CF2

so we don't need to explicitly create a new edge here, because the rules for *CF1*, *s2* -> *CF2*, *B2* must already have made a path from CF2 to CF1, since we cannot have uniform control-flow after s2 if it was non-uniform before it.

+1 The way I'm thinking of it is that each statement generates two nodes in the analysis graph, essentially a precondition and a post-condition. So the two lines express CF1===Post(s1) === Pre(s1) and so the path in the analysis graph is CF -> CF1 -> CF2

litherum · 2021-03-30T06:46:12Z

wgsl/index.bs

+  <tr><td class="nowrap">loop {*s1*}
+      <td>*CF'*
+      <td class="nowrap">*CF'*, *s1* -> *CF1*, *B1*
+      <td>*B1* \ {Break, Continue} U {Nothing}


Are you sure that loop should U {Nothing}? Control flow will always enter the loop, and it can't exit without a break or a return or a discard.

You are correct, I took that part from the rules for while, which can exit whenever the condition is true.
The more precise behaviors here should be B1, removing Continue, and replacing Break by Nothing if it exists.
I'll make the change in the next commit.

RobinMorisset · 2021-03-30T06:49:17Z

Thanks a lot @litherum for all of these comments! They inform me of which parts need some clarification.
I'll answer all of them tomorrow morning, but will try to clarify a few things inline right now.

litherum · 2021-03-30T07:06:46Z

Instead of "true" and "false" we might want to use "definitely uniform" and "possibly nonuniform"

RobinMorisset · 2021-03-30T07:21:31Z

Instead of "true" and "false" we might want to use "definitely uniform" and "possibly nonuniform"

This is almost what I had in a previous version of the analysis. I picked True/False to make the analogy between edges and logical implication clearer, but I can easily reverse this and go back to these names.

dneto0 · 2021-03-30T17:43:00Z

Before getting into the heart of the analysis:

data in var<uniform> is always uniform because it's the same variable shared across all invocations in the entry point, and a read-only storage class
samplers, and sampled textures have the same properties

Also, right now WebGPU is guaranteeing (i asked long ago) that there is no aliasing of storage locations across resource variables. That's probably implicitly assumed by the analysis.

For infinite loops: I think the standard thing to say is that no semantics is defined for the program if it loops infinitely. Shaders are assumed to finish in finite time; in real life operating systems intervene to kill runaway processes, which pragmatically speaking is the same.

I'd be interested to see if the analysis allows an interesting example such as @toji 's clustered-forward shading example: https://twitter.com/tojiro/status/1344409446802362372?lang=en and live page here

kdashg · 2021-03-30T18:31:23Z

wgsl/index.bs

+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.
+An expression is said to be uniform if it is in uniform control-flow, and all invocations compute the same value for it.
+A local variable is said to be uniform, if all invocations have the same value in that variable at every program point where it is live.


I think this is a little misleading, since it's not "same value" really, but rather the value is dependent on the same control flow in all invocations.

Something must be said about what "all invocations" mean here. Is it "all" through the draw/dispatch? "all" in the current scope? Or even "all" as in all active at any point within the wave?

I disagree with @jdashg's comment here. The way I use the term, a variable can be in uniform control flow and be non-uniform because it has different values across the scope of the uniformity. I would argue this definition because it is useful. If a control flow construct depends on a non-uniform variable under my definition, the control flow will be non-uniform. To express that in a definition where uniformity of a variable depends on the uniformity of its control flow, we would have to redefine a characteristic of variables to plug into that statement.

Furthermore, the uniformity of a uniform buffer concerns the persistence of its values across a broad scope. The same should apply to defining a variable as uniform.

alan-baker

From the 2021-03-30 meeting, I was asked to link to Vulkan's scoping definitions.

Vulkan defines invocation group as workgroup if that is a defined concept, otherwise it is the command. See https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#shaders-scope-command

For shaders without defined workgroups, this set of invocations forms an invocation group as defined in the SPIR-V specification.

SPIR-V only defines uniform control flow (i.e. divergence and reconvergence) in terms of invocation groups. See https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#UniformControlFlow.

wgsl/index.bs

alan-baker · 2021-03-29T21:39:41Z

wgsl/index.bs

+The following definitions are merely informative, trying to give an intuition for what the analysis in the next subsection is computing.
+The analysis is what actually defines these concepts, and when a program is valid or break the uniformity rules.
+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.


Even informatively I would avoid saying lockstep execution occurs. Also, I think the invocations need scoped. For compute each workgroup defines uniformity. For other shaders I'd lean towards what SPIR-V defines as an invocation group (though this may prove to be to restrictive).

For purposes of utility, I would define uniform control flow as being control flow that depends on values certain to be the same over the defined scope of uniformity. The programmer doesn't care if they are executed in lockstep or not. It's not strictly relevant to the restrictions this introduces. Rather than having to define how hardware works, let's define how you can write a program that trips it up.

alan-baker · 2021-03-29T21:52:46Z

wgsl/index.bs

+
+<table class='data'>
+  <caption>Uniformity rules for expressions in lvalue positions</caption>
+  <thread>


Suggested change

<thread>

<thead>

thanks, fixed.

alan-baker · 2021-03-30T00:53:30Z

wgsl/index.bs

+      <td>*B1* \ {Nothing} U *B2*
+      <td>*CF2*
+      <td>
+  <tr><td class="nowrap">if (*e*) then *s1* else *s2*


I assume this chains for elseif, but it would be good to include.

dneto0 · 2021-03-30T20:08:44Z

First discussion in meeting of 2021-03-30

kdashg · 2021-03-30T22:13:10Z

WGSL meeting minutes 2021-03-30

AB: Misunderstanding of the proposal. Expected “there are some things that originate non-uniform values or behaviors” but don’t see that addressed. E.g. some builtins are definitely uniform and others definitely non-uniform. Eg. group ID value, invocation ID value. Is this more conservative than I thought?
RM: Have TODOs to fill in for different builtin functions. The analysis is about propagating the facts through a view of the program. But can change the inputs / leaf facts as needed.
AB: Looking at behaviours of a function body. If neither Nothing or Return, then reject the program. But each loop that terminates must have a Break; so anything with a loop is rejected.
RM: When you exit a loop, you remove the “Break” from the set of behaviours, and replace it with “Nothing”. Will address by separating the prose.
AB: I think I get the intent. The discard one confused me. The only behaviour is Discard, or Return. Is a singleton of behaviours allowable, as long as each invocation has the same behaviour.
RM: Yes, a singleton would be accepted. If there is a singleton behaviour for a function, then the behaviour after the call site is the same as the behaviour before the call site: either all the invocations are still there, or none of them are.
RM: Idea is if you have a single behaviour for a compound statement (or function body), then the convergence property after the end of that statement is the same as at the beginning. Will try to add examples, and check against the test suite.
MM: Examples would have helped reading through.
MM: Bikeshed has a mechanism for marking a section as an example; examples are non-normative.
DM: does the PR allow private variables to be uniform?
RM: Currently all globals are considered non-uniform. DN pointed out some kinds of module-scope variables are uniform.
Discussion: sampled textures are uniform. Storage textures are pointers
Need some things to be clarified editorially; RM to continue edits. Direction is good.
AB: Need to define the invocation group.
DM: For vertex shader it doesn’t matter.
AB: Yep. For a fragment shader, it gets complicated.
JG: Is invocation group an entire draw call? That’s what it brings to mind, but maybe it’s the raster group.
AB: Will look it up.
MM: Does it affect the analysis for today’s WGSL? Sure, it may when adding features.
DM: It affects flat-interpolated floats.
GR: Derivatives don’t care about the full group; it only cares about the quad.
AB: SPIR-V / Vulkan doesn’t guarantee reconvergence of the quad after a prior divergence. So it’s more than just the quad.
JG: If interested in the content, tag yourself as a reviewer. Wait on merging until all the reviewers have had a chance to review. Expect to be permissive: don’t expect it to be perfect.
RM: Feel should wait at least one week. Hope to do the first round of edits by office hour tomorrow; may confirm builtins lists in office hours tomorrow.
AB: Checked Vulkan spec: invocation group for a fragment shader is the whole draw.
- DM: Please post the reference.

dneto0

I only partially reviewed this.
Sending this review now because it has actionable feedback, particularly on request for clarity of what's being modeled.

dneto0 · 2021-03-30T17:46:41Z

wgsl/index.bs

+The following definitions are merely informative, trying to give an intuition for what the analysis in the next subsection is computing.
+The analysis is what actually defines these concepts, and when a program is valid or break the uniformity rules.
+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.


Wording: "lockstep" is the wrong word here. Let's work on this as an editorial fix.

dneto0 · 2021-03-30T17:48:44Z

wgsl/index.bs

+The analysis is what actually defines these concepts, and when a program is valid or break the uniformity rules.
+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.
+An expression is said to be uniform if it is in uniform control-flow, and all invocations compute the same value for it.


This is stronger than I'm used to: I'm used to "all invocations compute the same value for it".
But maybe it amounts to the same thing?
Is there extra conservatism added because of requiring it to be in uniform control flow. Is it for simplicity of analysis/ diagnostics?

It makes sense to me. How would you say "all invocations" without implying the uniform control flow?

I think the only reason we need to define whether an expression is "uniform" is so we can place limits on what operations are in it. For this reason, we only care if it is in uniform control flow. These expressions might produce different results and still be in uniform control flow, that doesn't mean you can't use the uniform control limited operations in such expressions.

dneto0 · 2021-03-30T17:49:38Z

wgsl/index.bs

+
+### Uniformity analysis overview ### {#uniformity-overview}
+
+In this section we specify an analysis that verifies that functions which are only safe to call in uniform control flow (barriers and derivatives) are only called in such a context.


I would call out that it's a static analysis: it is done only by inspecting the program source.

dneto0 · 2021-03-30T17:53:12Z

wgsl/index.bs

+The first phase walks over the AST of the function, building a directed graph along the way.
+The second phase explores that graph, resulting in either rejecting the program, or computing the constraints on calling this function.
+
+Note: Each vertex in this graph corresponds either to the statement "The control-flow at a specific program point must be uniform" or to "The value of a specific expression must be uniform" or to "A specific variable must always hold a uniform value" or is one of the special vertices True and False.


Which agent has the obligation for the "must"? The analysis, the programmer, or the runtime behaviour of the implementation?

Is it provability?

The control flow at this point in the program is proven to be uniform?

Or

Semantics of the language require that this statement be executed in uniform control flow. (e.g. this is a control barrier)

dneto0 · 2021-03-30T17:55:54Z

wgsl/index.bs

+
+In more detail, here is the algorithm for analyzing a function:
+
+* Create some vertices called "True", "False", "CF_start", "CF_return" and if the function is non-void a vertex called "Value_return"


What is the intuition behind True and False.

Is it

True = control flow is known to be uniform at this point

False = control flow is not known to be uniform at this point.

That highlights the one-sided error of the analysis, which is important to make clear.

Yes. I originally went for "mustBeUniform" "cannotBeGuaranteedToBeUniform", but found it too verbose, and think that True/False makes it clearer why edges can be interpreted as edges.

dneto0 · 2021-03-30T17:58:02Z

wgsl/index.bs

+The second phase explores that graph, resulting in either rejecting the program, or computing the constraints on calling this function.
+
+Note: Each vertex in this graph corresponds either to the statement "The control-flow at a specific program point must be uniform" or to "The value of a specific expression must be uniform" or to "A specific variable must always hold a uniform value" or is one of the special vertices True and False.
+      Each (directed) edge corresponds to an implication.


+1 to describing more what implication is supposed to capture.

kvark

Haven't finished my review yet, will do another pass after the first iteration.

kvark · 2021-04-05T18:47:45Z

wgsl/index.bs

+The analysis is what actually defines these concepts, and when a program is valid or break the uniformity rules.
+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.
+An expression is said to be uniform if it is in uniform control-flow, and all invocations compute the same value for it.


It makes sense to me. How would you say "all invocations" without implying the uniform control flow?

kvark · 2021-04-05T18:48:24Z

wgsl/index.bs

+The following definitions are merely informative, trying to give an intuition for what the analysis in the next subsection is computing.
+The analysis is what actually defines these concepts, and when a program is valid or break the uniformity rules.
+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.


we need to define the scope of this, i.e. what subset of invocations is considered for uniformity

I agree completely that this needs to be defined. To do so, we'll have to introduce the concept of waves/subgroups/warps/wavefronts/whatever. Which I don't think is in the spec currently.

This brings up another concern of mine. Will having one scope for "uniform" that applies to buffers and another scope for "uniform" as it applies to variables and control flow be confusing? I think so.

kvark · 2021-04-05T18:58:24Z

wgsl/index.bs

+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.
+An expression is said to be uniform if it is in uniform control-flow, and all invocations compute the same value for it.
+A local variable is said to be uniform, if all invocations have the same value in that variable at every program point where it is live.


Something must be said about what "all invocations" mean here. Is it "all" through the draw/dispatch? "all" in the current scope? Or even "all" as in all active at any point within the wave?

wgsl/index.bs

kvark · 2021-04-05T20:42:08Z

wgsl/index.bs

+  <thead>
+    <tr><th>Statement<th>New vertices<th>Recursive analyses<th>Behaviors<th>Resulting control-flow vertex<th>New edges
+  </thead>
+  <tr><td class="nowrap">*s1*; *s2*


I don't get this part. What statement is this in the code?

Just a sequence. E.g. two function calls {foo(); bar();}, this simply says that you should first analyze the first statement, then the second, using the control flow at the exit of the first one as the control flow at the entrance fo the second.

Pedantically speaking, the grammar doesn't have this in the statements. Perhaps, we should move this rule out of the table?

kvark · 2021-04-05T20:46:30Z

wgsl/index.bs

+  <tr><td class="nowrap">if (*e*) then *s1* else *s2*
+      <td>*CFinside*, *CFend*
+      <td class="nowrap">*CF*, *e* -> *CF'*, *V*, *B*<br>
+          *CFinside*, *s1* -> *CF1*, *B1*<br>


Sorry, I'm confused here again. We are defining a new vertex "CFinside", but what is it?
This command is supposed to mean "run the analysis on S starting with control-flow CF1, apply the required changes to t...", so it assumes that CF1 is known and given. But here where we are using this, we aren't defining it in any way.

CFinside is a freshly allocated node.
It is passed to the recursive analysis so that it can make edges from other nodes to it.
And from the last column you have "CFinside -> {CF', V}", which adds two edges starting from it.

In terms of implementation, a vertex/node is just an integer. So this entire rule would look something like this (in pseudo-C++ syntax):

unsigned CFinside = ++allocatedVerticesCounter; unsigned CFend = ++allocatedVerticesCounter; auto (CF', V, B) = analyzeExpr(CF, e); auto (CF1, B1) = analyzeStmt(CFinside, s1); auto (CF2, B2) = analyzeStmt(CFinside, s2); behaviorSet bReturn = union(B, B1, B2); edges[CFinside].push_back(CF'); edges[CFinside].push_back(V); edges[CFend].push_back(CF1); edges[CFend].push_back(CF2); return (CFend, bReturn);

It is probably not perfect C++ (in particular I have not checked the syntax for creating/destructuring tuples, and we probably should expand the edges vector when we increment allocatedVerticesCounter, and we should not use an apostrophe in an identifier), but it should hopefully clarify the meaning of this table.

Did this answer your question? And if so, do you have any advice on how I should present it in the spec?

No, I think we should have some wording here to help the reader, like "CFinside is a node corresponding to XXX", and same for all the nodes we are introducing.

edges[CFinside].push_back(CF');

I agree this is necessary, but I can't figure out from the table where this edge comes from. I'd suggest stating it explicitly.

wgsl/index.bs

kvark · 2021-04-05T20:54:32Z

wgsl/index.bs

+### Uniformity rules for function calls ### {#uniformity-function-calls}
+
+The most complex rule is for function calls:
+- For each argument, apply the corresponding expression rule, with the control-flow at the exit of the previous argument (using the control-flow at the beginning of the function call for the first argument). Name the corresponding value vertices "arg_i" and the corresponding control-flow vertices "CF_i"


what are the "CF_i" exactly?

They're the nodes returned by the recursive calls to the analysis when analyzing the arguments.
They're intended to correspond to the uniformity requirement of the control-flow at the end of evaluating the corresponding argument.

kvark · 2021-04-06T04:56:35Z

Also, before I forget, we really need to figure out the exact scopes for uniformity (see #669 thread) before proceeding with the analysis. The design space includes some interesting options if the scope is at least the sub-group.

alan-baker · 2021-04-06T17:35:12Z

I'm concerned about the following case:

loop {
  storageBarrier();
  if (non_uniform_expr) {
    continue;
  }
  // ...
};

SPIR-V will not guarantee that the invocations are reconverged at the start of the subsequent loop iterations, so the barrier cannot be considered to be in uniform control flow. I don't think the analysis captures this.

pow2clk

Sorry for the last minute review.

Loathe as I am to bog us down in renaming discussions, I fear that fact that "uniform" means a different scope for variables and buffers will be confusing.

I think the definitions of "uniform" for different nouns should be based on utility as I've described internally.

I think introducing the notion of a block would be helpful in simplifying the way to determine uniformity as it would allow simply saying that a variable is uniform if it is assigned in a basic block whose execution depends on uniform control flow and all its dependencies are uniform. We could do away with defining a uniform expression and just say that certain operations cannot be used within a basic block that is non-uniform.

pow2clk · 2021-04-06T17:21:31Z

wgsl/index.bs

+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.
+An expression is said to be uniform if it is in uniform control-flow, and all invocations compute the same value for it.
+A local variable is said to be uniform, if all invocations have the same value in that variable at every program point where it is live.


I disagree with @jdashg's comment here. The way I use the term, a variable can be in uniform control flow and be non-uniform because it has different values across the scope of the uniformity. I would argue this definition because it is useful. If a control flow construct depends on a non-uniform variable under my definition, the control flow will be non-uniform. To express that in a definition where uniformity of a variable depends on the uniformity of its control flow, we would have to redefine a characteristic of variables to plug into that statement.

Furthermore, the uniformity of a uniform buffer concerns the persistence of its values across a broad scope. The same should apply to defining a variable as uniform.

pow2clk · 2021-04-06T17:23:41Z

wgsl/index.bs

+The following definitions are merely informative, trying to give an intuition for what the analysis in the next subsection is computing.
+The analysis is what actually defines these concepts, and when a program is valid or break the uniformity rules.
+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.


I agree completely that this needs to be defined. To do so, we'll have to introduce the concept of waves/subgroups/warps/wavefronts/whatever. Which I don't think is in the spec currently.

This brings up another concern of mine. Will having one scope for "uniform" that applies to buffers and another scope for "uniform" as it applies to variables and control flow be confusing? I think so.

pow2clk · 2021-04-06T17:27:37Z

wgsl/index.bs

+The following definitions are merely informative, trying to give an intuition for what the analysis in the next subsection is computing.
+The analysis is what actually defines these concepts, and when a program is valid or break the uniformity rules.
+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.


For purposes of utility, I would define uniform control flow as being control flow that depends on values certain to be the same over the defined scope of uniformity. The programmer doesn't care if they are executed in lockstep or not. It's not strictly relevant to the restrictions this introduces. Rather than having to define how hardware works, let's define how you can write a program that trips it up.

pow2clk · 2021-04-06T17:29:22Z

wgsl/index.bs

+The analysis is what actually defines these concepts, and when a program is valid or break the uniformity rules.
+
+Control-flow is said to be uniform at a point in the program if all invocations execute in lockstep at that program point.
+An expression is said to be uniform if it is in uniform control-flow, and all invocations compute the same value for it.


I think the only reason we need to define whether an expression is "uniform" is so we can place limits on what operations are in it. For this reason, we only care if it is in uniform control flow. These expressions might produce different results and still be in uniform control flow, that doesn't mean you can't use the uniform control limited operations in such expressions.

wgsl/index.bs

pow2clk · 2021-04-06T17:42:26Z

wgsl/index.bs

+### Uniformity rules for statements ### {#uniformity-statements}

-### Divergence and reconvergence TODO ### {#divergence-reconvergence}
+In order to properly deal with reconvergence we must know when there is a single way for control to flow out of a statement.


This is the first mention of convergence or reconvergence. As I understand it, it is a synonym for uniformity and nonuniformity, but it's not explicitly said here. I happen to think that these terms are preferable due to the different meaning of uniform buffers, but regardless, they should either be defined or not used.

oh this is going to be fun to specify! SPIR-V uses the notion of quad uniformity, while reconverting only at the subgroup scale.

Point taken about terminology! We can bikeshed when the text comes into better focus. (We can use mangoes, bananas, grapes as needed.)

RobinMorisset · 2021-04-06T17:57:50Z

Sorry for not having answered all of these helpful comments more quickly. I am in the middle of it, I just wanted to rapidly answer the last one:

I'm concerned about the following case:
loop {
  storageBarrier();
  if (non_uniform_expr) {
    continue;
  }
  // ...
};
SPIR-V will not guarantee that the invocations are reconverged at the start of the subsequent loop iterations, so the barrier cannot be considered to be in uniform control flow. I don't think the analysis captures this.

The analysis does capture this example (it was one the main examples that I used while designing the analysis!)
The behaviors of your

if (non_uniform_expr) {
  continue;
}

are {Continue, Nothing}. Since this set has more than one element, there is no automatic reconvergence. In particular, the control-flow at the end of this statement (CFend in the if rule) has a path (indirectly) to non-uniform-expr.
And the control-flow at the beginning of the loop (CF' in the loop rule) has a path to the control-flow at the end of the loop (CF1 in the loop rule)
Because of the storageBarrier, there is an edge from True to that vertex (CF').
And since nonUniformExpr is non-uniform, there is a path from the corresponding vertex to False.
So there is a path from True to False, and the program is rejected.

RobinMorisset

I'll answer the rest of the comments in the next hour or two.

wgsl/index.bs

RobinMorisset · 2021-04-06T18:07:49Z

wgsl/index.bs

+
+At the same time, it computies metadata about the function to help analyze its callers in turn. This means that the call graph must first be built, and functions must be analyzed from the leaves upwards, i.e. from functions that call no function outside the standard library toward the entry point. This way, whenever a function is analyzed, the metadata for all of its callees has already been computed. There is no risk of being trapped in a cycle, as recurrence is forbidden in the language.
+
+Note: another way of saying the same thing is that we do a topological sort of functions ordered by the "is a (possibly indirect) callee of" partial order, and analyze in that order.


We are debating allowing functions to be declared in any order. You are correct that if we do not allow calling a function before it is defined, then we can just use the program order.

wgsl/index.bs

RobinMorisset · 2021-04-06T18:11:09Z

wgsl/index.bs

+
+In more detail, here is the algorithm for analyzing a function:
+
+* Create some vertices called "True", "False", "CF_start", "CF_return" and if the function is non-void a vertex called "Value_return"


Yes. I originally went for "mustBeUniform" "cannotBeGuaranteedToBeUniform", but found it too verbose, and think that True/False makes it clearer why edges can be interpreted as edges.

RobinMorisset · 2021-04-06T18:13:23Z

wgsl/index.bs

+### Uniformity rules for statements ### {#uniformity-statements}
+
+In order to properly deal with reconvergence we must know when there is a single way for control to flow out of a statement.
+We achieve this by assigning to each statement a set of *behaviors* out of {Return, Break, Continue, Discard, Nothing}.


Nothing means that control can flow to the next statement.
I wanted to call it Fallthrough, but it conflicted with the actual Fallthrough statement. Maybe "Default" or "NextStatement" might be clearer?

The empty set would mean that control flow is trapped forever in the statement.

RobinMorisset · 2021-04-06T18:13:52Z

wgsl/index.bs

-### Uniformity restrictions TODO ### {#uniformity-restrictions}
+TODO: do we need an extra behavior for possibly infinite loops? I should check whether some form of reconvergence happens after something like `while(tid mod 2) {}`.
+
+If the set of behaviors for a statement has a single element, this means that we either did not diverge within the statement, or we reconverged, and we pick the vertex corresponding to control-flow at the start of the statement as the vertex corresponding to control-flow at the exit of the statement, overriding the other rules below.


Ok, I'll try to move this to after the table.

wgsl/index.bs

RobinMorisset · 2021-04-06T18:16:28Z

wgsl/index.bs

+  <thead>
+    <tr><th>Statement<th>New vertices<th>Recursive analyses<th>Behaviors<th>Resulting control-flow vertex<th>New edges
+  </thead>
+  <tr><td class="nowrap">*s1*; *s2*


Just a sequence. E.g. two function calls {foo(); bar();}, this simply says that you should first analyze the first statement, then the second, using the control flow at the exit of the first one as the control flow at the entrance fo the second.

RobinMorisset · 2021-04-06T18:16:41Z

wgsl/index.bs

+      <td>*B1* \ {Nothing} U *B2*
+      <td>*CF2*
+      <td>
+  <tr><td class="nowrap">if (*e*) then *s1* else *s2*


kdashg · 2021-04-07T01:10:56Z

WGSL meeting minutes 2021-04-06

RM: Thanks to everyone who commented! I don’t think it’s useful to discuss details in the whole group, but rather it would be good to discuss Task: Uniformity #669 instead.
- Issue 669
MM: I feel like there’s not much to discuss, but rather this is an exercise in identifying the intersection between our host APIs
AB: Though we do need to do this statically, which not all hosts may have
MM: I volunteered to investigate MSL
GR: I can tell you for derivatives in d3d, where we assume the author doesn’t ever ask for them outside uniform control flow
DN: Maybe there is a distinction, whether we can statically determine these, vs dynamic. On a particular platform, it might compile, since it assumes that there’s some run-time reason why it will be valid, even though it’s not provable
TR: Can always expand it later, but can’t restrict it later
MM: As a programmer, I want/need to know if what I’m doing is legal
AB: I think we would need different uniformity levels, which current proposal doesn’t handle
MM: Besides derivatives, is everything else handled? Maybe I need to go through the builtins to check which needs what.
MM: Right now, wgsl is pretty simple, can’t address quad/simd groups today, but, we might want to add that later. It could be useful for RM and me to already go adapt the uniformity analysis to handle multiple levels of uniformity. Today, FS has derivative groups, and CS have workgroups, but no shader type has multiple levels today.
RM: We may just be able to run the analysis twice.
GR: Is this done for each webpage? (yes, as part of shader validation and type checking)
DM: One case we have in webrender, where we have different quads that have different values for flat interpolators, and this is a use case we should try to handle for webgpu.
TR: Like for per-primitive uniforms?
TR: Also difference in doing a deriv in non-uniform control if its source at least comes from uniform control flow
MM: This is a case where we may reject a technically-allowed thing, for unusual code
TR: Not that uncommon, and we probably want to handle it. This was allowed in FXC even when we tried to be very conservative otherwise.

wgsl/index.bs

kvark · 2021-04-13T17:19:37Z

wgsl/index.bs

+
+At the same time, it computies metadata about the function to help analyze its callers in turn. This means that the call graph must first be built, and functions must be analyzed from the leaves upwards, i.e. from functions that call no function outside the standard library toward the entry point. This way, whenever a function is analyzed, the metadata for all of its callees has already been computed. There is no risk of being trapped in a cycle, as recurrence is forbidden in the language.
+
+Note: another way of saying the same thing is that we do a topological sort of functions ordered by the "is a (possibly indirect) callee of" partial order, and analyze in that order.


IIRC, the current consensus is to have all the top-level declarations ordered.
We can therefore describe this as just analyzing the functions in the order they are written, and add a TODO to reconsider a topological sort once the ordering is relaxed (after MVP, if ever).

kvark · 2021-04-13T17:20:45Z

wgsl/index.bs

+### Uniformity rules for statements ### {#uniformity-statements}

-### Divergence and reconvergence TODO ### {#divergence-reconvergence}
+In order to properly deal with reconvergence we must know when there is a single way for control to flow out of a statement.


oh this is going to be fun to specify! SPIR-V uses the notion of quad uniformity, while reconverting only at the subgroup scale.

wgsl/index.bs

kvark · 2021-04-13T17:26:17Z

wgsl/index.bs

+  <thead>
+    <tr><th>Statement<th>New vertices<th>Recursive analyses<th>Behaviors<th>Resulting control-flow vertex<th>New edges
+  </thead>
+  <tr><td class="nowrap">*s1*; *s2*


Pedantically speaking, the grammar doesn't have this in the statements. Perhaps, we should move this rule out of the table?

kvark · 2021-04-13T17:29:05Z

wgsl/index.bs

+  <tr><td class="nowrap">if (*e*) then *s1* else *s2*
+      <td>*CFinside*, *CFend*
+      <td class="nowrap">*CF*, *e* -> *CF'*, *V*, *B*<br>
+          *CFinside*, *s1* -> *CF1*, *B1*<br>


No, I think we should have some wording here to help the reader, like "CFinside is a node corresponding to XXX", and same for all the nodes we are introducing.

kdashg · 2021-04-20T19:17:05Z

WGSL meeting minutes 2021-04-20

RM: Sorry, been sick. New patch soon to add things that people had been requested, like “is this point/line in uniform flow”. Nothing to report right now though.
DM: Talked about with AB: One problem is that reconvergence is at the draw-call level. (AB: Compute is workgroup) So we wouldn’t be able to treat flat interps as uniform still?
AB: Difference between uniform flow and uniform vals
MM: Whatever we do for UA, we have to respect that the APIs don’t give us better reconvergence guarantees.
DM: I think it’s more complicated than that, where we may want better/stricter analysis. Can look later into making it more flexible.
MM: I’m excited for a tool that colors lines green/red for non/uniform.
DM: Just waiting for RM then? We have an alg implementation, but not RM’s.
AB: If I had a tool that broke up an implicit lod lookup, and moved the derivative out into UCF, is that a valid transform? Or would we have to reject it?
RM: I think if this is a tool, then it would have been accepting non-spec WGSL, and transforming it into spec-compliant WGSL
TR: I think you’re talking about the same transform that fxc does, where it may hoist out the derivative. But it wouldn’t convert implicit to explicit
AB: I think Vulkan specs implicit based on explicit, though implicit may be faster
RM: The spec would declare it as non-valid WGSL and browsers would reject, but a tool could accept a non-WGSL thing and transform it.
AB: So anything passed to createShaderModule would need to respect the spec here (yes)
DM: Do we need to talk about private globals that naga/tint generate?
RM: I think it would be useful to have a keyword that requires UCF, and I think this would satisfy that problem.
GR: Should we generate an error for non-UCF, or should we transform it so that it is?
RM: non-UCF would be an error
MM: This is an opt-in/assert.
RM: This would also help with global variables if we could annotate them requiring that they are UCF-only
GR: Reminds me of “what level of uniformity are we talking about” Per quad? Per call?
RM: Like DM said, can run UA on different levels, but we need to agree on what level(s?) to require/run.
GR: I find it some confusing that “uniformity” here is different compared to “uniform” buffers.
RM: Is this different from our native APIs? I think everyone is confusing
TR: If we have uniform, it should maybe have an adjective prefix, like quad-uniform.
TR: Also we don’t have subgroups yet, so should we talk about subgroup-uniformity there? (maybe?)
TR: With the assertion, if they don’t have a way to ask for an always-uniform value in subgroup (‘first-lane’?)
AB: I anticipate an ext for dynamic uniformity
MM: Many different names for make-uniform, but because it only work on a simd-group, not sure it makes sense to add now, since it doesn’t match the scope of uniformity that we’re working on right now. I think we should only add simd-groups later, when we’re ready for the whole feature.
JG: So we have diff levels on U, and I think we can just run the UA on different levels of U, and I think we’ll want this for our different levels of U.
RM: Yeah, that works, though I’m not sure myself what levels we want/need, but UA will work. (as long as we don’t have toooo many U levels!)
AB: Derivative requires quad-uniformity But in SPIR-V once you’ve diverged, you only reconverge for the whole invocation-group which is essentially the whole draw.
TR: We also don’t have a make-quad-uniform thing, either, so we generally can’t anyway
AB: I don’t think other specs make this guarantee either.
JG: What about on de-convergence? Can you go from UCF to non-Invoke-U but still quad-U?
AB: Yes but it falls apart quickly.
// uniform control flow
If (non_uniform_cond) {
// known to be quad uniform
If (non_quad_uniform_cond) {
// …
}
// no longer quad uniform in SPIR-V
}
// uniform control flow

RobinMorisset · 2022-01-24T22:54:21Z

@alan-baker, @dneto0. I think I've changed everything that we discussed in today's call and in #1770; so it should be ready for you to review.

Things that we decided to delay to some separate PRs:

changing the rules to accommodate Should unreachable-code be an error or warning? #2378 since it is still undergoing debate
various renamings (e.g. MustBeUniform => RequiredToBeUniform, finding clearer names than LValue/RValue)
making a new version of the rules with a greater focus on understandability and lesser focus on perf, making the current rules (which are designed to be equivalent) a non-normative appendix.
possibly detecting dead continuing blocks if we decide to do anything special for dead code.
adding some form of uniformity annotations for global variables (Uniformity annotations for global variables #1791)
adding some form of uniformLoad operation (Uniformity analysis: find a way to load from a storage buffer uniformly. #2321)

alan-baker

Very close now, just some minor text update from my point of view. Thanks!

alan-baker · 2022-01-25T14:44:14Z

wgsl/index.bs

+      <td>
+      <td class="nowrap">*CF*, *CF*
+      <td>
+   <tr><td class="nowrap">reference to function-scope variable or parameter "x"


The spec distinguishes between variables and let-declarations, so to be precise we should name let-declarations here.

Suggested change

<tr><td class="nowrap">reference to function-scope variable or parameter "x"

<tr><td class="nowrap">reference to function-scope variable, let-declaration or formal parameter "x"

Separately are these rules priority based? This rule conflicts with builtin value rules below since they may be function parameters (or members of a struct function parameter).

alan-baker · 2022-01-25T14:44:39Z

wgsl/index.bs

+      <td class="nowrap">*X* is the node corresponding to "x"
+      <td class="nowrap">*CF*, *Result*
+      <td class="nowrap">*Result* -> {*CF*, *X*}
+   <tr><td class="nowrap">reference to uniform built-in variable "x"


Nit: built-in variables are now referred to as built-in values.

alan-baker · 2022-01-25T14:44:52Z

wgsl/index.bs

+      <td>
+      <td class="nowrap">*CF*, *CF*
+      <td>
+   <tr><td class="nowrap">reference to non-uniform built-in variable "x"


alan-baker · 2022-01-25T14:45:07Z

wgsl/index.bs

+      <td>
+      <td class="nowrap">*CF*, *CannotBeUniform*
+      <td>
+   <tr><td class="nowrap">reference to read-only global variable "x"


Nit: change global to module-scope

alan-baker · 2022-01-25T14:45:14Z

wgsl/index.bs

+      <td>
+      <td class="nowrap">*CF*, *CF*
+      <td>
+   <tr><td class="nowrap">reference to non-read-only global variable "x"


wgsl/index.bs

…ion let-declarations

github-actions · 2022-01-25T15:24:37Z

Previews, as seen when this build job started (ef89e66):
WebGPU | IDL
WGSL
Explainer

alan-baker

Great work, thanks for this contribution!

dneto0

Thanks!

I think we should land this version.
Discussing with @alan-baker and @RobinMorisset offline, we have queued up some further refinements, and reaction to decisions about what to analyze in unreachable code.

wgsl/index.bs

dneto0 · 2022-01-25T18:19:14Z

wgsl/index.bs

+          *Value_return* -> *V*
+  <tr><td class="nowrap">*e1* = *e2*;
+      <td>
+      <td class="nowrap">LValue: (*CF*, *e1*) => (*CF1*, *L1*)<br>


This has the LHS being evaluated before the RHS.
Current spec says the RHS is evaluated before the LHS.
We can fix this later.

Ah, good catch, I kept expecting left-to-right evaluation. I'll fix it.

RobinMorisset

Thanks for the kind words and thorough reviews. I've got a commit incoming with fixes to the last issues you found.

wgsl/index.bs

github-actions · 2022-01-25T21:01:52Z

Previews, as seen when this build job started (c620d23):
WebGPU | IDL
WGSL
Explainer

kdashg · 2022-01-26T18:13:15Z

WGSL meeting minutes 2022-01-25

* Robin, Alan, David met offline and came to a common understanding of what needs to be done before landing vs. after landing.  Expect a landable PR by the end of week of .  Expect to review and land next week.

Since then Robin updated, and Alan reviewed and approved. Have a list of followups to do in separate PRs (see note in the issue).
AB: Would like others to review, but also accelerate landing so we can get to implementation.
DM: We agreed conceptually on what it is, so I expect to approve and land by next week.
One week to review, expect to land next meeting or earlier.

dneto0

Thanks for persevering. I think I understand it now and am happy to land this.

Thanks!

dneto0 · 2022-01-27T22:49:36Z

The merge conflict is a trivial one, based on the capitalization of the old section names. I can fix it for you if you like.

github-actions · 2022-02-01T16:52:28Z

Previews, as seen when this build job started (eee5098):
WebGPU | IDL
WGSL
Explainer

kvark

I looked at it again, sorry about the wait!

I don't expect this to be perfect for landing. It's a hugely important and big piece of work that we require, and we should follow-up with patches. But I'd like to have at least the foundation of the algorithm to be solid, i.e. the terms defined and the nodes called something that's easy to understand. This way, we'll be in a better position to polish it.

So noted a few things. Please feel free to respond "let's deal with it later" on any of them!

Here are some high-level thoughts. While this algorithm is required, I have a sense that describing it in this form may be suboptimal. It's very hard to understand by reading it. For me, it's more or less a number of magic rules that I have to basically reinterpret in my head when reading. And this is complicated by the fact it's written in pseudo-code, so the rules of interpretation are also interpreted from the text...

So this reminds me of an article I made some time ago. What would be cleaner for me personally if this algorithm was written as actual code that I can run. Whatever language it is (statically typed are preferred, of course).
But I understand it's too much to ask at this stage, so we should proceed.

wgsl/index.bs

kvark · 2022-02-01T20:17:22Z

wgsl/index.bs

+In this section we specify an analysis that verifies that functions which are only safe to call in uniform control flow (e.g. barriers and derivatives) are only called in such a context.
+
+<div class="note">Note: This analysis has the following desirable properties:
+      - Sound (meaning that it rejects every program that would break the uniformity requirements of builtins)


are we only talking about builtins here?
Considering this program:

fn foo() -> f32 { return myTexture.sample(mySampler, 0.0).x; } fn bar() { if (non_uniform) { foo(); } }

My interpretation is that we are analysing foo's requirement for being called in uniform control flow, and then we can reject the program based on the call sites of foo. And this is user-defined, not a builtin.

You are correct. I wrote builtin here, because all constraints ultimately flow from some builtin (if there was no call to sample in foo, we could call foo anywhere). I am not sure how to phrase it more clearly.

wgsl/index.bs

kvark · 2022-02-01T20:34:35Z

wgsl/index.bs

+
+In more detail, here is what we compute for each function:
+
+* A tag about the control-flow in which the function can be called: one of {AlwaysMustBeUniform, MustBeUniformForControlFlowAfter}


is there a statement missing clarifying what a "tag" is in this context?
or at least, something like "for each node in the graph representing a function, we may attach the following tags"?

kvark · 2022-02-01T20:37:00Z

wgsl/index.bs

+In more detail, here is what we compute for each function:
+
+* A tag about the control-flow in which the function can be called: one of {AlwaysMustBeUniform, MustBeUniformForControlFlowAfter}
+* A tag for each parameter of the function: one of {AlwaysMustBeUniform, MustBeUniformForControlFlowAfter, MustBeUniformForReturnValue, NoRestriction}


It sounds like exactly one tag needs to be attached to a node representing the function parameter. Would it ever be the case where we want MustBeUniformForControlFlowAfter together with MustBeUniformForReturnValue but not as strong as AlwaysMustBeUniform?

kvark · 2022-02-01T20:44:08Z

wgsl/index.bs

+
+Here is the algorithm for computing this data for a given function:
+
+* Create nodes called "MustBeUniform", "CannotBeUniform", "CF_start", "CF_return", and if the function is non-void a node called "Value_return"


the language seems to be marginally inconsistent in multiple dimensions:

here we use "Name", where some other place we just do Name. Perhaps, we should just refer to them consistently as Name everywhere?

some names use camel case, others use some variation of a snake case, e.g. "Value_return". Perhaps, we could pick one and stick with it? That would mean, for example, ControlFlowStart, ControlFlowReturn, ValueReturn, etc

kvark · 2022-02-01T20:45:09Z

wgsl/index.bs

+
+* Create nodes called "MustBeUniform", "CannotBeUniform", "CF_start", "CF_return", and if the function is non-void a node called "Value_return"
+* Create one node for each parameter of the function which we'll call "arg_i"
+* Walk over the syntax of the function, adding nodes and edges to the graph following the rules of the next section, using CF_start as the starting control-flow for the function's body.


nit: there is a few cases where the spec says "this is described below" of sorts, like here. It would be great to have an actual link to the relevant section instead

kvark · 2022-02-01T20:49:12Z

wgsl/index.bs

+* Create some nodes called "MustBeUniform", "CannotBeUniform", "CF_start", "CF_return" and if the function is non-void a node called "Value_return"
+* Create one node for each parameter of the function which we'll call "arg_i"
+* Walk over the syntax of the function, adding nodes and edges to the graph following the rules of the next section.
+* Look at which nodes are reachable from "MustBeUniform"


I expressed a similar concern in a comment, glad this is noticed. Let's have good names here, please.
"CannotBeUniform" -> "MayBeNonUniform" or "AssumedNonUniform"
"MustBeUniformForControlFlowAfter" -> "PropagatesUniformity" or something along the lines (edit: I see @Kangz suggested a very similar thing earlier)

RobinMorisset

Thanks @kvark for the comments. I've tried to rephrase things where you found them unclear, please tell me whether it helps.

I am not opposed to providing a reference implementation of the analysis implemented in an executable language, quite the opposite, but I don't think I can do that in the next few days, and we'd like to get this landed in the spec soon.

RobinMorisset · 2022-02-02T15:31:42Z

wgsl/index.bs

+In this section we specify an analysis that verifies that functions which are only safe to call in uniform control flow (e.g. barriers and derivatives) are only called in such a context.
+
+<div class="note">Note: This analysis has the following desirable properties:
+      - Sound (meaning that it rejects every program that would break the uniformity requirements of builtins)


You are correct. I wrote builtin here, because all constraints ultimately flow from some builtin (if there was no call to sample in foo, we could call foo anywhere). I am not sure how to phrase it more clearly.

github-actions · 2022-02-02T15:35:43Z

Previews, as seen when this build job started (92623ba):
WebGPU | IDL
WGSL
Explainer

kdashg · 2022-02-02T18:05:47Z

WGSL meeting minutes 2022-02-01

Previously:
- One week to review, expect to land next meeting or earlier.
RM: David and Alan reviewed and approved. No other complaints.
DM: Have not reviewed. Expect to review tonight. Will give answer tonight.

kvark

Thank you for patience in addressing all of those!

@kvark

SHA: 0561a0e Reason: push, by @kvark Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

@kvark

SHA: 0561a0e Reason: push, by @kvark Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

@kvark

SHA: 0561a0e Reason: push, by @kvark Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

…ception (gpuweb#1571) This PR updates the existing createQuerySet test of query_types.spec.ts in order to expect exceptions rather than validation errors when the device features doesn't contain 'timestamp-query'.

litherum reviewed Mar 30, 2021

View reviewed changes

kdashg reviewed Mar 30, 2021

View reviewed changes

pow2clk self-requested a review March 30, 2021 18:38

kdashg self-requested a review March 30, 2021 18:38

kvark self-requested a review March 30, 2021 18:44

alan-baker self-requested a review March 30, 2021 19:04

alan-baker reviewed Mar 30, 2021

View reviewed changes

kvark mentioned this pull request Mar 30, 2021

Uniformity of Private-class global variables #1579

Open

dneto0 requested changes Mar 30, 2021

View reviewed changes

kvark mentioned this pull request Apr 1, 2021

Task: Uniformity #669

Closed

kvark reviewed Apr 5, 2021

View reviewed changes

pow2clk reviewed Apr 6, 2021

View reviewed changes

RobinMorisset commented Apr 6, 2021

View reviewed changes

kdashg reviewed Apr 7, 2021

View reviewed changes

wgsl/index.bs Outdated Show resolved Hide resolved

Kangz added the wgsl WebGPU Shading Language Issues label Apr 9, 2021

kvark reviewed Apr 13, 2021

View reviewed changes

RobinMorisset mentioned this pull request Jun 1, 2021

Uniformity annotations for global variables #1791

Open

RobinMorisset requested a review from dneto0 January 24, 2022 22:34

alan-baker requested changes Jan 25, 2022

View reviewed changes

s/global/module-scope/, s/built-in variable/built-in value/, and ment…

ef89e66

…ion let-declarations

alan-baker approved these changes Jan 25, 2022

View reviewed changes

dneto0 approved these changes Jan 25, 2022

View reviewed changes

Address the last issues found by @dneto0

c620d23

RobinMorisset commented Jan 25, 2022

View reviewed changes

wgsl/index.bs Show resolved Hide resolved

wgsl/index.bs Show resolved Hide resolved

wgsl/index.bs Show resolved Hide resolved

dneto0 approved these changes Jan 27, 2022

View reviewed changes

Merge branch 'main' into main

eee5098

kvark requested changes Feb 1, 2022

View reviewed changes

Robin Morisset added 3 commits February 2, 2022 16:15

CannotBeUniform -> MayBeNonUniform

3358ba2

Apply Dzmitry's suggestions

66fa04d

s/MustBeUniform/RequiredToBeUniform/g

92623ba

RobinMorisset commented Feb 2, 2022

View reviewed changes

This was referenced Feb 2, 2022

should shaders be checked for execution-uniformity (e.g. barrier only in uniform control flow) #264

Closed

Document behaviour when uniformity requirement can't be proven #340

Closed

kvark approved these changes Feb 2, 2022

View reviewed changes

kvark merged commit 0561a0e into gpuweb:main Feb 2, 2022

github-actions bot added a commit that referenced this pull request Feb 2, 2022

Add the uniformity analysis to the WGSL spec (#1571)

8991ecb

SHA: 0561a0e Reason: push, by @kvark Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

github-actions bot added a commit that referenced this pull request Feb 2, 2022

Add the uniformity analysis to the WGSL spec (#1571)

6ff9b0c

SHA: 0561a0e Reason: push, by @kvark Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

github-actions bot added a commit that referenced this pull request Feb 2, 2022

Add the uniformity analysis to the WGSL spec (#1571)

46b0175

SHA: 0561a0e Reason: push, by @kvark Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>


		### Uniformity analysis overview ### {#uniformity-overview}

		In this section we specify an analysis that verifies that functions which are only safe to call in uniform control flow (barriers and derivatives) are only called in such a context.


		TODO: do we need an extra behavior for possibly infinite loops? I should check whether some form of reconvergence happens after something like `while(tid mod 2) {}`.

		If the set of behaviors for a statement is a singleton, we take that to mean that reconvergence happened, and we pick the vertex corresponding to control-flow at the start of the statement as the vertex corresponding to control-flow at the exit of the statement, overriding the other rules below.


		### Uniformity rules for function calls ### {#uniformity-function-calls}

		The most important and complex rule is for function calls:


		In more detail, here is the algorithm for analyzing a function:

		* Create some vertices called "True", "False", "CF_start", "CF_return" and if the function is non-void a vertex called "Value_return"


		At the same time, it computies metadata about the function to help analyze its callers in turn. This means that the call graph must first be built, and functions must be analyzed from the leaves upwards, i.e. from functions that call no function outside the standard library toward the entry point. This way, whenever a function is analyzed, the metadata for all of its callees has already been computed. There is no risk of being trapped in a cycle, as recurrence is forbidden in the language.

		Note: another way of saying the same thing is that we do a topological sort of functions ordered by the "is a (possibly indirect) callee of" partial order, and analyze in that order.

	<tr><td class="nowrap">reference to function-scope variable or parameter "x"
	<tr><td class="nowrap">reference to function-scope variable, let-declaration or formal parameter "x"


		In more detail, here is what we compute for each function:

		* A tag about the control-flow in which the function can be called: one of {AlwaysMustBeUniform, MustBeUniformForControlFlowAfter}


		Here is the algorithm for computing this data for a given function:

		* Create nodes called "MustBeUniform", "CannotBeUniform", "CF_start", "CF_return", and if the function is non-void a node called "Value_return"

Conversation

RobinMorisset commented Mar 29, 2021 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 29, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kdashg Apr 7, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

litherum Mar 30, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RobinMorisset commented Mar 30, 2021

Uh oh!

litherum commented Mar 30, 2021

Uh oh!

RobinMorisset commented Mar 30, 2021

Uh oh!

dneto0 commented Mar 30, 2021 • edited by kainino0x Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

RobinMorisset commented Mar 29, 2021 •

edited by pr-preview bot

Loading

kdashg Apr 7, 2021 •

edited

Loading

litherum Mar 30, 2021 •

edited

Loading

dneto0 commented Mar 30, 2021 •

edited by kainino0x

Loading