Gallium3D Now In Mainline Mesa Code-Base!

[phoronix]

Phoronix: Gallium3D Now In Mainline Mesa Code-Base!

Gallium3D, the 3D graphics driver that has long been in development by Tungsten Graphics, has finally entered the mainline Mesa code-base! Gallium3D has a lot of capabilities and will be of much benefit to Linux desktop users once all 3D drivers have been ported to this new architecture (for more information read our articles or the Tungsten Wiki). We shared yesterday that Gallium3D was in the process of being merged and that is now completed within Mesa's master branch...

http://www.phoronix.com/vr.php?view=NzA1Ng

[bridgman]

This is actually a really important milestone for open source 3D drivers; while Gallium3D was hanging out in a branch it wasn't really a practical solution for mainstream drivers. Now that it's in master I think you'll see everyone pile on and start working towards shipping Gallium3D-based drivers. Congrats to all involved.

[Svartalf]

This is actually a really important milestone for open source 3D drivers; while Gallium3D was hanging out in a branch it wasn't really a practical solution for mainstream drivers. Now that it's in master I think you'll see everyone pile on and start working towards shipping Gallium3D-based drivers. Congrats to all involved.

Indeed. It translates into something that could get within spitting distance of the peak performance of the proprietary drivers. It makes the story your employer's got more compelling, don't you think? ;)

[89c51]

big props to the developers

[bridgman]

Indeed. It translates into something that could get within spitting distance of the peak performance of the proprietary drivers. It makes the story your employer's got more compelling, don't you think? ;)

Yep; without Gallium3D our comment that we thought open source 3D could fairly easily get to 60-70% of fglrx performance would be pretty lame. The last 30% will be hard though and I don't think anyone will bother; about half of the difference comes from a very sophisticated shader compiler, and the other half comes from constant bottom-to-top tuning and optimizing of the stack, from the GL API down to the bottom of the memory manager and command submission code.

That said, if you can run a modern GPU at 60-70% of fglrx performance you're probably gonna be CPU-limited on anything but a CAD workstation app anyways ;)

[[Knuckles]]

Congrats to all involved!

[aaaantoine]

Yep; without Gallium3D our comment that we thought open source 3D could fairly easily get to 60-70% of fglrx performance would be pretty lame. The last 30% will be hard though and I don't think anyone will bother; about half of the difference comes from a very sophisticated shader compiler, and the other half comes from constant bottom-to-top tuning and optimizing of the stack, from the GL API down to the bottom of the memory manager and command submission code.

That said, if you can run a modern GPU at 60-70% of fglrx performance you're probably gonna be CPU-limited on anything but a CAD workstation app anyways ;)

That last 30% makes a difference when you're using an integrated card that barely performs (specifically, my Xpress 1100). :)

[ethana2]

How mature is the Cell driver? Are we talking Compiz on the PS3 by Klutzy?

[Regenwald]

benches!!111!!1! :)
however, i wonder why tuning the different pipes, mesa and (intel is going to do this) shouldn't help to improve radeon's gallium3d-performance.

[bridgman]

The "pipe" driver is the primary hardware-dependent code, so tuning a cell or intel pipe driver wouldn't affect radeon. On the other hand, under Gallium3D the amount of hardware-dependent code is smaller, and really is a good match with the stuff that is different from one GPU to the next.

The "winsys" driver used to be a mix of hardware-dependent (command submission) and hardware independent (window interface) functions, but AFAIK that has now been broken up to isolate the hw-dependent code in a separate module from the rest.

[Regenwald]

The "pipe" driver is the primary hardware-dependent code, so tuning a cell or intel pipe driver wouldn't affect radeon. On the other hand, under Gallium3D the amount of hardware-dependent code is smaller, and really is a good match with the stuff that is different from one GPU to the next.

The "winsys" driver used to be a mix of hardware-dependent (command submission) and hardware independent (window interface) functions, but AFAIK that has now been broken up to isolate the hw-dependent code in a separate module from the rest.

well, if someone tunes let's say the opengl-implementation in mesa or the state tracker (don't know whether i'm right, mean opnecl-, openvg-, 2d-modul in gallium3d on top of the pipe driver), than you'll gain, too. so you could "move" all your tuning action from the fglrx-codebase to gallium/trackers ;)

