[Mesa-dev] [PATCH 1/2] mesa, gallium: add a cap for GPUs without unified color+generic varying slots

[Ian Romanick]

On 12/14/2011 01:47 PM, Marek Olšák wrote:
> On Wed, Dec 14, 2011 at 6:30 PM, Ian Romanick<idr at freedesktop.org>  wrote:
>> On 12/13/2011 04:32 PM, Marek Olšák wrote:
>>>
>>> ---
>>>   src/gallium/drivers/r300/r300_screen.c |    3 ++-
>>>   src/gallium/include/pipe/p_defines.h   |    3 ++-
>>>   src/glsl/linker.cpp                    |    6 ++++++
>>>   src/mesa/main/mtypes.h                 |    9 +++++++++
>>>   src/mesa/state_tracker/st_extensions.c |    3 +++
>>>   5 files changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/r300/r300_screen.c
>>> b/src/gallium/drivers/r300/r300_screen.c
>>> index 0bae065..a761939 100644
>>> --- a/src/gallium/drivers/r300/r300_screen.c
>>> +++ b/src/gallium/drivers/r300/r300_screen.c
>>> @@ -102,6 +102,7 @@ static int r300_get_param(struct pipe_screen* pscreen,
>>> enum pipe_cap param)
>>>           case PIPE_CAP_TEXTURE_BARRIER:
>>>           case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS:
>>>           case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
>>> +        case PIPE_CAP_SEPARATE_COLOR_VARYINGS:
>>>               return 1;
>>>
>>>           /* r300 cannot do swizzling of compressed textures. Supported
>>> otherwise. */
>>> @@ -182,7 +183,7 @@ static int r300_get_shader_param(struct pipe_screen
>>> *pscreen, unsigned shader, e
>>>                * R500 has the ability to turn 3rd and 4th color into
>>>                * additional texcoords but there is no two-sided color
>>>                * selection then. However the facing bit can be used
>>> instead. */
>>> -            return 10;
>>> +            return 8;
>>
>>
>> Why are you trying to make r300g behave differently the every other driver
>> that has existed for that same hardware?  This doesn't make any sense.  This
>> is not Apple's driver works for r300 hardware, and it's not how AMD's
>> Windows driver works (worked, anyway) for r300 hardware.
>>
>> This feels like an unnecessary hack.
>
> Hi Ian,
>
> Simple. I cannot pass the test glsl-max-varyings if I report 40
> varying components, because I have only 32 texcoord components + 8
> color components. I could re-use the color varyings, but it's not full
> single-precision. r300 uses a fixed-point type S3.12 for color
> interpolators, which can represent values in the range [-7.9999,
> 7.9999]. That's unusable for used-defined varyings. r500 uses a 20-bit
> float, which is better, but I am not sure if it's good enough.

The desktop GL spec isn't very specific about range or precision before 
either a late 3.x version or one of the 4.x versions (I don't recall 
which).  However, I'm pretty sure ES2 requires 24-bit float.  Is 20-bits 
even a real computer number? :)

This also means that r300 and r500 can't handle unclamped colors. 
Right?  I'm thinking of the scenario:

  - The driver advertises 32 varying components.

  - The application calls glClampColorARB(GL_CLAMP_VERTEX_COLOR_ARB, 
GL_FALSE).

  - The shader uses gl_Color and 32 components worth of other varyings.

What happens?  Are the colors partially clamped or what?  Since color 
clamping is set independent of compiling or linking, you don't have an 
opportunity to generate any errors up front.

It sounds like the colors have to go through different interpolators 
anyway if glClampColorARB(GL_CLAMP_VERTEX_COLOR_ARB, GL_FALSE) is used. 
  Is that handled correctly?

Now I'm really curious to see glsl-max-varyings run on an Apple system 
with an r300.  Scouting around, that looks like it would have to be a G5 
iMac or PowerMac.  Hrm...

> Also, r500 actually has 10 texcoord interpolators, but we don't use
> the last two yet (it's non-trivial, there is a special PS3 mode for
> it). Whether color interpolators can be enabled in that mode is
> undocumented, though I am almost sure the back colors cannot be. (the
> DX9 ps_3_0 shader profile doesn't have color inputs at all)

If colors are counted, you don't need to worry about that.  40 varyings 
means 40 varyings.  Clamped colors would go to the usual slots (leaving 
2 texcoords unused), and clamped colors would go in two of the texcoord 
slots.

> Yes, the patch is a hack. However modifying glsl-max-varyings to only
> test MAX_VARYING_FLOATS - 8 doesn't feel right either. Do you have a
> better idea?
>
> What about the other patch?

I need to do some research about that.  I'm pretty sure i915 needs a 
slot for WPOS.  I want to collect some more data and see if there's a 
coherent architecture that works for the various platforms.  We're 
starting to get a big pile of band-aids, and that can't hold up in the 
long run.