[Mesa-dev] TGSI declarations missing type info

[Jose Fonseca]

----- Original Message -----
> 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).

Yes, separating out arrays is light years more important that typing, and on its own right, as it seriously impairs optimization.

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

It's still unclear to me what typed registers buy over typed operations.

When one translates a floating point addition operation, one immediately knows that the inputs are floating points and the outputs as well. Ditto for integers.

And type is not truly a property of the temporaries anyway, but of the intermediate values. And if you're doing any decent optimization, you'll transform the IR to SSA, and you'll annotate the types on the SSA values, and not the temporary storage, so that you can handle unions and bitcasts efficiently.

Passes like trying to minimize the number of temporaries would be come much harder/inefficiency with typed registers, as they would need to be type aware.

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

Ouch.

Jose