Radeon Linux OpenGL Driver Continues Giving Its Best Against Windows 10

[humbug]

Damn, our drivers may be good now but clearly the porting methodology just leaves a lot to be desired. People on Linux have to spend more money on more expensive hardware if they want to achieve what can be done on windows for so much less.,

Would be interesting to see an in depth technical discussion with Feral and Aspyr and get their take on the problem and future plans to alleviate it.

[RussianNeuroMancer]

People on Linux have to spend more money on more expensive hardware if they want to achieve what can be done on windows for so much less.

Just like with console->Windows ports. At this point I doubt that anything could be done about it, besides developing game as cross-platform from the beginning.

[Rallos Zek]

Part of me wonders if perhaps this is an Xorg issue, since Xorg wasn't really designed (and therefore optimized) to handle such high resolutions. After all, Xorg is relatively CPU intensive compared to Wayland, and perhaps the CPU usage increases as you add more pixels. Heavier CPU utilization is likely to decrease framerates. Just a guess though - I'm not familiar enough with how all that works at the lower level.

Bullshit! Show the benchmarks showing cpu utilization and usage, Show me Wayland running on an 486 or 68040 with 8mb to 16mb of ram like X11 can and then you might have a point.

[dungeon]

I've been wondering this too. From what I recall, it isn't just AMD's drivers that seem to lose more performance than Windows as the resolution increases. Part of me wonders if perhaps this is an Xorg issue, since Xorg wasn't really designed (and therefore optimized) to handle such high resolutions. After all, Xorg is relatively CPU intensive compared to Wayland, and perhaps the CPU usage increases as you add more pixels. Heavier CPU utilization is likely to decrease framerates. Just a guess though - I'm not familiar enough with how all that works at the lower level.

He, he, it isn't Xorg, but KMS I remember times with UMS from 10 years ago where we scaled normally, but as soon as that was introduced scaling does not worked the same way anymore... instead of having normal scaling, we get flat line scaling instead whose with bigger res even became worse and with less even less - all flat and nope normal scaling anymore

Maybe it is just some sort of FBO boundware somewhere, but for sure it is related to KMS

People usually think it is Xorg, some think it is shader compiler or whatever... but nope, that scaling was borked with UMS>KMS switch

Wayland for sure won't help anything there, it would just further introduce that we can't feel our CPUs normally, with that we would be just further pushed to "enjoy" our GPU boxed laggy land

[schmidtbag]

Bullshit! Show the benchmarks showing cpu utilization and usage, Show me Wayland running on an 486 or 68040 with 8mb to 16mb of ram like X11 can and then you might have a point.

You're trolling, right? I have too hard of a time believing anyone is that dense.
Keep in mind, I'm not saying the problem is Xorg, it's just that I noticed Xorg's CPU usage is significant, and it seems reasonable to guess that the usage goes up along with the resolution (but again, not saying it does do that).

People usually think it is Xorg, some think it is shader compiler or whatever... but nope, that scaling was borked with UMS>KMS switch

Wayland for sure won't help anything there, it would just further introduce that we can't feel our CPUs normally, with that we would be just further pushed to "enjoy" our GPU boxed laggy land

Do you have data on any of this? I'm not saying you're wrong, I'm legitimately curious. I find it a little weird that a lower-level mode setting would make scaling worse, let alone have this problem go on for a decade with nobody noticing or doing anything about it. Though I don't know much about how Wayland works at the lower level, what I do know is how it's built and intended to work with modern GPUs and modern displays. If KMS really is the problem, I could see why Wayland wouldn't fix the problem, but best case scenario, it might just make the problem less extreme.

[dungeon]

Do you have data on any of this?

What data, i don't have such an old UMS capable hardware anymore... otherwise i would show it to you how scalabilty was borked right there with KMS.

If you have such an old hardware try running something like mesa 7.5 branch with UMS and you will see it, on distro versions maybe like Debian 5 maybe 6, something up to later 2.6 era kernel, something of that time where we were still clean of KMS, when radeon used classic mesa, etc... but it isn't about classic, it is just because of KMS UMS scaled up and down all normal, just like nvidia, but in KMS land that became bound & flat

