[Mesa-dev] TGSI declarations missing type info

[Christoph Bumiller]

On 14.11.2011 11:33, Jose Fonseca wrote:
>
> ----- Original Message -----
>> On 13.11.2011 17:32, Christoph Bumiller wrote:
>>> On 13.11.2011 17:10, Marek Olšák wrote:
>>>> I am guessing there is no type info because TGSI shaders are
>>>> allowed
>>>> to use uint, sint, and float instructions on the same register
>>>> without
>>>> type conversions (it would be possible to generate such usage with
>>>> GL_ARB_shader_bit_enconding, also GL_NV_gpu_program4 has typeless
>>>> registers too). I think GLSL has types because it's a typed
>>>> language,
>>>> not because it's needed for the underlying implementation. Do all
>>>> drivers need such info or is it just llvmpipe that would make use
>>>> of
>>>> it?
>>> If you don't have typed values in your backend IR and the hardware
>>> doesn't have dedicated integer and float registers, you don't need
>>> type
>>> info.
>>>
>>> With llvm you have both typed values and, for x86, different
>>> registers
>>> for integers and floats, so it seems it would be very helpful not
>>> to
>>> destroy all that information (gallium's favourite thing to do)
>>> before
>>> passing shaders to the driver.
>> Actually never mind, I just realized TEMPs are all stored in memory
>> in
>> llvmpipe, so you can just load into a value of the appropriate type,
>> as
>> determined by the instruction.
>>
>> For example, in lp_bld_tgsi_soa.c, emit_fetch, FILE_TEMPORARY case
>> you have:
>>
>> " cast temps_array pointer to float* " -- just do the same with int
>> or
>> whatever type your require and you should be fine.
>
> Having type info in TGSI registers is useless for llvm/llvmpipe, spite what initial appearances may be.
>
> Imagine indirect addressing on this hypothetical world with typed TGSI declarations:
>
>   DCL_float TEMP[0]
>   DCL_int   TEMP[1]
>   DCL_float TEMP[2]
>   DCL_int   TEMP[3]
>   DCL_float TEMP[4]
>   DCL_int   TEMP[5]
>
>   MOV OUT[0], TEMP[ADDR[0]]
>
> What LLVM type would one declare the TEMP array with? 4 x floats? 4 x int32s? 128bit integers? an union of all these?

Indirect addressing on TEMP should be forbidden and only allowed for
TEMPORARY_ARRAY, I'd very much like to know which values I can keep in
registers and which ones I have to store to thread-local memory (I can't
do things like MOV %e{%ecx}x but I have 128 registers).

Then there should be a declaration per array, and we can have our type.

The same issue goes for indirect address of IN, where not also not know
the type, but neither can you know the much more important interpolation
mode (note that the GLSL compiler currently generates the inefficient
"if (i == 0) MOV TEMP[0], IN[0] else if (i == 1) ...".

> Answer is: it doesn't matter, provided the type has 128bits.
>
>
> And with LLVM's bitcast operator, unions are totally unnecessary. As long as the temporary array is declared with a data type with the same bitwidth, one can always do for floats:
>
>   %0 = load <...> (...)
>   %1 = bitcast <4 x float> (%0)
>
> or for doubles:
>
>   %0 = load <...> (...)
>   %1 = bitcast <2 x double> (%0)
>
> or for ints:
>
>   %0 = load <...> (...)
>   %1 = bitcast <4 x int32> (%0)
>
> LLVM optimization passes should remove all this redundant bitcasts quite easily.
>
>
>
> The only place where integer/float/double knowledge would be necessary for TGSI translation would be for fragment shader interpolation. But given that so far interpolation is only defined for floats, there's no need.
>
>
> And I've looked at DX10 tokenized shaders, and the paradigm there too seems to be typed operations on typeless registers.
>
>
> So, AFAICT, typed TGSI registers only creates more headaches for zero benefit.
>
> Typed operations on typed registers seems to fit what drivers needs just fine.
>
>
> Jose
>
>