On Wed, 8 Sep 2010 20:25:15 +0200, Luca Barbieri <l...@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.
pgp9oXGdt1eZO.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