[bridgman]

Yes and no. That would work if we had a large Linux-specific performance team, or if we used Gallium3D and Mesa for our Windows and MacOS drivers, but we don't do either of those today.

What we do instead is share big chunks of code across multiple OSes, so that tuning work done for one OS benefits users of the other OSes as well. If we had a completely separate code base for Linux drivers then the arguments about "dumping fglrx and concentrating on open source drivers" would make a lot more sense.

[Regenwald]

hm and fglrx's move to gallium3d? are there already plans? do you already have a strategy how/when to do this? it's going to be difficult to share code, isn't it? perhaps than, the time for a full os-driver will come..

however, some day we have to thank intel that the via/nouveau/ati-driver is that fast...

[RealNC]

People wanting performance are more interested in a fglrx with less bugs. If I say "fglrx doesn't support this and that" they say "use the open source drivers". But then I say "they suck ass; they're slow" and we're back to square 1. If all they can do is utilizing only 70% of my 300$ card, then no thanks.

[bridgman]

We moved our 3D stacks onto something similar Gallium3D a few years ago; the big 3D performance jump in September '07 came from the new OpenGL stack hitting the fglrx driver. I don't think there would be any real benefit to changing again.

[bridgman]

People wanting performance are more interested in a fglrx with less bugs. If I say "fglrx doesn't support this and that" they say "use the open source drivers". But then I say "they suck ass; they're slow" and we're back to square 1. If all they can do is utilizing only 70% of my 300$ card, then no thanks.

I guess the question is whether you can see the difference between 175 and 225 frames per second on your 60 Hz display :D

[Kjella]

I guess the question is whether you can see the difference between 175 and 225 frames per second on your 60 Hz display :D

You know there'll always be games that'll bring any graphics cards to it's knees, try setting GTA IV to maximum if you don't know what I'm saying. Or they could have bought a cheaper card than they did. Still, so you got one or two FPS games that DO need the full 100%, it's not more than a reboot away. Not playing, playing older games, whatever that would do just fine. Chances are that on most brand new games you'll be booting into Windows a while anyway while WINE tries to figure out some new fixes anyway. To me it seems like focusing on this point is blowing it completely out of proportion.

[RealNC]

I guess the question is whether you can see the difference between 175 and 225 frames per second on your 60 Hz display :D

I can't.

But I CAN tell one between 20 and 30. And trust me, it's a BIG one :)

[BlackStar]

I doubt there is anything that could bring your $300 4870 to 20-30 fps on Linux.

