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

Nicolai Hähnle nhaehnle at gmail.com
Mon Jan 9 11:58:21 UTC 2017


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.

Nicolai


More information about the mesa-dev mailing list