----- Original Message ----- > > > ----- 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? > > 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.
Typo. I meant, typed operations on _typeless_ registers seems to fit what drivers needs just fine. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
