[Mesa-dev] [PATCH v3 00/13] TGSI: improved live range tracking, also including arrays

[Gert Wollny]

[...]
> 
> $R600_DEBUG=merge ST_DEBUG=tgsi ./run wollny/
> 
> ATTENTION: default value of option
> allow_glsl_extension_directive_midshader overridden by environment.
> run: state_tracker/st_glsl_to_tgsi.cpp:5783: ureg_dst
> dst_register(st_translate*, gl_register_file, unsigned int, unsigned
> int): Assertion `array_id && array_id <= t->num_temp_arrays' failed.

This would indicate that the array is split, but still addressed
somewhere, i.e. I don't look at all possible locations where arrays are
used. I think I debug this by letting the R600 driver advertise
bindless texture support (obvioulsy it will not pass the tests, because
it is not implemented and  the hardware may not even support it, but
the GLSL->TGSI conversion should still work. 


> 
> 
> I can, if you dont mind waiting for an answer sometimes.
> 
I will rely on this, but I also will take some time do work on it. 


> But maybe even easier: is there an implicit/explicit magic number I
> can play with to see if it changes anything?

Unfortunately, in my code there are no specific magic numbers to
change, if there is anything then it is probably in the LLVM backend
(that is not used with r600). 

The only think you could try is to disable one of the two parts in my
code: one is the split_array(), called around 

  st_glsl_to_tgsi:7018 

and the other is where the array merging and interleaving are applied,
i.e. line 

  st_glsl_to_tgsi:5537

My take is that this latter step is responsible for the regressions, 
especially the array interleaving could make it more difficult to
optimize, because if the optimizer pass doesn't look at a per-component 
access, but on the higher level per-register base, then register live-
ranges for the array elements will become longer, making it more
difficult to schedule everything without spilling.


> ATM it seems like your code improves half the shaders its affecting a
> lot and hurting the other half bad like it hits an invisible wall.
> I think one problem could be the relationship between VGPRs and SGPRs
> used and max Wavefronts achieved.
Unfortunately, on r600 such fine grained information is not available,
so that I also have no real clue. 

Cheer,
Gert