[virglrenderer-devel] TGSI to GLSL translator type assumptions

[Dave Airlie]

On 28 April 2018 at 12:03, Gurchetan Singh <gurchetansingh at chromium.org> wrote:
> I was wondering about the typing assumptions in vrend_shader.  The
> TGSI spec says that "all TGSI instructions, known as opcodes, operate
> on arbitrary-precision floating-point four-component vectors."
>
> http://gallium.readthedocs.io/en/latest/tgsi.html
>
> However, some instructions such as UMAD / UMUL / ATOMIMIN have integer
> source and destination registers, so I assume these instructions are
> exceptions to the spec.

There are tgsi_opcode_infer_src_type and tgsi_opcode_infer_dst_type interfaces,
however there may be some cases missing in those.

> One assumption we make is all temporary registers
> (TGSI_FILE_TEMPORARY) are a vector of floats.  We do a lot work making
> this assumption hold, with many conversions.  For example, the
> following TGSI:
>
> https://pastebin.com/PN8eHDvZ
>
> currently produces this GLSL:
>
> https://pastebin.com/p90gevMA
>
> I'm interested in the possibility of removing the
> "float(uintBitsToFloat)" and "int(floatBitsToInt)" steps, since I've
> found it to be a source of many bugs.  I would like to produce a GLSL
> like this:
>
> https://pastebin.com/fJCqYEjj
>
> By inferring the type of the declarations from the opcodes.  We would
> copy the tgsi_full_instruction(s) that are emitted in
> iter_instruction, deduce the type of the declarations, and then emit
> the declarations and instructions.  Is this advisable?

The main reasons I just go with all register being floats is when I wrote
this originally I left the possibility for using GL2.1 on the host which doesn't
have GLSL which necessitates integers (though I'm not sure I ever tested
that path much), and I didn't want to diverge too much from what TGSI expects.

TGSI expects floats in all those places, and while adding the bitcast conversion
is ugly, it is definitely the surest way to avoid bugs, as when you
miss one things
usually break.

Do you want temps to be always ints now? or try to infer the temp type? how does
that handle
I2F TEMP[0], TEMP[0] type scenarios? and temp arrays with different types,

I'd need a lot more info and some example shaders using floats to see
how it would end up.

Dave.