In fact, my 4850 has managed to breeze through everything I could throw at it on Linux *or* Windows (well, except for GTAIV, but that game didn't stay installed for more than 15 minutes.) I've forced VSync, because nothing comes even close to 85Hz - everything is running silk-smooth here.

[Kamikaze321]

@bridgman

i registered here, cos I just want to ask you something. You always say that OS drivers can get around 60-70% of fglrx performance. But what makes you think it? I mean, you guys spend 10 years and your driver is not working on many machines. On the other hand, 1 man spend one year and it just works, even 2D is already faster. What makes you think, that your 3D code is better, its obviously that you cant even write a decent installer, so why should your 3d be better? If I am right you are an AMD employee, so do you know how many people working on linux driver? And do you think they are worth their money?

BTW, last time I spend 3 hours to install fglrx on my notebook, and no I am not a Linux noob and I had to use all tutorials available. At the end I dint know any more how and why they started working. After i installed ubuntu 8.10 I didn't even try to install them again, cos I knew I would swear like mad. How much could i earn in this time? Dont you think that AMD owe me thomething?

Ah, and my brother has the same notebook as i do, I compared fglrx and radeon with open arena, radeon has already around 60% of fglrx performance.

[bridgman]

No argument there, but IIRC the lowest frame rate in Michael's recent benchmarks of the sub-$100 4670 was about 70 FPS, and most of the numbers were up over 200 - at 2560x1600 resolution with all eye candy turned on.

If you care about that last 30%, that's why we're still making fglrx and continuing to improve it. If you want the open source drivers to run faster then download the docs, download the code, roll up your sleeves and get to work :D

[remm]

Speaking of which, I just bought a passive HD 4650 card for my new workstation. Looked decent on paper (I thought it was old enough ...), but for some reason the xorg-ati driver has terrible 2D performance with it (ma HD 4850 worked well enough ...), and frglx just blew on me (compiz + xv = panic).

How about paying a couple [outside] people to work full time on the xorg-ati driver, rather than blow your money on the Linux closed source driver that is obviously never going to work properly ?

[bridgman]

You always say that OS drivers can get around 60-70% of fglrx performance. But what makes you think it?

Fair question. That was the aggregate estimate at the start of the project, from a few 3D architects who were familiar with both the open source and closed source code. After a year of looking at the code, talking to users, and talking to developers I still think the estimate is about right.

The actual performance will vary wildly depending on the application, of course, with simple apps more likely to run fast on the open driver and complex apps more likely to run fast on fglrx, but I think it's the right ballpark.

I mean, you guys spend 10 years and your driver is not working on many machines. On the other hand, 1 man spend one year and it just works, even 2D is already faster. What makes you think, that your 3D code is better, its obviously that you cant even write a decent installer, so why should your 3d be better?

The key point here is that we are talking about 3D performance, not install, X or kernel drivers. The 3D stack is the biggest single piece of code in the driver and is used largely unchanged across all OSes, so the investment in that code is effectively funded by 100% of the market. The X driver amd installer are specific to Linux and so are essentially funded only by our expectation of Linux sales.

Also, the operation of the 3D stack is largely independent of kernel and Xorg variations, while the X driver is greatly affected by them. Distro-to-distro variations affect things like suspend/resume and X startup/shutdown, and the installer is the "front line" of dealing with distro-to-distro variations.

Finally, the fglrx driver is using XAA while the open drivers are using EXA, which (as of recently) makes a big difference in performance.

If I am right you are an AMD employee, so do you know how many people working on linux driver? And do you think they are worth their money?

Yes, I have been with ATI and then AMD for about ten years. I know the people working on the Linux driver and yes, I think they are doing a good job. We do need to do a better job of communicating between development and users, and that is something I am trying to address.

Remember that client (ie non-server) Linux has something under 1% market share by all the available numbers; we are putting a lot more than 1% of our development effort into Linux but that is still less than what we invest into OSes with 10-50x the market share. I know that's not what you want to hear but it is the reality of the situation and is no different at any other HW vendor.

There are easy things the Linux community could do to improve the situation; the most significant one would be coordinating distro releases so that they all lurch forward on more-or-less the same schedule, so Linux driver developers only have to deal with maybe 5x the release frequency of Windows rather than the 50x we try to deal with today.

Absent that kind of change, all the hardware vendors can do is gradually accumulate the tricks and tweaks which allow a single driver to work well on a wide variety of distros. We're at a bit of a disadvantage there right now because we only started ramping up consumer support in the last year, while NVidia has been doing it for longer and has accumulated more tweaks along the way. The good news is that you do reach an equilibrium point where everything tends to keep working, and I think we are getting close.

BTW, last time I spend 3 hours to install fglrx on my notebook, and no I am not a Linux noob and I had to use all tutorials available. At the end I dint know any more how and why they started working. After i installed ubuntu 8.10 I didn't even try to install them again, cos I knew I would swear like mad.

Actually you probably would have had a much easier time with Intrepid, unless your previous installs were on RH or SuSE enterprise distros. Ubuntu support is a fairly recent addition; before that our test and bug fixing were focused on what the bulk of our customers, which was primarily RHEL and SLES/SLED.

How much could i earn in this time? Dont you think that AMD owe me thomething?

If you were using a supported OS then I think we should at least feel guilty and make sure we work hard to improve things.

Ah, and my brother has the same notebook as i do, I compared fglrx and radeon with open arena, radeon has already around 60% of fglrx performance.

On simpler chips and apps I expect that the open drivers may be able to outperform fglrx, not just match it. The 60-70% estimate was a best guess average making some assumptions about mix of GPUs and applications.

[RealNC]

No argument there, but IIRC the lowest frame rate in Michael's recent benchmarks of the sub-$100 4670 was about 70 FPS

I don't think he's testing Oblivion and Crysis and stuff ;)

[Kano]

@bidgeman

Did any ATI employee ever test a Nvidia card on Linux to see how it should work?

[bridgman]

I don't think he's testing Oblivion and Crysis and stuff ;)

