Proprietary vs. Linux Git, Mesa 11.2-devel, DRI3 For R600g/RadeonSI

[BenPope]

I am also looking for the working initial PowerPlay git commit to revert to.

I don't see any problems with the latest powerplay branch (well, from yesterday, which is newer than Michaels build: http://cgit.freedesktop.org/~agd5f/l...db2a75bbcc8419) my test results are here: http://openbenchmarking.org/result/1...HA-BPPADOKAN90, perhaps I'm not running tests that have a problem?

[bulletxt]

So, what's the good news here for oss situation?

[liam]

And Mesa shows always higher overhead even on Gallium Nine.

Which really makes you wonder how gallium manages to beat catalyst on a few tests.

[SystemCrasher]

Which really makes you wonder how gallium manages to beat catalyst on a few tests.

It also quite good in, say, Xonotic (which is known troublesome workload for open drivers), and some synthetic tests are quite ok. Though some synthetic tests are also probably showing us there're some major performance/overhead problems as well. But TBH, Catalyst does not serves as great example of technical excellence either, so beating it could be just a really crappy code in catalyst.

Yet, overall, looking on this benchmarks round, I wonder if AMD got any QA's, dammit. How the hell such a major bugs like failing Bioshock are lurking in both open and closed driver? Catalyst is especially strange in this regard. This bench clearly close to getting high score in terms of failed runs. Uhm, sure, these are AAA games or so, but that's what we have today...

[liam]

It also quite good in, say, Xonotic (which is known troublesome workload for open drivers), and some synthetic tests are quite ok. Though some synthetic tests are also probably showing us there're some major performance/overhead problems as well. But TBH, Catalyst does not serves as great example of technical excellence either, so beating it could be just a really crappy code in catalyst.

Yet, overall, looking on this benchmarks round, I wonder if AMD got any QA's, dammit. How the hell such a major bugs like failing Bioshock are lurking in both open and closed driver? Catalyst is especially strange in this regard. This bench clearly close to getting high score in terms of failed runs. Uhm, sure, these are AAA games or so, but that's what we have today...

Their new initiative with both drivers using the amdgpu (or whatever the drm/libdrm bit is called) may end up helping their driver on other platforms if, as you say, catalyst really is crummy software.
So, if catalyst is crap, one must question how much the drivers are holding back the hardware.
The qa issue is pretty simple: there's not enough of them. As the open drivers a become better at running these more demanding games, I'd hope they start being added to their ci setup.

[SystemCrasher]

Their new initiative with both drivers using the amdgpu (or whatever the drm/libdrm bit is called) may end up helping their driver on other platforms if, as you say, catalyst really is crummy software.

Well, it can help to iron out some stuff in user-mode part. But kernel mode is system specific anyway. And, honestly speaking, I do not care how kernel mode parts of catalyst are working on other systems because I do not use these systems. And I do not really care about user more part of catalyst either. I really had enough of Catalyst. So I care about all-open stack instead. If it somehow helps AMD somewhere else, fine with me. But I do not care about it too much. At most I can imagine some other open systems can use MESA if they are ok with exposing DRM/KMS apis on kernel side of things. But whatever, Linux is setting trends in this regard and I do not get what is the point to wait for same thing few extra years. This up to people who understand why this extra waiting is worth of it.

So, if catalyst is crap, one must question how much the drivers are holding back the hardware.

I've got to suspect it actually quite a lot. This is indirect guess, based on few things.
1) AMD GPUs manage to perform extremely well in some workloads. E.g. in mining, crypto, etc - AMD GPUs pwn nvidia to the hell. It means when it comes to numbers crunching, AMD GPUs lack fundamental problems with raw performance, and its more about being able to use it.
2) Windows version of catalyst is quite competitive overall, plus or minus some cheat-optimizing like totally replacing shaders by driver. Uhm, well, no compiler can match carefully crafted assembly optimizations, but its really unfair competition and it only works reasonably only in SOME cases. It only maters for gamers inclined on few AAA titles. Everywhere else this cheat is not going to work and one just gets much worse results. So things like nvidia+prop driver are actually overrated in some benches quite a lot and would not show anything close to these numbers in MY use cases. Seeing superb numbers in Bioshock could be nice for hardcore gamers, but if I play relatively unpopular Xonotic, it would be entirely different story. Where I face raw code generation performance and that's where nvidia is hardly epic. Maybe they are somewhat better, but not anyhow groundbreaking overall. And actually open stack can afford like 80% of Catalyst in such workloads. There still seem to be some fundamental probs since some synthetic tests like gpuench show us there're some fundamental problems. But these are clearly software overhead/poor optimization of some operations.
3) AMD hardware arch looks reasonably on its own. It lacks any reasons to be slow and AMD does great at innovating, e.g. like they did with HBM. And 1) confirms this idea. At very most it could be some challenge to squeeze most out of it and it is a matter of existence of those trying to get most of it. GCN has mostly fixed inherent problems of VLIWs which are much worse at it when it comes to GPGPU. That was nearly last obviously weak point. Whatever, AMD and NV designs are more or less similar in idea, intel is lagging behind, trying to get something similar as well, and of the rest I can only remember PowerVR having anyhow comparable arch. Virtually the only mobile GPUs which can afford Vulkan support. Everyone else seems to be like 10 years in the past and just no match to these.

The qa issue is pretty simple: there's not enough of them.

You can't have enough qa in first place: you can't test all combos and so everyone is doomed to face user-reported bugs if their HW/SW is anyhow complicated, we have to live with it. But there are ways to maximize coverage while usnig only limited, realistic amounts of resources. And I guess there is plenty room to improve. I really do not get how the hell they manage to release Catalyst with installer failing to build ubuntu packages each time I give it a try. No, you do not have to test all ubuntu versions. Just automate it and run on couple of current versions, it takes little qa resources if you do it right, yet it would report bugs potentially hitting millions of users. Seems AMD isn't good at it.

Then, bugs happen. And there is really room to improve. Somehow, I was never able to get my bugs fixed in Catalyst. Not even single bug. OTOH, in opensource driver, all bugs annoying me were eventually nailed down. I think it proves there is room to improve. And best improvement is actuallly has been proposed by Qualcomm-Atheros devs: just kill proprietary drivers with a fire.

As the open drivers a become better at running these more demanding games, I'd hope they start being added to their ci setup.

TBH, looking on Catalyst, I fail to notice any positive effects of their CI. It always released with bad performance and annoying bugs and then good luck to get this crap fixed. In case of open drivers, there're more or less efficient communication channels. But it does not works for proprietary drivers. AMD isn't unique about it. Recently nv drivers just failed to work on recent kernels. For THREE kernel releases in the row. Because kernel devs chopped of some code nvidia used. Nobody else used it and that's we're getting idea why proprietary development just not going to be Linux friend. Proprietary devs just can't into communication & proper integration.