[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