So, I have bought AMD Radeon 6800 back in the December when it released here. I have previously used AMD Radeon 590 (just FYI).

One of my projects I do is a software running in GTK+ with OpenGL rendering. It has been running on over dozen of machines, every single one without any problem … then there is new AMD graphics card.

Prior to watching - STRONG WARNING (especially for epileptics) - this video contains a lot of flickering, please bear this in mind. Do NOT play it unless you are used to new AMD graphics cards.

Sorry for strong sarcasm, but this issue has been dragging for about 6 months. AMD is not replying on their forums, and no one has contacted me so far despite my numerous bug reports in their software. I can replicate the issue even with other OpenGL applications.

Apart from flickering like this (it is not just the viewport, but also the actual GUI that eventually flickers), I do get occasional (in complex programs much more often) crashes in their drivers. They are random and always related to OpenGL driver from AMD. Like:

One could argue that this might be GTK+ related. I was able to reproduce it with SFML too (although due to much simpler scene, it happens far less frequently). I tried using RenderDoc, the issue seems much smaller when RenderDoc is attached - but eventually I end up with black screen and complete driver crash. Capturing sequential frames in RenderDoc ends up in crash of the application (RenderDoc survives, but doesn't capture anything).

I'm also getting driver crashes inside atio6axx.dll inside Unigine Heaven benchmark when running it with OpenGL. Although it doesn't seem to suffer from flickering issue. Those 2 issues (driver crashes and flickering - might be unrelated to each other, but both are related to broken OpenGL drivers on AMD gpus)

Does anyone else experience similar issues?

Is there a way for me to solve it? Or at least, is there a PROPER way to contact AMD support? I'm willing to write up small application (even open sourced) that would expose their driver problems so they could finally fix it. I was willing to wait for 6 months, but it's been dragging for way too long.

NOTE: Clear solution of buying new GPU is NOT a solution. First of all, there are no GPUs in stock in my country (quite literally) … and while I could possibly use older GPU (that AMD Radeon 590 - which does work - and I will likely have to do that as temporary solution for me, so I can work), I have no control over what other users of the application use.

…

Or do I have to go through drastic way and simply drop AMD support altogether, and specifically add recommendation for the users that AMD graphics cards are not supported?

I recall seeing lots of issues with AMD and various OpenGL things in various communities, especially performance on Windows. I think on Linux it might be better, but on Windows the answer seems to be use Direct3D 11/12. Not sure on Vulkan quality.

If people are still complaining that AMD has issues in Minecraft, there doesn't seem to be much hope for your project which would be way down their priority list.

I am having issues with AMD drivers as well, i pinpointed the problem being present in google chrome in a function called grabscreen, the computer hangs for several seconds, then exits all the programs opened causing me troubles with my visual studio applications opened. I contacted AMD support with no luck, they seems blind to usesr problems

The project originated back when Vulkan didn't even exist. Keep in mind that the project is quite big (the main application runs on GTK+), as it is being actively developed (and used) by multiple people for years.

Since then, we did have few problems with graphics drivers. Some of them were solvable using workarounds (I can remember one context related problem in Intel GPUs, for which I had to modify GTK+ itself … and obtain specific hardware to be able to fix that).

One of the "problems" is that the window is created by GTK+, which I use for GUI (and of course for context creation). The current GTK+ version used is 3.24.8, I have tried 3.24.28 (which seems to be highest buildable on Windows with gvsbuild). The context creation and use of OpenGL is pretty much the same in both - and clearly it doesn't solve the problem.

Other APIs like D3D12 (on which I have more modern custom game engine project - which of course runs fine) are not easy to integrate with this project, due to GTK+. The most logical step would be to move over to Vulkan. I have worked with it already, but not through GTK+. And that's where problems happen.

For Vulkan you need GTK4, that means major update in the source code (probably not fixed within few days, but rather weeks at least - if not more). If there is not a shorter way though, then I'm out of options and have to push this way. The good thing is, so far the only one using this graphics card architecture is me (out of all the users).

…

The ugly but working solution could be: Reproducing the issue with more basic GTK+ application. And then make another application without GTK+ (where I handle the context), and try to make sure I'm able to do it without the issue. If it works - then I can simply change whatever I need inside GTK+ and rebuild a custom version with my changes. Which is quite complicated - but I sadly can't rely on AMD fixing their driver issues.

I'm afraid the harsh reality here is that OpenGL is a dying platform, and driver support is likely to continue to decline. Porting to DirectX/Vulkan is a good choice, but since you are dealing with a large application on a legacy tech stack… not fun.

What are the chances that your application would run on a shim OpenGL implementation, like ANGLE?

It indeed is - the application is quite large, although the rendering engine is not that big (but architecture-wise it is outdated, compared to D3D12 engine I have written).

Running on shim implementation is not feasible (the application is GPU heavy and utilizes even today's high end GPUs to maximum for its purpose … along with things like OpenCL-OpenGL interop … this being said, OpenCL also seems to be dead due to Vulkan/D3D12 where you can simply have compute queues). The application is most likely going to live for many years, hardware will change to more modern over time (regularly).

…

So the obvious solution is:

1. Upgrade from legacy GTK3 (while still active, it is inevitably going to die out - much like GTK2, on which the application was originally built) to GTK4 (I have a working build under Windows already - I was concerned about its stability, but it's been out for months in stable release), it can still use OpenGL at this and I'll be able to check that all features work (at least on other graphics hardware) - this will replace legacy tech stack with new one
2. Upgrade from OpenGL to Vulkan
   • This means whole rendering engine must pretty much go (as compared to my D3D12 this one is not command list based)
   • Also there is probably not any easy way how to get through it - I mean, I could integrate some OpenGL extensions that “help with moving over to Vulkan” … but I can also just go ahead, build the basic renderer and start extending it one by one (going over each “entity” type we have making sure it works)

Long story short though - I will have to do major updates in the project. There is slim or no chance of AMD actually fixing the drivers.

Direct3D11 support is still pretty good, and is probably an easier port than 12 if you don't need that extra potential.

Sadly - integrating Direct3D 11 into GTK+ would be a bit of nightmare (integrating Direct3D 12 would be about the same hard).

Not to mention that GTK+ only allows either OpenGL or Vulkan (in GTK4) as renderer for the GUI itself. Downside of Vulkan is, that I will need to write my own widget that allows me to use context and draw into it.

I have written all my compute shaders in OpenCL, and used a C preprocessor and bunch of defines to use the same shader source for Vulkan as well. API abstraction wouldn't be so much work either for compute stuff at least.
Gfx on the other hand is a pain in the ass. Writing a textured software rasterizer is less code than drawing a damn triangle using Vulkan. I hate OpenGL, but often i still miss it :/

The downside here is that GTK4 doesn't really have equivalent of GtkGlArea for Vulkan (so this also means writing whole specific GTK widget is also needed).

Other option is praying for AMD to fix their drivers, and I guess everyone here knows that it's not going to happen anytime soon. Sadly.