4 ms·

Sure. RX480, Reference Edition. I’ve tried: Arch Linux, Ubuntu 16.04, 16.10, 17.04 (currently on 16.04), latest Fedora. Time period: Bought GPU 11 days after

Sure. RX480, Reference Edition. I’ve tried: Arch Linux, Ubuntu 16.04, 16.10, 17.04 (currently on 16.04), latest Fedora. Time period: Bought GPU 11 days after official release, been switching distros about every one or two months since due to issues. Only used distro-provided kernel, Mesa and Xorg. With AMDGPU, no game works and OpenGL crashes, Wayland crashes, and nothing really works. In all cases. With AMDGPU-PRO, everything works, except there’s a 50/50 chance on every boot that WebGL in Firefox will be broken. ________________ > which they've had an issue with due to trying to provide a custom 'DAL' as a proprietary interface to their real driver in userspace This is exactly why I criticize the stubborn decision to refuse to allow such a solution. If the DAL is not implemented, we’ll never get feature parity for proprietary functionality between the Windows, Linux and Mac versions. AMD is known to release all their tech openly as soon as possible, but while they’re competing with NVIDIA in a space, they obviously can’t keep it 100% open. And it’s also obvious that if AMD wants the same functionality on Windows, Linux, Mac and Android, they either need a DAL, or they need to let the Linux maintainers control their drivers for all other platforms.

flukus 9y ago
I got an RX480 (no idea what edition) at the start of the year and it worked fine with with arch and ubunutu gnome 17.04. I've had some issues like the occasional system freeze and one game in particular always freezing but it's been stable for the most part. Other distros (including earlier ubuntu) went into some horribly unusable resolution on boot. I was annoyed at the teething problems too, but the progress has been good enough that I stable API doesn't seem necessary. If they hadn't tried to work in their own abstractions then the progress might have been better.
- kuschku 9y ago
  > If they hadn't tried to work in their own abstractions then the progress might have been better. Not really. You're still so stubborn about having no DAL. How do you propose should AMD develop an additional driver functionality for Linux, Mac, Windows and Android, and release them on the same day, without writing code twice, without such a DAL? You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes. But that's not true for GPU drivers anymore. GPU drivers have to get feature updates every few weeks, and add new functionality and new APIs on all platforms at the same time with the same APIs. Often APIs that are completely new. You can't write all this functionality 5 times for every platform while staying competitive with NVIDIA. The only choice is having a stable ABI to write driver extensions that implement the same new functionality for all platforms, or you'll never get the functionality. And, guess what, that's exactly what happened. Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux. AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. They absolutely can not release new features every week for the mainlined driver in the official kernel and write them separately for every OS. The alternative is a DAL, or no functionality. Thank you for driving more users to Windows.
  - thomastjeffery 9y ago
    > and release them on the same day That isn't necessary. > without writing code twice That isn't anywhere near as difficult as you make it out to be. Writing code is not difficult, or particularly time-consuming. Designing code is. Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. to run incorrectly to optimize for a specific proprietary game engine. Those updates are to the OpenGL/etc. implementation itself, not the communication with the kernel, meaning those changes will be similar, if not exactly the same in each driver, without any extra abstraction. Also remember that most of these AAA title games do not have Linux support in the first place, and many of them only support DirectX, which will not be implemented in the Linux driver. Here in Linux, we care about FPS in proprietary game engines much less than correct working drivers. > You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes. It's true that graphics APIs (especially Vulkan) are continually changing, and that those changes must be implemented in each driver. That still does not mean it is significantly easier to write one implementation for windows, and just copy it to the Linux driver. In fact, those who work on Linux itself believe the opposite. It's also worth noting that Vulkan is meant to be so low-level that its implementations will likely be quite different between Windows and Linux. > AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me. > Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux. You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. That means you are relying on AMD alone to implement them, so I am entirely unable to help you. That is the situation we started with for the entire driver, and AMDGPU marks a significant improvement. You may believe that Linux devs compromising to allow AMD to create a complicated layer in their mainline driver would help them, but I don't believe that to be the case, and neither do they. The true reason that AMD wants a DAL in their driver is that they aren't willing to entirely discard their old habits, and instead insist on a driver that is, at least partially, closed source. As long as they do that, they require themselves to do wildly unnecessary work, and create entirely worthless incompatibilities, purely out of stubbornness. Stubbornness that will continue to be reciprocated by the Linux dev team. I will continue to do what I can to support AMD, as long as they make strides toward Free drivers, but I know there are always politics involved, and that AMD won't change overnight.
thomastjeffery 9y ago
> they obviously can’t keep it 100% open. Why not? Even if you honestly believe that it is a good idea to hide superior driver code (which it is not), AMD doesn't have any. NVIDIA has had superior proprietary drivers since AMD acquired ATI.
- kuschku 9y ago
  It’s not that simple. AMD has to license code from other third parties, too (which is a common reason for proprietary code), and in some situations (as with the new tiled rasterizer of VEGA, which with its beta drivers gets 2x the performance of the open driver), it has significant advantages over what NVIDIA has. AMD always has opened as much as possible, as soon as possible, but there’s situations where that’s not directly possible. And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
  - thomastjeffery 9y ago
    > AMD always has opened as much as possible, as soon as possible, but there’s situations where that’s not directly possible. This is the problem with proprietary software. There are politics involved. Note that when I refer to AMD, I am referring to a group of people, not a single individual. Those at AMD and those third parties that they work with that insist on proprietary software have made my life miserable. The hours I have spent trying to find a stable configuration to run fglrx are a direct result of their belief in the need for proprietary software. I'm sick of their excuses. I'm happy to finally have a free driver for my RX480. It's not perfect, but it's a leap in the right direction. > And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that. That is true. I see that as AMD's fault, not the Linux devs'.
    - kuschku 9y ago
      > That is true. I see that as AMD's fault, not the Linux devs'. And I disagree with that. AMD has said they'd publish it openly, but only in a version that relies on their abstraction layer. Because implementing it the first time already is over budget and past deadline, implementing it twice would be impossible. You can have a working, open source, version in a few weeks just by compiling AMDs kernel branch, and modules. But you'll never get it in mainline. And mainline will always be months or years behind.

