AMD Radeon HD 6000 Series Open-Source Driver Becomes More Competitive

[krasnoglaz]

See: http://www.phoronix.com/scan.php?pag...tem&px=MTQxMzY

So, no benchmarks, but highly automated ones? Come on!

[benmoran]

I've abandoned fglrx soon after I discoverd open sauce can run my three monitor setup on HD6850 just fine and decided to take 3D performance loss for great 2D performance and absence of headaches over compatibility with various kernels, xorg etc etc.

It seems that these days even perf 3D is coming close, so in near future it will be a no-brainer solution...

Yeah, me too. For my a10-5800k, I was suprised to find that 90% of my games actually ran much better with the open source drivers. I've been able to get smooth playable framerates in just about everything. Fglrx may have technically had higher frame rates in some games, but the stuttering, high frame rate fluxuation, and horrible lag made it feel so much worse. That, plus never having to see shitty screen tearing and vsync issues anymore, I'll never use fglrx again.

[brent]

I assume most of the missing 50% performance in radeon is not due to "some secret magic performance unlocking code" that catalyst has,
but the accumulated effect of dozens of small optimizations that would make radeons code unclean if they were applied. Is that a fair assumption?

That should be about right, but I don't think it is correct to say that these optimizations would necessarily make the code "unclean". They would increase complexity of the code, of course, but most of these optimizations can probably implemented in sane and clean ways.

[bridgman]

That should be about right, but I don't think it is correct to say that these optimizations would necessarily make the code "unclean". They would increase complexity of the code, of course, but most of these optimizations can probably implemented in sane and clean ways.

Yeah, we should probably separate out the parts of that answer. Alex was mostly answering the question of whether future performance improvements will come from "one or two big things" or a lot of small improvements. It's probably fair to say that there are 3 classes of changes :

- general improvements (we want these)

- changes which improve behavior in certain scenarios and have no effect in others (some these are probably fine)

- changes which improve behavior in certain scenarios and make things much worse in others (these are the ones which make the code grow rapidly and become hard to manage, because you need very complex switching logic to figure out which changes to enable at any given time).

So there are still lots of opportunities for improvement, and many of those potential changes could fit in while keeping the driver clean. The code probably is approaching the point where (a) individual improvements will be smaller so cumulative effect is what counts, and (b) more of the changes are likely to have negative impact on other apps, although obviously the goal would be to make 20fps games go faster while only slowing down the games that are already running at 200fps.

[89c51]

- changes which improve behavior in certain scenarios and make things much worse in others (these are the ones which make the code grow rapidly and become hard to manage, because you need very complex switching logic to figure out which changes to enable at any given time).

implement AI and genetic algorithms in the driver so it can optimize itself

[schmidtbag]

Yeah, we should probably separate out the parts of that answer. Alex was mostly answering the question of whether future performance improvements will come from "one or two big things" or a lot of small improvements. It's probably fair to say that there are 3 classes of changes :

- general improvements (we want these)

- changes which improve behavior in certain scenarios and have no effect in others (some these are probably fine)

- changes which improve behavior in certain scenarios and make things much worse in others (these are the ones which make the code grow rapidly and become hard to manage, because you need very complex switching logic to figure out which changes to enable at any given time).

So there are still lots of opportunities for improvement, and many of those potential changes could fit in while keeping the driver clean. The code probably is approaching the point where (a) individual improvements will be smaller so cumulative effect is what counts, and (b) more of the changes are likely to have negative impact on other apps, although obviously the goal would be to make 20fps games go faster while only slowing down the games that are already running at 200fps.

If we were to dismiss the 3rd class of changes, how close (theoretically) do you think the performance of the open source driver could get to the Windows Catalyst driver on something such as a HD6970?

Anyways thanks for answering these questions - it's a nice feeling having important developers actually give a crap about talking to their customers directly.

[bridgman]

If we were to dismiss the 3rd class of changes, how close (theoretically) do you think the performance of the open source driver could get to the Windows Catalyst driver on something such as a HD6970?

Hard to say... 80-90% I guess. Our ~60% estimate assumed that we would not have a sophisticated shader compiler (among other things), and Vadim's SB work has already blown past that. It didn't assume use of multiple threads either -- IIRC Marek added that.

Anyways thanks for answering these questions - it's a nice feeling having important developers actually give a crap about talking to their customers directly.

I wasn't actually an important developer on the graphics side, but thanks

[vadimg]

If we were to dismiss the 3rd class of changes, how close (theoretically) do you think the performance of the open source driver could get to the Windows Catalyst driver on something such as a HD6970?

Anyways thanks for answering these questions - it's a nice feeling having important developers actually give a crap about talking to their customers directly.

Really, performance of the open source driver can be even higher just because catalyst is not ideal either. I can mostly talk about compiler (it's what I dealt with), and I saw many cases where proprietary compiler generated the shader code that was far from ideal. I was slightly surprised to find out that r600g performance with Unigine Heaven 3.0 was basically equal to Windows, I didn't expect that, but in fact it seems catalyst's compiler may lose in efficiency as compared to SB or llvm backend, anyway it's far from ideal.

So far I believe most of performance problems are caused by pretty big CPU overhead in mesa/state tracker, not really related to the driver. It's a kind of problems that are hard to fix, but fixing it can be a most significant win for most old apps like Doom3 etc.

By the way, one more thing that I think will allow to improve performance is formats optimization, for me with catalyst it basically doubled the performance with doom3. It's what called "Catalyst A.I." in proprietary driver settings. Maybe there are other things involved, but I believe that just using most optimal hw formats instead of chosen by mesa can provide significant improvements.

[duby229]

I understand what you are saying that mesa cpu overhead is a really hard problem to solve, but I think it's great news to hear you say that.

[sonnet]

I'd be very interested to know if o.s drivers behave well with game under wine.
Historically Catalyst had problems with games played with wine.
So I was wondering if os drivers had less glitches and if they get even closer to Catalyst performances in wine.