> > 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? > > Answer is: it doesn't matter, provided the type has 128bits. Yeah from my POV It was mainly just how lossy the IR, we drop all this information at the GLSL->TGSI boundary, and then reconstruct it from the opcodes on the other side, but I agree now that I've played some more with llvm that we probably don't require it at this point to the extent I mentioned, I've been playing with the bitcasts a bit now. The next open question I have is whether this warrants additions to the tgsi_opcode_info struct, mainly whether the return value is uint/int/float, and whether then src regs are uint/int/float, I'm not 100% that all opcodes always take all int/uint/float srcs, but my memory is a bit hazy on what the outliers might be. DAve. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
