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

Luca Barbieri luca at luca-barbieri.com
Wed Sep 8 11:25:15 PDT 2010

> I keep hearing this, and a bunch of people have been trying to build the
> equivalent gallium hardware drivers to various core drivers for a long
> time.  So, can we get some details on a success story?  What driver is
> now more correct/faster than it was before?  By how much?  How much of
> that was hardware enabling you did on the gallium side only?

I think Corbin Simpson and Marek Olsak could be the best people to
comment on this, since they mostly wrote the r300g driver, which seems
now to be the preferred driver, instead of the older r300 classic DRI

Dave Airlie extensively contributed both to the r300 DRI driver and to
r600 Gallium drivers, and possibly others are in a similar position.

Keith Whitwell wrote the current Gallium i965 driver, and as far as I
know stopped work on it due to other commitments.

Personally I never worked on classic drivers, so I can't really give a
thorough comparison.

The general advantages of Gallium are, as I see it, are:
- Ability to write the driver in a more maintainable "object-oriented"
fashion, where you just provide code to create hardware-specific
objects from general self-contained descriptions and then bind them to
the pipeline
- Rich set of auxiliary code, much more modern than the Mesa code
(kind of like your GLSL compiler vs the old one). Among others, this
includes the draw module that by default executes vertex and geometry
shaders with LLVM.
- Ability to get support for APIs other than OpenGL (e.g. the DDX
interface, OpenVG, with work on Cairo, OpenCL, video APIs) mostly for
free, and much more efficiently and cleanly than if they were layered
on top of OpenGL, which may require custom interfaces anyway
- Sharing the code to support all the legacy features and weird corner
cases of OpenGL and not exposing the driver to them

More information about the mesa-dev mailing list