[Mesa-dev] [PATCH 1/2] glsl: add driconf to zero-init unintialized vars

[Rob Clark]

On Mon, Jun 27, 2016 at 7:13 AM, Alan Swanson <reiver at 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 <robclark at 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.

I did have the idea to try and only inject the initializer when the
compiler warns about uninitialized vars, but in the presence of flow
control there seem like some cases that glsl doesn't catch.

BR,
-R


> --
> Alan.
>