On 09.01.2017 12:28, Marek Olšák wrote:
On Mon, Jan 9, 2017 at 12:09 PM, Nicolai Hähnle <[email protected]> wrote:
On 09.01.2017 11:40, Marek Olšák wrote:
On Mon, Jan 9, 2017 at 9:40 AM, Nicolai Hähnle <[email protected]> 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
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
