The Good & Bad OpenGL Drivers On Linux

[Ericg]

Isn't it a little over-broad to lump all Mesa drivers in together? There's a wiiiide range of performance differences between different chipsets from different manufacturers.

Not really because the blog post also centered around how willing the developers were willing to work with bugs they found, in which case Mesa responded VERY quickly (typically same day for the bugs referenced). Also if the open source drivers SUPPORT something it typically WORKS. Maybe its not the fastest but personal experience is if they say "This WORKS" then it does. There's no "Well we say we support it but it doesn't actually work in practice." Maybe its not the fastest but they tried their best to be ACCURATE. Which is the point of one of the bugs mentioned-- Mesa supported VBO's, Dolphin used VBO's. They 'worked' but they weren't that fast and there was a couple minor issues. Bugs reported, patches submitted, patches accepted. All in a matter of hours, with a personal thank you from the mesa devs to the dolphin devs because they didn't have a real-world workload prior to actually run that code path-- now they do.

[IanS]

Couldn't help but notice the AMD blob was left out of the article. Where does that sit in the list?

[curaga]

Couldn't help but notice the AMD blob was left out of the article. Where does that sit in the list?

Huh? It was the "mediocre" one.

[ObiWan]

Couldn't help but notice the AMD blob was left out of the article. Where does that sit in the list?

It's there:

AMD's Linux OpenGL driver has a "medicore" rating with "A lot of issues that do not happen on Windows are present on Linux, sometimes with a very visible effect in our emulator."

And in the blog right after Intel

Mediocre - AMD
We had the most issues with AMD when using their proprietary graphics driver on Linux, fglrx/Catalyst. A lot of issues that do not happen on Windows are present on Linux, sometimes with a very visible effect in our emulator.

One of the most widespread issues we had with AMD drivers actually corrupts textures when an application asks the driver to create mipmaps. Here is what it looks like on a very simple textured cube demo for the Wii, running in Dolphin:


This happens when creating a GL_UNSIGNED_SHORT_5_6_5 texture and running glGenerateMipmap. Our first complaints about this bug started more than 2 years ago. A thread was started on the AMD developer forums, only to be ignored and deleted when AMD moved to a new developer forums system a year later. To this day we are not sure if this bug was ever fixed, but due to changes in the way Dolphin emulates mipmapping, this is not an issue for us anymore.

The quality of the code in the userland AMD driver looks horrible from the outside: using valgrind on a program using the AMD driver causes valgrind to complain about the large number of errors (ioctls using unintialized structures, access to unintialized memory). In some error cases, instead of reporting an error to the caller, the AMD driver will simply call exit(123) and kill the whole application. This kind of issues impacted SDL 1.3: calling XCloseDisplay caused the driver to exit. A workaround was put in place later in SDL 2.0 to avoid this problem which should have never happened in the first place. Fun fact: this bug was found while writing a minimal program that reproduce the mipmapping issue?

But bugs don?t only happen on fglrx: the Windows AMD driver also has a few major bugs. AMD supports a form of client-side buffer storage that would be extremely useful for Dolphin. It is exposed via the AMD_pinned_buffer extension. Using AMD_pinned_buffer with Vertex Buffers or Uniform Buffers works perfectly, but trying to use it with Index Buffers starts rendering random polygons. Because of this issue, we had to stop using AMD_pinned_buffer for Index Buffers, leading to decreased performance for AMD users of our OpenGL backend.

To this day we?re still not sure how to report fglrx bugs to AMD: we haven?t seen developers reply to bug reports on their official forums, and while there is an unofficial bug tracker for fglrx issues it does not seem to be looked at by AMD developers and keeps accumulating new issues.

On the other hand, AMD is making steps that will help Dolphin a lot in the future: pioneering Unified Memory Access for graphics APIs, and working on Mantle, a new API that exposes more low-level GPU features to applications. If these last two improvements come together, it could potentially make AMD GPUs the best platform for high-gen console emulation.

[log0]

"...Our first complaints about this bug started more than 2 years ago. A thread was started on the AMD developer forums, only to be ignored and deleted..."

That is something I've had to learn too. If you are not some AAA games (or multi-million corp graphics) developer, blob driver devs (not only AMD, pretty much all of them) don't give shit, forget about reporting bugs and start to work on workarounds.

[curaga]

"...Our first complaints about this bug started more than 2 years ago. A thread was started on the AMD developer forums, only to be ignored and deleted..."

That is something I've had to learn too. If you are not some AAA games (or multi-million corp graphics) developer, blob driver devs (not only AMD, pretty much all of them) don't give shit, forget about reporting bugs and start to work on workarounds.

Echoing this. Even better than workarounds, publicly name and shame them if at all possible.

[chrisb]

It's there:



And in the blog right after Intel

The Phoronix article should mention that "AMD's Linux OpenGL driver" means the closed source one. It isn't clear at all.

[brosis]

"...Our first complaints about this bug started more than 2 years ago. A thread was started on the AMD developer forums, only to be ignored and deleted..."

That also means, regardless if you are huge or small, work with opensource, NOT with catalyst. If catalyst cares - they will implement changes back. BUT, regardless who helps push the open driver forward - everyone is at win, always. Thats the difference.

[mmstick]

That also means, regardless if you are huge or small, work with opensource, NOT with catalyst. If catalyst cares - they will implement changes back. BUT, regardless who helps push the open driver forward - everyone is at win, always. Thats the difference.

The same applies to NVIDIA as well. Neither AMD nor NVIDIA apparently check their forums. In order to get contact with them, you need to find the contact details of the developers themselves.

[brosis]

The same applies to NVIDIA as well. Neither AMD nor NVIDIA apparently check their forums. In order to get contact with them, you need to find the contact details of the developers themselves.

Nvidia responded within 6 days, so its different.