[Mesa-dev] gallivm and system values

[Brian Paul]

On 02/28/2012 12:59 PM, Jose Fonseca wrote:
>
>
> ----- Original Message -----
>> Hi guys,
>>
>> So I've gotten llvmpipe GLSL 1.20 support with native integers
>> enabled
>> to be 0 regressions from non-integers enabled.
>>
>> The one big problem I've hit is non-native integer llvmpipe uses
>> system_values, it takes them in as integers and converts them to
>> floats and stores that value, however the state trackers assume that
>> system values are stored as integers, so we don't ever see any
>> explicit F2I, so although we do bit casting we get the wrong value
>> since it isn't converted back to an integer anywhere.
>
>> Now I don't think support instance id pre GLSL 1.40 works properly
>> anyways.
>>
>> But I'm open to suggestions on how to handle it:
>>
>> a) drop support for float system values, don't advertise instance id
>> since we don't let apps use it properly. Just use integers.
>>
>>
>> b) add a mechanism for gallivm to know if its operating with native
>> integers or not advertised and have it do something, the reason I
>> don't like this is so far this is the only case where this is a
>> problem, gallivm code so far has not need to know what the driver was
>> advertising above it.
>
>
> I'm not sure I fully understood the problem, so I may be missing the point.
>
>
> I think that when used by draw/llvmpipe, gallivm should match precisely in the same way as src/gallium/auxiliary/draw/draw_vs_exec.c and src/gallium/auxiliary/tgsi/tgsi_exec.c do.
>
> If TGSI is generated such way that TGSI_SEMANTIC_INSTANCEID/TGSI_SEMANTIC_VERTEXID values are assumed to be integer, then we need to follow that on gallivm too.
>
> But note that TGSI_SEMANTIC_FACE is assumed to be float. So if you want to make all system values integer, you'll need to update everywhere where TGSI_SEMANTIC_FACE is used. So maybe, we should make this decision based on semantic first, and not of file. (I don't think one can indirectly index system values, so each system value could be backed by its own LLVMValueRef, of different types.

Yeah, I'd expect the various system values to have different types 
depending on what they're for.

BTW, I think the TGSI docs are lacking in the area of system values...

-Brian