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

[Eric Anholt]

On Wed, 8 Sep 2010 20:25:15 +0200, Luca Barbieri <luca at luca-barbieri.com> wrote:
> > 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
> driver.
> 
> 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

So you're taking the GL state from Mesa's structures, munging it into
intermediate structures, then presenting me with intermediate objects?
The biggest thing I've found for CPU-side performance on 965 was that
you want to avoid some sort of intermediate state step for everything
but shader compile.  I've seriously thought about going back to the
915-style immediate mode state updates for 965 -- anecdotal evidence
From other groups says that this is *immense* win.

> - 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.

There are two things I find attractive about gallium, you nailed one of
them:

1) LLVM backends for software
2) Not having to write texture upload/download/blit/etc. code, just the
layout.

Now, the layout's the part that we screw up the most, and you have to do
it either way.  But the layout, at least as Intel does it, makes
upload/download/copy tough, so not doing that part in the driver somehow
would be nice (2.5kloc or so that's been copied around a few times).
However, the fact that when I ask about performance nobody says "OMG the
texture upload/download/copy/etc. support in gallium is so great and is
way faster than anybody managed in classic because it catches all the
corner cases" makes me really scared about it.

I always wished that instead of gallium we had just got a reworked
implementation of texture handling in Mesa.

> - Ability to get support for APIs other than OpenGL (e.g. the DDX
> interface, OpenVG, with work on Cairo,

These 3 only seem interesting to me once you've abstracted the hardware
abstraction layer that you have to implement anyway, so that you want to
talk to gallium to avoid the overhead of the abstraction layer ->
abstraction layer translation.  Having written cairo on OpenGL and a
partial implementation of X on OpenGL, if you can assume GLSL then
OpenGL is a good interface for talking to the hardware.  If you can't
assume shaders, well, gallium isn't an option anyway.

I do not want to write assembly for cairo's gradients or new blend
operators or whatever.  If your hardware abstraction layer doesn't give
me a decent language to talk to in 2010, it sounds like failure.

> OpenCL, video APIs) mostly for

These two, on 965, want to use the media engine, so I don't see
significant sharing to be had between a gallium OpenGL driver and a
gallium media driver.  You'd share the batchbuffer code, maybe the
buffer object handling, texture layout functions for inter-API
interaction, what else?  Batchbuffers we've wanted to put into libdrm
for years but never got around to it, and if we've got multiple things
layouting textures, then we'd probably throw that into the shared lib
instead of duping it, too.

And, as far as video APIs, open-source codec guys tell me they want
OpenCL or please go away.  Intel codec accel guys just write assembly by
hand like real men (wtf?) and stuff it in vaapi.  Neither of these sound
like video APIs on gallium to me.  (though please don't interpret this
as me pushing vaapi.  The lack of a shipping gstreamer plugin for vaapi
pretty much summarizes vaapi's relevance to me.)

> - Sharing the code to support all the legacy features and weird corner
> cases of OpenGL and not exposing the driver to them

This is definitely something good, and meta.c's been mostly working for
that in classic Mesa.  If we cleaned up renderbuffer handling so the
window system FB vs FBOs weren't magic, then I'd be happy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100908/b9052546/attachment.pgp>