[Mesa-dev] i965 SamplerUnits rework

[Kenneth Graunke]

On 08/25/2012 11:02 AM, Eric Anholt wrote:
> Kenneth Graunke <kenneth at whitecape.org> writes:
> 
>> On 08/24/2012 10:07 AM, Eric Anholt wrote:
>>> Kenneth Graunke <kenneth at whitecape.org> writes:
>>>
>>>> Greetings!
>>>>
>>>> This series reworks how i965 deals with sampler indirections, changing it
>>>> to use linker-assigned sampler variable IDs in SEND instructions rather 
>>>> than baking in the ID of the texture unit they happen to be bound to.
>>>>
>>>> Instead, it now encodes that mapping in the binding, sampler state,
>>>> and sampler default color tables, which are updated and re-emitted at least
>>>> once per batch anyway.
>>>
>>> Nice work!  I think there's a cleanup available by making the texture
>>> state part of the program key sampler-indexed as well, but that's
>>> something that can be done later.  The texunit name change in the early
>>> patches definitely helped make for easy reviewing.
>>>
>>> Long term, we'll have to split our sampler/texture state tables for
>>> ARB_sso, but I'm OK with this series because nobody uses EXT_sso and it
>>> fixes a massive performance bug.
>>
>> Yeah, I neglected to mention...I'm not sure how best to do this in the
>> presence of separate shader objects.  To clarify, though, you're saying
>> that we have a pre-existing bug in our EXT_sso support, right?  Not that
>> my series breaks it.
> 
> I think it does newly break it -- if under EXT_sso both vs and fs do
> texturing, using different texunits from the same sampler index would
> result in the wrong texture being chosen for one of them.

Sigh.  You're right, of course.

Surface state is fine as is---we iterate over the combined number of
samplers in both program, and fill in both tables using each stage's
SamplerUnits map.  Duplicates will work fine.

Sampler state and SDC is broken for SSO programs where both stages do
texturing.  I can fix this by emitting separate per-stage tables.  For
linked programs---by far more common---we want to avoid doing that since
it just wastes batch space and CPU time.

Is there a good way to detect when we're in the SSO case?  If so, it
should be easy to fix in a way that remains optimal for non-SSO.

I also seriously question whether we should be advertising EXT_sso.  As
Eric said, almost nobody uses it (they want ARB_sso), and we have barely
any test cases (a mere 5 basic tests).  oglconform only has ARB_sso
tests...none for EXT_sso.