Lexically scoped uniform lifetime rules

[magcius]

Is your feature request related to a problem? Please describe.
Not sure exactly what to call this, but I want to talk about this section of the HLSL specification. This is one of the few places in the specification that explicitly says that code of this type is invalid.

The rationale for why this code is invalid is a bit stretched, and suggests that an optimizer doing lifetime analysis might reuse registers between two edges of a branch.

Describe the solution you'd like
I'd like the code provided to be valid, and for it to be invalid for an optimizer to shuffle lifetime/registers in a way that modifies wave uniformity concerns. I want this to be valid:

float2 temp_uv = modifyuv(uv);
if (pos.x <= SCREEN_UV) {
    ret = tex.Sample(s0, temp_uv);
}

while I am OK with this remaining invalid:

if (pos.x <= SCREEN_UV) {
    float2 temp_uv = modifyuv(uv);
    ret = tex.Sample(s0, temp_uv);
}

That is, lexical scoping defines the uniformity. If a value is lexically calculated or assigned outside a branch, moving it inside a branch is an invalid optimization when it might affect derivatives/wave uniformity.

It is getting exceptionally difficult to write code that behaves the way I want in the presence of control flow, wave intrinsics, and optimizing compilers, and would like some guarantees that doesn't feel like I'm building on top of quicksand.

Describe alternatives you've considered
If we consider it too costly to make this code valid and want it to remain invalid, then I would like some more concrete specifications and rules for why this code is valid or invalid, and what guarantees we do have, and would like to talk about more language extensions so we can be more explicit (pragmas? annotations?)

"Don't mix wave/texturing operations and control flow" isn't actionable advice.

Additional context
This intersects with other HLSL work on uniformity, NURI, and maximal reconvergence.

[llvm-beanz]

@magcius, I think that spec is just wrong. We actually do a bunch of crazy stuff in DXC to make that code work specifically for samples. I don't think we extend it to wider quad ops though.

[magcius]

What guarantees do we have about code like this working? Can we put any good bounds on it? Right now all we have is this spec, unfortunately.

[llvm-beanz]

What guarantees do we have about code like this working?

Not many... It should work when targeting DXIL, but likely won't targeting SPIRV today. We don't really represent this in a sane way in the type system so the only way we get this "right" is because we have this pass in DXC, that traverses up from uses of UV coordinates in a limited set of operations and we annotate the calculations as convergent so the optimizer can't move them into different control flow.

Can we put any good bounds on it?

Today, we have what we have... we should think more carefully about this as we consider bringing concepts of uniformity into HLSL. I don't think that's going to be in the short term though.

Right now all we have is this spec, unfortunately.

We should update the spec to not have an example that we clearly intentionally support. I've filed an issue on the spec: microsoft/DirectX-Specs#206.

[tex3d]

@llvm-beanz:

@magcius, I think that spec is just wrong. We actually do a bunch of crazy stuff in DXC to make that code work specifically for samples. I don't think we extend it to wider quad ops though

I believe this is not correct.

While it's true that DXC will avoid sinking the computation of temp_uv into the branch due to convergent marking, the Sample operation itself is still not well-defined when performed in the non-uniform branch because it requires implicit derivative operations which are not well-defined when they include inactive threads.

The reason it's well-defined if you supply an input interpolant directly is because those values and their derivatives are constant for each thread and available for the entire shader invocation, separately from temporary register states.

I admit that the details in this area are subtle, and often not well explained. That's unfortunate, and we do intend to improve this area in the future, though at some level, it can simply be difficult to grasp at first for someone who isn't experienced in this area. We also intend to improve the language and compiler/tooling to help shader authors more easily write well-defined, reliable, cross-platform code in HLSL, as @llvm-beanz linked to the rough uniformity proposal in the previous comment.

Example 4 demonstrates how to use QuadAny to ensure that a full quad will participate in the Sample operation, while avoiding the Sample operation on quads that don't contribute to ret.

Another way to handle this is to explicitly compute the derivatives with ddx and ddy outside the non-quad-uniform control flow, then use SampleGrad instead of Sample. This could even be combined with QuadAny to limit coordinate and derivative computation to active quads.

Note, a compiler could perform the necessary transforms to make this code legal, but that can be fragile and can lead to unreliable and unpredictable implicit behavior that's difficult for a shader author to reason about. It can be easy to imagine the compiler legalizing trivial examples like these, but it gets a lot more complicated and unreliable in more complex scenarios, not to mention that the compiled shader will end up doing something different than what you explicitly wrote in HLSL. For instance FXC might try to hoist the sample operation for you, but there are a number of conditions that could prevent this from working (it would also require -all-resources-bound).

In summary, using lexical scope to define uniformity does not make the example well-defined. The problem is the derivative operations implied by the Sample operation itself, which would be like expecting a Wave operation inside the control flow to use values from threads that are not participating in this control flow. You must place the cross-thread (wave) operation in a flow control scope where all the threads needed to participate are active.

[magcius]

I admit my example was a bit simple, but the point I wanted to make more clearly was that as ISVs, we currently have no guarantees as to whether this code is valid or not, and without a mental model and guarantees for extremely simple cases, how can we build larger, more complex systems at all?

The reason it's well-defined if you supply an input interpolant directly is because those values and their derivatives are constant for each thread and available for the entire shader invocation, separately from temporary register states.

My proposal was to suggest that HLSL adopt semantics where that temporary register must be held alive based on lexical rules; e.g. for Sample operations, the register used to store UVs passed to sampling needs to be kept valid if the variable was lexically defined outside of that branch even if the wave becomes inactive due to flow control, and any optimization that would reuse the register is invalid.

If you feel that's unfeasible from a performance or implementation standpoint, then that's fine, although disappointing to me. Are there any middle ground options here that would help me ship shaders with confidence? Can we get in writing what guarantees we do have?

Note, a compiler could perform the necessary transforms to make this code legal, but that can be fragile and can lead to unreliable and unpredictable implicit behavior that's difficult for a shader author to reason about.

Already today, things feel extremely fragile when combining wave operations, texture sampling, and flow control. I understand that part of this might be solved with future additions to HLSL, and I'm very excited for that. But even without language changes, I'd like to explore what semantics guarantees we could have.

For an example of the complex systems I have in mind, I recently spent days trying to debug this shader and error message. I know it's a bit of an unrelated issue, but it's an example of mixing wave operations, sampling, and flow control that I dealt with in the wild.

The problem is the derivative operations implied by the Sample operation itself, which would be like expecting a Wave operation inside the control flow to use values from threads that are not participating in this control flow.

I want these code examples to become valid as well:

float2 temp_uv = modifyuv(uv);
if (pos.x <= SCREEN_UV)
    ret = QuadReadAcrossX(temp_uv);

float2 temp_uv = modifyuv(uv);
if (pos.x <= SCREEN_UV)
    ret = WaveReadLaneAt(temp_uv, WaveGetLaneIndex() ^ 15); // Assuming there are at least 32 lanes in this invocation