David Neto
David Neto
This should follow #3167 to avoid conflicts.
@jimblandy asked for an example where it's helpful for a GLSL -> SPIR-V -> WGSL flow to have the currently-spec'd pointer rules. I think this is illustrative: Consider this GLSL...
Regarding this construction: ``` var px: pointer; px = (some_conditionX) ? &v1.x: &v2.x; ``` WGSL's rules disallow: - storing a pointer in memory (so there's no way to have an...
> Given that the call graph is a DAG, this check seems to be linear in the size of the program (if you assume that operations on sets of variables...
The discussion in last night's meeting was freeranging and interesting. Google has not agreed to a direction on this topic. It needs more discussion.
It's a normative statement. So it shouldn't be a note? Would you rather it say "Reference types do not appear in WGSL program source"?
Yep, should be override-declaration. Consider fixing this as part of #3061
`trunc` has its own weirdness. 'trunc' says it computes 'truncate' which is defined early on in the spec. 'truncate' is "defined over real numbers x" which excludes infinity. So 'trunc'...
> This maybe a good place to start introducing `undefined value` as the undefined value for a f32 or f16 is `infinity or any valid value`. We then use `undefined...
I want it to be natural and easy to introduce a future extension which enforces floating point behaviour which is more in line with IEEE 754, supporting signed zeros, infinities,...