Originally posted by dffx
View Post
Announcement
Collapse
No announcement yet.
The Good & Bad OpenGL Drivers On Linux
Collapse
X
-
All opinions are my own not those of my employer if you know who they are.
-
Originally posted by IanS View PostCouldn't help but notice the AMD blob was left out of the article. Where does that sit in the list?
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."
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.
Comment
-
"...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.
Comment
-
Originally posted by log0 View Post"...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.
Comment
-
Originally posted by Developers View Post"...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..."
Comment
-
Originally posted by brosis View PostThat 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.
Comment
-
Comment