alan-baker
alan-baker
That could work, but I haven't investigated re-parsing the options in clspv once we've loaded all the modules. It would also be possible for clvk to store the user provided...
`texture_2d` seems a bit silly to me. I prefer the descriptiveness of `filterable`.
First thought is something like: ``` struct S1 { x : vec4, y : vec4, } var buf : buffer; // a new type fn foo(offset1 : u32, offset2 :...
Definitely should let them be assigned to `let`s, but I'd suggest returning from functions (at least user-declared functions) as a separate issue.
Discussed internally and we propose to have a subgroup uniformity that basically the same as workgroup uniformity (same basic rules), but at a lower scope. While this likely does not...
After more discussion we are also leaning towards making this a separate language feature since it should in theory also touch the original subgroup builtins.
This is tricky for clspv unfortunately. There's nothing help figure out how to interpret the type. So we don't know how to generate the code (though it fails before the...
Not at the moment unfortunately.
I think I was wrong about untyped pointers solving this issue. Because the pointers are in the private address space, clspv can't actually utilize untyped pointers.
> The uniformity of a continue should only affect the uniformity of statements between the continue and the end of the loop body (the section shown in red on the...