[Mesa-dev] [PATCH] radeonsi: fix the Witcher 2 black transitions

[Marek Olšák]

On Mon, Jan 9, 2017 at 12:58 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On 09.01.2017 12:28, Marek Olšák wrote:
>>
>> On Mon, Jan 9, 2017 at 12:09 PM, Nicolai Hähnle <nhaehnle at gmail.com>
>> wrote:
>>>
>>> On 09.01.2017 11:40, Marek Olšák wrote:
>>>>
>>>>
>>>> On Mon, Jan 9, 2017 at 9:40 AM, Nicolai Hähnle <nhaehnle at gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Interesting, this suggests a bug in the LLVM WQM stuff. Anyway, it
>>>>> makes
>>>>> sense for now.
>>>>
>>>>
>>>>
>>>> Or more likely: v_interp is executed after KILL, which breaks WQM.
>>>
>>>
>>>
>>> That's only relevant for derivative calculations, though, and I thought
>>> those were undefined in GLSL after (non-uniform) KILL? Or is something
>>> (LLVM? GLSL compiler copy-propagation?) too eager in sinking the place
>>> where
>>> inputs are loaded?
>>
>>
>> Inputs are not "loadable" in GLSL. They are preloaded from the
>> beginning. radeonsi has the option to load them lazily. If that
>> happens after KILL, the loads are no longer in WQM. The only thing
>> that can break non-lazy preloading is when input loads are moved
>> across the KILL intrinsic by LLVM.
>
>
> Right. But from the patch, my understanding is that the problem is somehow
> related to derivative computations, and GLSL clearly says that "Derivatives
> are undefined within non-uniform control flow."
>
> radeonsi wants to create code like
>
>   v_interp
>   <derivative sequence>
>
> As long as the <derivative sequence> is in (dynamically) uniform control
> flow, so should the v_interp. Conversely, if the derivative sequence (and
> the v_interp) happens after a kill, then the GLSL must have relied on
> undefined behavior, or we've incorrectly sunk the derivate sequence to after
> the kill somewhere.
>
> It's actually quite plausible that a dFdx(input) will work correctly even
> under non-uniform control flow with most drivers, because most drivers will
> pre-load the input (like radeonsi with your patch), and so it's plausible
> that shaders in the wild rely on this even though doing so is wrong.
>
> Anyway, this is all speculation without looking at the actual shader in
> question.

My interpretation of GLSL is that: If WQM is used, all inputs must be
interpolated in WQM and the interpolation can't be moved outside of
the WQM block.

Therefore, v_interp sinking across a WQM boundary (e.g. KILL) is incorrect.

Marek