We think the uniformity analysis needs some updates to better account for pointers. Pointers have relatively limited functionality in WGSL currently, but they can be used for:
- assignment to most address spaces in a local manner (e.g.
let x = &y; *x = ...;)
- passed as parameters for private, workgroup and function address spaces
The missing uniformity aspects have to do with function address space pointers since private and workgroup end up being non-uniform by default. The analysis is missing an lvalue rule for the dereference operator and overall, doesn't seem to handle function scope variable passed as pointers to helper functions.
Consider the following:
fn bar(p : ptr<i32, function>, c : bool) {
if (c) {
*p = 0;
}
}
fn foo() {
var x : i32 = 1;
// ...
bar(&x, cond);
// ...
// use x
}
What value node should the "use x" statement use for x? The analysis doesn't capture the value update that occurs in bar, so if c is a non-uniform value the x will become non-uniform.
I can see two possibilities here:
- Be conservative and have a value node for each pointer parameter that gets an edge to MayBeNonUniform, or
- Model pointer parameters like an extra return value and to have a more accurate analysis
CC @jrprice @RobinMorisset
We think the uniformity analysis needs some updates to better account for pointers. Pointers have relatively limited functionality in WGSL currently, but they can be used for:
let x = &y; *x = ...;)The missing uniformity aspects have to do with function address space pointers since private and workgroup end up being non-uniform by default. The analysis is missing an lvalue rule for the dereference operator and overall, doesn't seem to handle function scope variable passed as pointers to helper functions.
Consider the following:
What value node should the "use x" statement use for
x? The analysis doesn't capture the value update that occurs inbar, so ifcis a non-uniform value thexwill become non-uniform.I can see two possibilities here:
CC @jrprice @RobinMorisset