[Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps

Kenneth Graunke kenneth at whitecape.org
Wed Sep 8 11:59:08 PDT 2010

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list