<div class="gmail_quote">On Thu, Sep 9, 2010 at 2:35 AM, Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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. </blockquote></div> OK so there you have it: The texture upload/download/copy is way faster in r300g than anyone managed in r300c. For example, the ETQW main menu uses some texture streaming and I get 1 fps in r300c and about 30 fps in r300g. That's not something one can ignore. The transfers in r300g were really simple to implement, it's just transfer, map, unmap, transfer (transfer=blit). The code is clean and isolated (about 250 LoC). This is just the driver code. There is also some additional transfer code in st/mesa, but I didn't have to care about that. The overall speed of r300g is either at the same level as r300c or higher, based on what application you look at. Various users have reported that, unlike r300c, all compiz effects just work, kwin works, a lot more games work, and the driver is faster in some apps. We used to have some performance issues in Tremulous not so long ago, but that's been fixed since then. Of course, one can find synthetic tests where one driver is always faster than another. I am talking about real world applications here. For example, I no longer have to kill Strogg in ETQW with the lowest details on my R580 for it to be smooth. r300g is quite optimized (I say "quite", because you're never sure), so the overhead of other mesa components is larger than other Gallium drivers might be able to see. In Tremulous, the overhead of r300g+libdrm is under 50% of the whole time spent in Mesa, and that's without using Draw, so we should start caring about the speed of st/mesa and mesa/main. The only obvious way to get some speed there seems to be merging Mesa core with st/mesa, dropping the classic driver inteface, and simplifying the whole thing. I guess this won't happen until everybody moves to Gallium. It's a sure thing Gallium is the future, and it doesn't seem to be a good idea to implement e.g. LLVM-powered vertex shaders for classic, considering the same thing has already been implemented and now stable in Gallium. The only disadvantage of Gallium seems to be TGSI. It's not better than Mesa IR, because all shaders must pass through Mesa IR anyway. I suppose using GLSL IR or something similar would help some drivers produce more optimized shaders (I am getting at temporary arrays here, which r300 hardware partially supports). Marek