Ooh, did someone port Crysis to Linux ?

[RealNC]

No. It still runs though. But I guess it's NVidia-only or something for now.

[bridgman]

Interesting. I saw a couple of posts indicating it was successfully installing under Wine and sort of limping along slowly but didn't think anyone had it "running beneficially" yet on any hardware.

[RealNC]

Stop attacking the post's examples. Concentrate on the point :D That is, substitute "Crysis" with any other demanding 3D app or game. I just mentioned Crysis without looking how well it runs.

[Kamikaze321]

Also, the operation of the 3D stack is largely independent of kernel and Xorg variations, while the X driver is greatly affected by them. Distro-to-distro variations affect things like suspend/resume and X startup/shutdown, and the installer is the "front line" of dealing with distro-to-distro variations.

Why not use precompiled packages for every distro? Thats how its done: http://www.virtualbox.org/wiki/Linux_Downloads


Finally, the fglrx driver is using XAA while the open drivers are using EXA, which (as of recently) makes a big difference in performance.

So why dont you implement EXA if its "just 2D"? I think nobody needs 0,2% more 3d performance.



Actually you probably would have had a much easier time with Intrepid, unless your previous installs were on RH or SuSE enterprise distros. Ubuntu support is a fairly recent addition; before that our test and bug fixing were focused on what the bulk of our customers, which was primarily RHEL and SLES/SLED.


Actually, I had hardy with fglrx. Then I updated to intrepid, and i had no gui anymore. You guys were to late on drivers. There was one pre-release for intrepid, but they didnt work, so i had no gui till i reconfigured xorg, but then i had only OS.
Other problems forced me to go back to hardy. But then it took me 3 hours to install fglrx, thats how i discovered OS drivers. But i realized that i need intrepid, so i got intrepid, but this time i didnt even try to instal them, since it didnt work the first time.



If you were using a supported OS then I think we should at least feel guilty and make sure we work hard to improve things.

Do we talk about DOS 1.0 here? :) Why deliver drivers at all then? People should be forced to buy and use MS software? I hope for AMD that MS wont force people to buy Intel and nvidia hardware....



On simpler chips and apps I expect that the open drivers may be able to outperform fglrx, not just match it. The 60-70% estimate was a best guess average making some assumptions about mix of GPUs and applications.

I got x1400 mobile

[bridgman]

Believe it or not, I do understand your point.

I have one too -- that none of the really demanding Windows games are usefully running on Linux today, and that by the time they do you probably will like fglrx a lot better.

[Wyatt]

bridgman, you mention a good GLSL compiler being one major component missing. What are your thoughts on LLVM and its potential to shore up this weakness. Could it be done? At speed?

[bridgman]

I think LLVM will be a great compiler in terms of being versatile and predictable. My only concern is not a criticism of LLVM per se, just an observation that most of the optimizing happens before instructions are emitted, which is fine for a normal CPU but not so fine for a superscalar machine.

In the case of 6xx/7xx we use a 5-way superscalar instruction word (up to 5 independent operations per VLIW instruction) and I don't think LLVM's built in optimizations will be able to opimize for that. This is not a showstopper; it just means that either the code generator for 6xx/7xx will need to have some hard-coded optimization, or that someone will need to figure out how to make VLIW issues visible to the standard LLVM optimizers.

In the meantime, we'll probably average something like 60% utilization of the superscalar hardware. The proprietary driver uses a very clever shader compiler which is able to achieve much higher utilization numbers.

Big picture, my guess is that for a while all the drivers will use LLVM for software rendering (eg running vertex shaders on our pre-7xx IGP parts which don't have vertex shader hardware) and hard-code shader opcode emission for vertex and pixel shaders on GPU rather than using LLVM. Not sure about this, but it's my impression.

[BlackStar]

I don't think he's testing Oblivion and Crysis and stuff ;)

It makes sense, too. The bottleneck with these is not your GPU, but the Wine D3D emulation layer. Quoting from WineHQ:Crysis (http://appdb.winehq.org/objectManager.php?sClass=version&iId=10107&iTestingId=19875):

What does not
The sound. Had to desable it to get passed the EA logo.
The FPS. I get something like ~1FPS when I run this game perfectly on windows..


Edit: Late reply, by about a whole page of posts... :)