flukus 9y ago

I got an RX480 (no idea what edition) at the start of the year and it worked fine with with arch and ubunutu gnome 17.04. I've had some issues like the occasional system freeze and one game in particular always freezing but it's been stable for the most part. Other distros (including earlier ubuntu) went into some horribly unusable resolution on boot. I was annoyed at the teething problems too, but the progress has been good enough that I stable API doesn't seem necessary. If they hadn't tried to work in their own abstractions then the progress might have been better.

kuschku 9y ago
> If they hadn't tried to work in their own abstractions then the progress might have been better. Not really. You're still so stubborn about having no DAL. How do you propose should AMD develop an additional driver functionality for Linux, Mac, Windows and Android, and release them on the same day, without writing code twice, without such a DAL? You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes. But that's not true for GPU drivers anymore. GPU drivers have to get feature updates every few weeks, and add new functionality and new APIs on all platforms at the same time with the same APIs. Often APIs that are completely new. You can't write all this functionality 5 times for every platform while staying competitive with NVIDIA. The only choice is having a stable ABI to write driver extensions that implement the same new functionality for all platforms, or you'll never get the functionality. And, guess what, that's exactly what happened. Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux. AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. They absolutely can not release new features every week for the mainlined driver in the official kernel and write them separately for every OS. The alternative is a DAL, or no functionality. Thank you for driving more users to Windows.
- thomastjeffery 9y ago
  > and release them on the same day That isn't necessary. > without writing code twice That isn't anywhere near as difficult as you make it out to be. Writing code is not difficult, or particularly time-consuming. Designing code is. Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. to run incorrectly to optimize for a specific proprietary game engine. Those updates are to the OpenGL/etc. implementation itself, not the communication with the kernel, meaning those changes will be similar, if not exactly the same in each driver, without any extra abstraction. Also remember that most of these AAA title games do not have Linux support in the first place, and many of them only support DirectX, which will not be implemented in the Linux driver. Here in Linux, we care about FPS in proprietary game engines much less than correct working drivers. > You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes. It's true that graphics APIs (especially Vulkan) are continually changing, and that those changes must be implemented in each driver. That still does not mean it is significantly easier to write one implementation for windows, and just copy it to the Linux driver. In fact, those who work on Linux itself believe the opposite. It's also worth noting that Vulkan is meant to be so low-level that its implementations will likely be quite different between Windows and Linux. > AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me. > Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux. You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. That means you are relying on AMD alone to implement them, so I am entirely unable to help you. That is the situation we started with for the entire driver, and AMDGPU marks a significant improvement. You may believe that Linux devs compromising to allow AMD to create a complicated layer in their mainline driver would help them, but I don't believe that to be the case, and neither do they. The true reason that AMD wants a DAL in their driver is that they aren't willing to entirely discard their old habits, and instead insist on a driver that is, at least partially, closed source. As long as they do that, they require themselves to do wildly unnecessary work, and create entirely worthless incompatibilities, purely out of stubbornness. Stubbornness that will continue to be reciprocated by the Linux dev team. I will continue to do what I can to support AMD, as long as they make strides toward Free drivers, but I know there are always politics involved, and that AMD won't change overnight.

thomastjeffery 9y ago

> they obviously can’t keep it 100% open. Why not? Even if you honestly believe that it is a good idea to hide superior driver code (which it is not), AMD doesn't have any. NVIDIA has had superior proprietary drivers since AMD acquired ATI.

kuschku 9y ago
It’s not that simple. AMD has to license code from other third parties, too (which is a common reason for proprietary code), and in some situations (as with the new tiled rasterizer of VEGA, which with its beta drivers gets 2x the performance of the open driver), it has significant advantages over what NVIDIA has. AMD always has opened as much as possible, as soon as possible, but there’s situations where that’s not directly possible. And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
- thomastjeffery 9y ago
  > AMD always has opened as much as possible, as soon as possible, but there’s situations where that’s not directly possible. This is the problem with proprietary software. There are politics involved. Note that when I refer to AMD, I am referring to a group of people, not a single individual. Those at AMD and those third parties that they work with that insist on proprietary software have made my life miserable. The hours I have spent trying to find a stable configuration to run fglrx are a direct result of their belief in the need for proprietary software. I'm sick of their excuses. I'm happy to finally have a free driver for my RX480. It's not perfect, but it's a leap in the right direction. > And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that. That is true. I see that as AMD's fault, not the Linux devs'.
  - kuschku 9y ago
    > That is true. I see that as AMD's fault, not the Linux devs'. And I disagree with that. AMD has said they'd publish it openly, but only in a version that relies on their abstraction layer. Because implementing it the first time already is over budget and past deadline, implementing it twice would be impossible. You can have a working, open source, version in a few weeks just by compiling AMDs kernel branch, and modules. But you'll never get it in mainline. And mainline will always be months or years behind.