On Wednesday 08 September 2010 11:40:24 Luca Barbieri wrote: > > If you're working on a driver for a scalar chip, you might want to pull > > brw_fs_channel_expressions and brw_fs_vector_splitting up and get them > > used -- it should make sensible codegen a lot easier for them. > > Current drivers for scalar hardware take Mesa IR/TGSI input and not GLSL > IR. > > Using GLSL IR might be interesting, but how do you plan to support > assembly programs? > Will a converter from Mesa IR to GLSL IR be used for that?
We intend to change the front-end for ARB fp/vp to generate GLSL IR directly. Then it would be compiled via whatever backend path your driver prefers. Since we also intend to write direct GLSL IR->915 and GLSL IR->965 backends, this would mean that Intel drivers won't use Mesa IR at all. Ideally, Mesa IR should go away eventually - if someone writes a GLSL IR->TGSI converter, none of the Gallium drivers would need it... > Having two hardware backends, one for GLSL IR, and one for Mesa > IR/TGSI doesn't seem to be a feasible long-term solution, and dropping > assembly program support also isn't (e.g. Doom 3 will stop working). > > Also, would converting GLSL IR to LLVM and writing an hardware LLVM > backend be a better idea? > That gives an instruction matcher, scalarizer and register allocator > for free, plus optionally middle-end optimizations. > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
