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

[Dave Airlie]

On Thu, Sep 9, 2010 at 3:28 AM, Eric Anholt <eric at anholt.net> wrote:
> On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri <luca at luca-barbieri.com> wrote:
>
>> It would be great if Intel switched to the i915g and i965g Gallium
>> drivers, since everyone else is concentrating their attention on
>> Gallium, since it's much easier and better to write drivers for it.
>
> 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?

r300g is a lot more successful than r300 classic, support for things
like texture tiling and hyper-z were a lot easier to add to the
gallium driver. These were very difficult to add to classic.

The thing is you miight enjoy fixing upside down FBO ordering for the
10th time, I personally would rather not know, and that goes for every
other corner case in the GL spec that is abstracted away from the
driver.

Having to not distinguish between and FBO and a rendering buffer,
having to not look at visual bits vs renderbuffer bits etc. Texture
transfers, and accelerated readpixels for free, I could go on.

The only upfront pain I really find with gallium is the winsys/pipe
split, I find it mostly unnecessary for writing drivers on Linux and
have no need to use those drivers on other non Linux OSes.

Really it would be worthwhile taking the i915g driver and fixing it as
an exercise so you get llvm draw for free instead of NIHing llvm draw.

I'm also disappointed that i915g and i965g never materialised in a
useful form, I'm still tempted to write i965g myself, and maybe after
r600g is finished I can find some time to bring it up.

Dave.