[Mesa-dev] TGSI declarations missing type info

[Christoph Bumiller]

On 11/14/2011 10:36 PM, Christoph Bumiller wrote:
> On 11/14/2011 10:13 PM, Jose Fonseca wrote:
>>
....
>>
>> My other reply was about this particular case.
>>
>> But I'm not convinced we can ignore this case at all. I'm fine with drivers cutting corners. By I can't accept an interface that's broken by design for all drivers.
>>
>> The argument from TGSI_OPCODE_IF may very well come from the application/state tracker as CONSTs. This means that state tracker would need to sanitize every const -0.0f => 0.0f, or emit code that did that before passing the TGSI_OPCODE_IF.
>>
> 
> If it comes from CONST, it will be either a uniform of type boolean, and
> thus not a degenerate case, or
> for if ((float)), the compiler / TGSI converter will emit a cast too
> bool first (i.e. an (F/I/U)SET).

Also, from GL_ARB_uniform_buffer_object:

Members of type "bool" are extracted from a buffer object by reading a
single uint-typed value at the specified offset. All non-zero values
correspond to true, and zero corresponds to false.

> 
> It's not as messy as it sounds, we just need to define the exact
> behaviour of IF, and making its source a float (the *only* other choice
> to zero/non-zero) seems awkward (since I'm strongly against representing
> booleans as 1.0f/0.0f if integers are supported.)
> 
> The only way where we differ from SM4 is that our float comparison ops
> return floats, and with NativeIntegers, these are always followed by a
> conversion to our current boolean representation (~0/0).
> 
> We already have to make a distinction, if integers are not supported,
> glsl-to-tgsi has to turn all glsl-ir integer operations into float
> operations.
> 
>> Take a pick, but please keep this consistent.
>>
>> Jose
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev