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

[Marek Olšák]

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.

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)

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?

Thanks,
Marek