AMD Linux Graphics: The Latest Open-Source RadeonSI Driver Moves On To Smacking Catalyst

[marek]

No csgo benchmarks. :/

Like the R7 370 my HD 7970M struggles to get ~60 fps in csgo. The unigine valley results looked so good here, I tried it too (on the "Extreme HD" preset) with latest mesa git.

FPS: [B]20.3[/B]
Score: [B]848[/B]
Min FPS: [B]12.1[/B]
Max FPS: [B]37.9[/B]

Wow. Is the R7 370 3x faster than the HD 7970M? Sure, old laptop vs new discrete, but it's still both pitcairn...

If you enable "cpu,GPU-load,num-bytes-moved,buffer-wait-time,num-compilations" in the gallium HUD for CS:GO:
- Is the CPU load lower than 100 divided by # of CPU cores? Is the GPU load lower than 90%? Which one is higher? (with respect to # of CPU cores)
- Do any of the last three graphs show any activity when the performance is bad?

[dungeon]

Thanks for the info. I encountered the crash in 2 locations, one is the Argus boss. I have an apitrace trace. It shows a problem with the R600 driver. But I don't know what to do from there. It's been years since I've done any coding and have to learn a lot of things :-)

Anyway easiest for me will be to simply buy a radeonsi supported card ... but ... I'd like to improve the driver :-) I'll have a look at the bug report.

Yeah fill a bug report with trace, just killed nearly everything on that map and no crash happens on radeonsi (Chessmaster and that yellow Argus up there, etc...)

Yeah, I don't think we were expecting "faster" at this point (at least not to this extent), but it's great to see fresh benchmarks with latest code.

I agree on both

[smitty3268]

Somebody played Victor Vran on R600g ? It crashes on me on a certain boss monster, looks like a buffer overflow issue. It works on Catalyst. They do ask for GL 4.1 in the requirements for Linux, but so far all the shaders say #version 150 and I have not found any call to an extension that is higher than GL 3.2. Can somebody test on radeonsi please ? :-)

There's an environment variable you set to turn off optimizations which often helps: R600_DEBUG=nosb

You might also try the newest git if you're on an older version. Dave and Glenn have been fixing crashes in the r600g driver over the last week or two.

[haplo602]

There's an environment variable you set to turn off optimizations which often helps: R600_DEBUG=nosb

You might also try the newest git if you're on an older version. Dave and Glenn have been fixing crashes in the r600g driver over the last week or two.

I already tried latest GIT, was even worse. Before it crashed cleanly, with latest GIT it took down the whole system (ok I enabled debug symbols to get more info but anyway). nosb/nollvm are the next tests in the round. But I tried GL version override, the render path changes to a 4.0 one (verified in the trace) but the crash happened anyway in the same place. AFAIK 4.0 will not work with SB ? So there seems to be something else wrong.

[dungeon]

I already tried latest GIT, was even worse. Before it crashed cleanly, with latest GIT it took down the whole system (ok I enabled debug symbols to get more info but anyway). nosb/nollvm are the next tests in the round. But I tried GL version override, the render path changes to a 4.0 one (verified in the trace) but the crash happened anyway in the same place. AFAIK 4.0 will not work with SB ? So there seems to be something else wrong.

Then there might be also some r600 regression somewhere, in that case bisecting can help. I even tried to go down to 10.2.8 mesa and game still works there and still does not crash on Argus... well on a radeonsi.

Well make sure that you have s3tc and if you use high textures then at least 1GB VRAM but also 1GB GTT.

[pal666]

but not willing to spend $60 just to find out it will turn out like crap too.

after buying game from steam you have two weeks or something and two hours of gameplay to test it and get refund if it does not work for you. so never fear

[dungeon]

No csgo benchmarks. :/

Like the R7 370 my HD 7970M struggles to get ~60 fps in csgo. The unigine valley results looked so good here, I tried it too (on the "Extreme HD" preset) with latest mesa git.

FPS: [B]20.3[/B]
Score: [B]848[/B]
Min FPS: [B]12.1[/B]
Max FPS: [B]37.9[/B]

Wow. Is the R7 370 3x faster than the HD 7970M? Sure, old laptop vs new discrete, but it's still both pitcairn...

OpenGL implementations often has big CPU overhead it is CPU capped in the main thread - watch your CPU *always*!!! So when you want to compare some benchmark results keep in mind singlethread IPC of CPUs used you compare. Your i7-3632qm is 25% slower then i5-6600K on that, which means there is more CPU power to feed up GPU. In some cases when CPU power is not enough also bigger the GPU means bigger CPU overhead so user with bigger GPU can see slower perf. So yes, your CPU IPC is somewhat like Kaveri APU has and perf should be comparible to that

CS:GO and Borderlands 2 native OpenGL games are very good examples of driver overhead, both of those for performance more or less depends on threaded GL driver implementation which mesa drivers does not have.

So either will someone implement threaded GL to fix this (most hickups you see in those games and performance issues should go away with this) partially in mesa or you can use Nine or different drivers or wait for complete solution called Vulkan

[haagch]

If you enable "cpu,GPU-load,num-bytes-moved,buffer-wait-time,num-compilations" in the gallium HUD for CS:GO:
- Is the CPU load lower than 100 divided by # of CPU cores? Is the GPU load lower than 90%? Which one is higher? (with respect to # of CPU cores)
- Do any of the last three graphs show any activity when the performance is bad?

Here is a video with the current state: https://www.youtube.com/watch?v=9dERLwSVJS4. Ignore the weird pauses and jumps, that's just the recording.

Htop shows that csgo uses about 136-175% cpu with either no core being at 100% or the threads are shuffled to different cores faster than the htop sample period.
num bytes moved and num compilations are mostly zero, so there's something that works well.
buffer wait time is the only one that is relatively high...

I have even experimented with making the buffer a lot smaller

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.h b/src/gallium/winsys/radeon/drm/radeon_drm_cs.h
index 6ceb8e9..6675d41 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.h
@@ -30,7 +30,7 @@
 #include "radeon_drm_bo.h"

 struct radeon_cs_context {
-    uint32_t                    buf[16 * 1024];
+    uint32_t                    buf[1024];

     int                         fd;
     struct drm_radeon_cs        cs;

just to see what would happen - not much did happen. Performance was about the same. Maybe the buffer wait time was a bit lower and it was a bit smoother, but if it was, it was in the range where I could have easily imagined it, so not really noticeable.

[dungeon]

Htop shows that csgo uses about 136-175% cpu with either no core being at 100% or the threads are shuffled to different cores faster than the htop sample period.

That is not the way to differ singlethread vs multhreaded rendering... It does not mean that one or any core must go to 100% and render to be capped.

To check that the best is if you don't to move at all, just stand still look at the ground or very near into some wall, etc... in good threaded render *all* cores should be nearly the same with rare and not much spikes, while in singlethread render or not good threaded render all threads can be used of course but there are often high or low spikes of some of the cores.

[profoundWHALE]

That is not the way to differ singlethread vs multhreaded rendering... It does not mean that one or any core must go to 100% and render to be capped.

To check that the best is if you don't to move at all, just stand still look at the ground or very near into some wall, etc... in good threaded render *all* cores should be nearly the same with rare and not much spikes, while in singlethread render or not good threaded render all threads can be used of course but there are often high or low spikes of some of the cores.

I remember those poorly coded (or very heavy on physics) rooms that I would have to look up at the ceiling in order to get through it. Like when you forgot that you dropped 2000 bottles of potions in some place in skyrim.