Rough proposal collecting thoughts on uniformity #405
Conversation
This has been sitting around in my checkout for close to a year, and I've been meaning to finish dumping thoughts into it and post it for wider review and feedback. So here goes! Please be gentle, it's real rough.
| * A _dispatch_ represents the full set of threads spawned from a CPU API | ||
| invocation. | ||
| * A _thread group_ represents a subset of a dispatch that can execute | ||
| concurrently. | ||
| * A _wave_ represents a subset of a thread group that represents in a single | ||
| SIMD processor. | ||
| * A _quad_ represents a grouping of four adjacent threads in a wave. |
There was a problem hiding this comment.
Worth including Vulkan terminology here as well?
| Uniformity of data and control flow are central concepts to SIMT execution | ||
| models, and is required for correct execution of shader programs. Despite | ||
| the importance of this fundamental property it is not represented in any | ||
| explicit way in the HLSL language. |
There was a problem hiding this comment.
Maybe mention that this requires backend compilers to attempt to analyse for uniformity?
| * `group_uniform` | ||
| * `simd_uniform` | ||
| * `quad_uniform` |
There was a problem hiding this comment.
It'd be good to explain how these relate to the dispatch, thread group, wave etc. scopes that were defined above.
| * `group_uniform` | ||
| * `simd_uniform` | ||
| * `quad_uniform` | ||
| * non-uniform (default state with no associated keyword) |
There was a problem hiding this comment.
Might be nice to have a way to explicitly mark non-uniform? Would leave open possibility of a "strict" mode where uniformity annotations are required and would allow developers to make their intent more explicit.
There was a problem hiding this comment.
I need to think on this. My intent was that we would only have a strict mode, so explicit uniformity would be required everywhere that requires uniformity, and that no annotation would mean non-uniform. With that approach I'm not sure how an explicit non_uniform helps, but maybe I'm missing something.
There was a problem hiding this comment.
I'm mainly wanting to avoid developers having to come up with naming or commenting conventions to document non-uniformity in their code, so I see it filling a role more like the signed keyword. (Although I expect now to be educated that signed actually does something more than I think it does)
| within a control flow block, the control flow is said to be _uniform control | ||
| flow_. | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
I'd love to know what, if anything, this proposal does to NonUniformResourceIndex.
There was a problem hiding this comment.
It should cease to exist, and I should capture that.
|
|
||
| ## Proposed solution | ||
|
|
||
| ### Uniformity as a Type Qualifier |
There was a problem hiding this comment.
Are there alternative approachs to using type qualifiers? I think doing so means we need to change the grammar?
Could something like:
group_uniform<int> myValue
Be made to work?
There was a problem hiding this comment.
If we have a template and non-template spelling that don't use the same words we could do something similar. For example:
template<typename T>
using GroupUniform = group_uniform TWould simply enable:
GroupUniform<int> MyInt;
Co-authored-by: Damyan Pepper <[email protected]>
Co-authored-by: Damyan Pepper <[email protected]>
Co-authored-by: Damyan Pepper <[email protected]>
Co-authored-by: Damyan Pepper <[email protected]>
There was a problem hiding this comment.
One more note for myself here:
The [[hlsl::required_uniform(..)]] attribute should imply to a function that it's initial control flow uniformity is the value set, otherwise all non-entry functions should assume default uniformity as non-uniform. Entry functions should assume default group uniformity.
The uniformity of each control flow block should be the intersection of the uniformity of the parent block and the condition (if any) that the block be entered.
|
Possibly related, it might also be worth talking about the whole "dynamic uniform" vs. "subgroup uniform" behavior. As dumb as it sounds, is Basically, what are drivers/hardware allowed to pack together into waves? This sort of packing is more common in the draw side of things (SV_InstanceID is infamously not uniform), but so far it's been very undefined. |
This has been sitting around in my checkout for close to a year, and I've been meaning to finish dumping thoughts into it and post it for wider review and feedback. So here goes!
Please be gentle, it's real rough.