And then go further enable KMS and you will see what i am talking about or what we have now They break scale right there, decade ago with KMS

I think r200 driver of that time would show it the best, because there are some people who still think this is maybe because of shader compiler... nope, it isn't compiler that hw does not do compiling shaders at all but is same flat scale like anything else just with switch to KMS

Wayland per se won't fix anything at this, that just push for more boundware further Do you know that Wayland was born right at that time somewhere - this year is 10th birthday of these old babies in Da bound BoX

[schmidtbag]

If you have such an old hardware try running something like mesa 7.5 branch with UMS and you will see it, on distro versions maybe like Debian 5 maybe 6, something up to later 2.6 era kernel, something of that time where we were still clean of KMS, when radeon used classic mesa, etc... but it isn't about classic, it is just because of KMS UMS scaled up and down all normal, just like nvidia, but in KMS land that became bound & flat

Well it's this specifically that I'm more curious about. You make interesting points, but I'm not seeing enough evidence that it's specifically KMS that's the issue. There may have been other changes at the same time KMS was implemented that are actually causing this problem. Remember, KMS functions at a lower level than UMS. Logically, that would mean it'd be less of a bottleneck. But, there's a lot about how all this works that I don't understand, which is why I'm not saying you're wrong.

I think r200 driver of that time would show it the best, because there are some people who still think this is maybe because of shader compiler... nope, it isn't compiler that hw does not do compiling shaders at all but is same flat scale like anything else just with switch to KMS

Again, I don't know enough to make any claims, but how do you know so definitively that it isn't the shader compiler? I'm not suggesting it is the problem (it never really occurred to me that it could've been the problem), but what rules out that it isn't the problem?

Wayland per se won't fix anything at this, that just push for more boundware further

If everything you've said is correct, then I'm inclined to agree. But, I still feel it would make the problem less bad. Think of it like adding more RAM to your computer: it's not making your computer faster, but rather just making it less slow.


Anyway I guess the real question is if KMS is in fact the problem, can anything be done about it without going back to UMS? Because I'm pretty confident devs are not going back to UMS.

[leipero]

Okay, how many people here can run observer on r600g with current Mesa and don't get GPU lockup? Anyone?

https://bugs.freedesktop.org/show_bug.cgi?id=105227

By the way, I have exactly same issue on r600g, any ideas why it could be?
Seems like LLVM patch is amdgpu-specific, and LLVM shouldn't be matter for r600g at all, yet exactly same behaviour for some reason.

MESA_GL_VERSION_OVERRIDE=4.x MESA_GLSL_VERSION_OVERRIDE=4x0 Forget about it on r600, it causes crashes for me for quite a bit of applications, including wine games (regardless if wine d3d or gallium nine is used, and that's really strange). There is something seriously wrong on the r600 side for GL 4.x, I have to bisect and see how far in the past that happened, but as I remmember it it was as far as Mesa 13, and maybe even 12, not sure (and those drivers not fully supporting GL 4.x makes things not so easy to bisect).

[dungeon]

Well it's this specifically that I'm more curious about. You make interesting points, but I'm not seeing enough evidence that it's specifically KMS that's the issue.

Well, search about there are old articles on phoronix, hard to find good one on that... but for example this:



https://www.phoronix.com/scan.php?pa..._kms_ums&num=2

It is low fps, low hardware, very old article, ignore that - just look at a line, the same story... suddenly line goes down with KMS how resolution increases Intel used GEM, radeon TTM, but nope same non scalability happened there for both, at that time somewhere i tested that UT on radeon a spot the same, actually a bit worse it was always slower with KMS only on one resoultion similar but on bigger enough same goes to crawl... because of that i don't think it is not even memory manager, just again and only KMS

Nowdays we can push CPU boundware on lower res to improve situation somewhat, so you might don't see it much... but as soon as resolution goes up enough same KMS crawling happen

[FireBurn]

Would love to see some Linux OGL + Vulkan and Windows DX9, DX11, DX12 (where applicable) + Vulkan tests

So we can really see the differences between Windows and Linux gaming