Looks like Linux smashes Windows in terms of Radeon OpenGL performance

[kamild1996]

Now, I have no idea how obvious I am by stating that, but since I have Ubuntu running on my PC, I decided to try it out anyway ^^

So, I used the GPU benchmark to test out PCSX2 OpenGL performance on my PC (Intel Core i5-3350P @ 3.5 GHz, 8GB DDR3, Radeon RX480 4GB) on two operating systems:
- Windows 10 x64 1703, Crimson 17.8.1
- Xubuntu 17.04, latest Mesa-git driver as of today (from padoka PPA), kernel 4.13rc4

Using the latest PCSX2 builds from 16th Aug (3:1.5.0~git201708161205~ubuntu17.04.1 on Linux, v1.5.0-dev-2175-g420f11161 on Windows). Haven't changed any settings besides the ones recommended for the GPU benchmark.

The results are straight-forward (the framerate fluctuated a lot, so I took a screenshot of the highest noted value, and then wrote down the lowest one):

WINDOWS 10:
- DX11 (for comparison): 420-450 FPS
- OpenGL: 202-212 FPS

UBUNTU 17.04:
- OpenGL: 400-430 FPS

And screenshots to back it up: http://imgur.com/a/iKiDB

I didn't test any really demanding games yet, I have only scavenged a Half-Life PS2 disc, which I was able to play on a bit. What I noticed is in this area, Windows on OpenGL and 2x native resolution would drop the framerate by almost 50% (I'll try to provide a screenshot of that as soon as I jump back to Windows). As you can see, Linux on OpenGL manages this area just fine, even on 3x native resolution.

Looks like Radeon's OpenGL driver on Windows really is that terrible...

PS: Fun fact - looks like XFCE's compositor doesn't impact PCSX2 performance, at least not in a noticeable manner. Thanks, PCSX2 devs!

[gregory]

Nice I'm pretty sure it is partially related to gl threading.

I have some mesa patches to reduce CPU overhead further (better threading for texture transfer). Unfortunately I didn't manage to have a green light for commit yet.

[Croc the Legend]

Nice I'm pretty sure it is partially related to gl threading.

I have some mesa patches to reduce CPU overhead further (better threading for texture transfer). Unfortunately I didn't manage to have a green light for commit yet.

I heard that on Vulkan it will get rid of driver overhead and that puts the work to the developers instead of the gpu drivers for optimization. Would porting gsdx to vulkan increase performance on AMD cards?

[gregory]

Vulkan moves the overhead from the driver to the application. So yes it should be faster in some cases. But you will miss all AMD optimizations. Looking at the above result, maybe the solution isn't to port thousand of application to vulkan but instead to provide a decent GL driver.

As I said in another thread, modern GPU will allow several optimization that should reduce the number of draw calls. But instead will increase the load on the GPU.

[kamild1996]

Doesn't Vulkan support (RADV) still have a lot to ask for on Linux? I tend to visit Phoronix's site, looking at benchmarks, and seems like Vulkan will sometimes just stop working...

[zwastik]

Just for reference:
http://www.phoronix.com/scan.php?page=ar...inux&num=9
You can see there is no significant difference in windows OGL and linux OGL in the game Talos Principle. This tests are done however with an nvidia card so you cannot really compare. I found nevertheless, huge contrasts between nvidia OGL in linux and windows, which I detailed in another post.

[kamild1996]

Just for reference:
http://www.phoronix.com/scan.php?page=ar...inux&num=9
You can see there is no significant difference in windows OGL and linux OGL in the game Talos Principle. This tests are done however with an nvidia card so you cannot really compare. I found nevertheless, huge contrasts between nvidia OGL in linux and windows, which I detailed in another post.

NVidia's OpenGL driver on Windows is fine, but it's the AMD's driver that's known for underperforming severely under Windows. That's why you don't see much difference on GTX 1060, but almost double the framerate on RX 480.

Fun fact: Team Fortress 2 is now slightly faster on Linux than on Windows. On Radeons, of course