[Mesa-dev] gallivm and system values

[Jose Fonseca]

----- 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.


GPU LLVM backends don't really matter much here, as they have (or can have, if necessary) the ability to override any step of TGSI -> LLVM IR conversion to suite them best.


Does this address your question?


Jose