Did Hell Just Freeze Over? Here's Evergreen On Gallium3D!

[pingufunkybeat]

AFAIK, all benchmarks presented here so far shows Gallium3D drivers to be much slower comparing to "traditional" Mesa closed source drivers. And difference usually looks pretty big. Is there any chance of closing this gap? Is there fundamental architectural problem in G3D? Ordinary users will hardly celebrate architectural perfection of AMD G3D drivers if performance is 3x worse all of a sudden for them.

First of all, Mesa is not closed source, it is open source.

r300g is already faster than r300c, so I don't think that this is an architectural issue.

The problem with r600g is that it is really really new and immature, and it is also missing a decent shader compiler. I expect it to catch up with, and overtake r600c eventually.

If you are talking about the proprietary Catalyst drivers (which have nothing to do with Mesa), it's a different story, and the proprietary drivers are likely to stay faster for a long time, probably forever. There are many reasons for this.

On the other hand, the performance of the open source drivers (most likely the Gallium-based ones) will approach the speed of the proprietary drivers, but this will take some time.

[bridgman]

Yep. Right now the maximum performance of a Gallium3D driver is a bit lower than the maximum performance of a classic driver simply because the upper level code is still written for classic drivers then uses an interface layer to work with Gallium3D drivers, but (a) that will go away over time and (b) the 300g code has already demonstrated that other improvements in the driver can more than make up for the (temporary) extra overhead of the interface layer.

[Tsiolkovsky]

Damn this is great news. Exciting times ahead. I'm glad I had the guts to buy a laptop with Evergreen chip a couple of months ago.

[markg85]

Very interesting development to say the least!

This really makes me think (and hope) that the next AMD GPU generation (6xxx) will start with Gallium rather then classic mesa! I just hope it starts of stable and preferably with kernel mode setting.

Perhaps a little to much to hope for?

Anyway a good job so far, AMD!

[pingufunkybeat]

Gallium drivers all require KMS, and I'm pretty sure that AMD won't waste time building a UMS code path for new hardware.

But The development is really good, and it's nice to have (more or less) functioning G3D drivers for all released hardware. That's a very impressive development, considering pretty much all of it was started 3 years ago, when the latest two generations were not even released, and most of the released ones only had very basic support for anything (all running with UMS)!

Here's the hoping that the Jerome's shader compiler makes good progress, and that r600g makes similar improvements to those observed with r300g.

[allquixotic]

Very interesting development to say the least!

This really makes me think (and hope) that the next AMD GPU generation (6xxx) will start with Gallium rather then classic mesa! I just hope it starts of stable and preferably with kernel mode setting.

Perhaps a little to much to hope for?

Yeah, "starting off stable" (i.e., the initial git commit being stable and 100% usable) is definitely too much to hope for. It's open source; it's supposed to have community help. They push out the rough bits that barely get things working, then leave it up to community devs to fix the "edge cases" (i.e. the 40% of the stuff that doesn't work).

If you wanted the initial support to be stable and 100% functional, you'd have to give them a full year (or more) of additional in-house development before making the initial push to freedesktop.org. That wouldn't benefit anyone; the (few) community developers wouldn't be able to contribute to it at all during that time, and the AMD guys would quickly fall behind the stride of hardware releases if they spent all their time polishing the driver in-house. There isn't enough manpower as it is; it's better to get the few community devs involved as early on as possible to further accelerate the progress. Case in point, Dave Airlie and others have been doing great with evergreen on gallium, but I don't think the AMD devs have touched it at all. They've just been working on classic mesa.

[droidhacker]

There isn't enough manpower as it is; it's better to get the few community devs involved as early on as possible to further accelerate the progress. Case in point, Dave Airlie and others have been doing great with evergreen on gallium, but I don't think the AMD devs have touched it at all. They've just been working on classic mesa.

Who says there isn't enough manpower? They've been building drivers faster than they're building new hardware! If that wasn't the case, they couldn't possibly have been able to catch up to FIVE YEARS OF BACKLOG (as well as two new hardware generations) in just THREE years.

As for Dave Airlie and co... red hat, etc... contributing to the drivers early on... you can clearly see that RH works closely with AMD on this. Don't you don't think that it might be possible for RH to get a few engineering samples early on to hack on? Up until now it hasn't been such a major requirement since the work has all been on EXISTING and RELEASED hardware, but it is very likely that AMD would be happy to spread around some samples earlier than release.

[bridgman]

The developers do all stay in constant communication, and there's a lot of "ok, I'll work on this, you work on that, and when they both sorta work we'll put them together" decision making going on all the time.

[bash]

Yep. Right now the maximum performance of a Gallium3D driver is a bit lower than the maximum performance of a classic driver simply because the upper level code is still written for classic drivers then uses an interface layer to work with Gallium3D drivers, but (a) that will go away over time and (b) the 300g code has already demonstrated that other improvements in the driver can more than make up for the (temporary) extra overhead of the interface layer.

So can we expect the 300g/600g drivers to get close(r) to the closed source driver performance in the next year or two? Or is that out of the picture for at least a couple of years?

[bridgman]

Yep, I think the developers are starting to approach the point where the basic functionality will be there and improving performance will be a good use of time. You'll know when 90% of the posts stop being about functionality/bugs and start being about performance

The main point I was trying to make was that it's not the simple fact of being a Gallium3D driver that will make the 300g/600g drivers go faster, it's that the code is smaller/cleaner which will make some of the performance work easier in the future.

That said, a lot of the performance work is probably going to have to be done outside of the "Mesa HW driver" / "Gallium3D HW driver" anyways - either in the upper layers of Mesa or in the lower level libdrm/drm code - and both of those are common to classic and Gallium3D drivers anyways.