On Tue, Jun 28, 2016 at 11:28 AM, Marek Olšák <mar...@gmail.com> wrote:
> On Mon, Jun 27, 2016 at 9:28 PM, Rob Clark <robdcl...@gmail.com> wrote:
>> On Mon, Jun 27, 2016 at 3:06 PM, Kenneth Graunke <kenn...@whitecape.org>
>> wrote:
>>> On Monday, June 27, 2016 11:43:28 AM PDT Matt Turner wrote:
>>>> On Mon, Jun 27, 2016 at 4:44 AM, Rob Clark <robdcl...@gmail.com> wrote:
>>>> > On Mon, Jun 27, 2016 at 7:13 AM, Alan Swanson <rei...@improbability.net>
>>>> > wrote:
>>>> >> On 2016-06-25 13:37, Rob Clark wrote:
>>>> >>>
>>>> >>> Some games are sloppy.. perhaps because it is defined behavior for DX
>>>> >>> or
>>>> >>> perhaps because nv blob driver defaults things to zero.
>>>> >>>
>>>> >>> So add driconf param to force uninitialized variables to default to
>>>> >>> zero.
>>>> >>>
>>>> >>> This issue was observed with rust, from steam store. But has surfaced
>>>> >>> elsewhere in the past.
>>>> >>>
>>>> >>> Signed-off-by: Rob Clark <robcl...@freedesktop.org>
>>>> >>> ---
>>>> >>> Note that I left out the drirc bit, since not entirely sure how to
>>>> >>> identify this game. (I don't actually have the game, just working off
>>>> >>> of an apitrace)
>>>> >>>
>>>> >>> Possibly worth mentioning that for the shaders using uninitialized vars
>>>> >>> having zero-initializers lets constant-propagation get rid of a whole
>>>> >>> lot of instructions. One shader I saw dropped to less than half of
>>>> >>> it's original instruction count.
>>>> >>
>>>> >>
>>>> >> If the default for uninitialised variables is undefined, then with the
>>>> >> reported shader optimisations why bother with the (DRI) option when
>>>> >> zeroing could still essentially be classed as undefined?
>>>> >>
>>>> >> Cuts the patch down to just the src/compiler/glsl/ast_to_hir.cpp change.
>>>> >
>>>> > I did suggest that on #dri-devel, but Jason had a theoretical example
>>>> > where it would hurt.. iirc something like:
>>>> >
>>>> > float maybe_undef;
>>>> > for (int i = 0; i < some_uniform_at_least_one; i++)
>>>> > maybe_undef = ...
>>>> >
>>>> > also, he didn't want to hide shader bugs that app should fix.
>>>> >
>>>> > It would be interesting to rush shaderdb w/ glsl_zero_init=true and
>>>> > see what happens, but I didn't get around to that yet.
>>>>
>>>> Here's what I get on i965. It's not a clear win.
>>>>
>>>> total instructions in shared programs: 5249030 -> 5249002 (-0.00%)
>>>> instructions in affected programs: 28936 -> 28908 (-0.10%)
>>>> helped: 66
>>>> HURT: 132
>>>>
>>>> total cycles in shared programs: 57966694 -> 57956306 (-0.02%)
>>>> cycles in affected programs: 1136118 -> 1125730 (-0.91%)
>>>> helped: 78
>>>> HURT: 106
>>>
>>> I suspect most of the help is because we're missing undef optimizations,
>>> such as CSE...while zero could be CSE'd. (I have a patch, but it hurts
>>> things too...)
>>
>> right, I was thinking that treating undef as zero in constant-folding
>> would have the same effect.. ofc it might make shader bugs less
>> obvious.
>>
>> Btw, does anyone know what fglrx does? Afaiu nv blob treats undef as
>> zero. If fglrx does the same, I suppose that strengthens the argument
>> for "just do this unconditionally".
>
> No idea what fglrx does, but LLVM does eliminate code with undefined
> inputs. Initializing everything to 0 might make that worse.
hmm, treating as zero does eliminate a lot.. anyway, I guess we'll
stick w/ driconf.
fwiw, with some help from the reporter, we figured out that this is
the bit that I need to squash into drirc:
<application name="Rust" executable="rust">
<option name="glsl_zero_init value="true"/>
</application>
now, if I could talk somebody into a r-b for this and the i965 fix? ;-)
BR,
-R
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
