OpenGL renderer is slow on AMD GPU due to inefficient driver. Sorry.

[gregory]

Lol. Oh boys, breaking news a Fury X can beat a GTX960 in GPU limited benchmark

The current subject is the performance/overhead of the driver. So I took a benchmark that test the performance of the driver.

What is isolated is not the number of times a GTX960 beat a top Fury (with HBM) but the number of benchmark that does test the driver overhead.

I agree with you most games are GPU limited, so nobody cares that AMD driver is slow. And it also proves that DX12/Vulkan won't be the revolution but only an improvement.

I said AMD drivers aren't as bad as people say, I never said they were flawless. I have had issues with them as well, but I've also had tons of issues with Nvidia drivers when I was still using their GPU's. People are still having serious driver issues with Nvidia to this day, but because their DX11 performance is better than AMD's, suddenly that absolves them of that fact and the drivers are "good" no matter what?

GSdx-ogl was half developed on AMD driver. And half on the Nvidia drivers. I report driver bug in both side. But I got more bugs on the AMD side and even crashes. Honestly I spend most of the time, finding workaroud to the AMD driver. AMD made a lots of progress but it is still far from Nvidia which is itself far from perfect.

The goals of the driver is to send the rendering command (following the API) from the application to the GPU as fast as possible. Of course if performance isn't important to you, AMD driver is somewhat usable.

[NarooN]

First post in this thread over at OCN dispels a lot of the nonsense spread around the net (and some of it in this thread.)

Here's a quote:

After this quick explanation of the API and some of it's core functions, let's look at AMD's side of the story. Again, to put things simply, deferred contexts and command lists are not mandatory. AMD have specifically chosen not to use it in their driver. The drawback is significantly higher CPU overhead is observed, which heavily chokes the GPU(s) in CPU intensive applications. However, the positives from this is that you get a simple and stable driver which can work with almost any newly released game without compatibility issues and the need for specific driver tweaks. It also gives consistent performance in most games across the board, even if that performance is relatively low. Hence why you can run pretty much any Indie game on an AMD card without a "not supported" error message. In contrast to Nvidia drivers, each game requires driver tweaks for that game to actually remain stable. This is a lot of work for the driver team, but at least you are getting the performance boosts from the multi rendering capabilities of Direct-X 11. I would not be surprised if AMD chose compatibility over performance to either reduce staff workload, or because the driver team don't have the ability to compile a fully stable driver which uses such features discussed.

AMD have shown promise in the past with their CPU overhead issues with "Sid Meier's Civilization Beyond Earth", whereby they worked closely with the developer to ensure the game used good API optimization methods for enhanced CPU performance. AMD also enabled command list support (such a rare moment) for this title which allowed proper usage on all threads.

This is mostly about theory and isn't related to the emu for the most part. AMD went for higher compatibility with games without requiring special tweaks and in turn took the perf hit from lacking the command lists. Would it have been cool if AMD allowed users to enable the command list support via the Radeon CP? I think so. But for whatever reason they didn't.

[refraction]

That's to do with DX11 overhead, we aren't talking about that, nor do we have an issue with it. it's the OpenGL overhead which is shocking on AMD cards as they don't support Multithreaded OpenGL, where Nvidia does.

[NarooN]

Derp, no idea why I kept talking about DX11 when it's about OpenGL. This is what happens when I multi-task too hard lol.

On that note, I have no idea why their driver doesn't support it in OpenGL. I think AMD was focused on the new API's to the point that they just said "f*ck it" to everything else. Their track record with OpenGL -- especially on Linux -- has been very lackluster for quite a while. Vulkan should fix this, not in terms of magically granting 5 billion frames per second (something I never believed to begin with, regardless of whether it's a native PC game or an emulated one) but in terms of opening up feature-sets and granted higher accuracy.

[gregory]

Well they need 6 months to release a BSOD fix. They likely need a couple of years to release a performance improvement (as a side note a single performance fix won't close the performance gap)

[lightningterror]

Didn't Mirh get a pm from one of the devs saying they found a way to optimize opengl? I believe this was around the same time the bsod bug got reported.
I predict a release for both the optimization and bug fix around April xD

[gregory]

I'm pretty sure you mean the 1st April

Yes, they found an obvious way to optimize the separate_shader_object extension on their driver. It is really obvious, they will skip validation of the VS when a new FS is loaded (seriously it is the goal of the extension). However a single optimization won't give a huge speedup.

[PS2Linx]

=> https://community.amd.com/thread/194895

=> fastest solution buy an Nvidia card !
=> hardest solution: recode the plugin with vulkan (or improve the open source driver and switch to linux).

How do you recode the plugin with Vulkan or make OpenGL work better?Im using Manjaro Linux with an AMD RX 480 8GB and I’m searching for a solution for the slowdowns when playing MGS2.

[jesalvein]

The most recent post in this thread is more than 8 months old. Please create a new thread and refrain from posting in threads older than 8 months in the future. Please also review the forum rules. Thank you.