7 ms·

Would you care to provide details relevant to your particular observation case? * What GPU hardware? * Which release of what distribution? * What p

Would you care to provide details relevant to your particular observation case? * What GPU hardware? * Which release of what distribution? * What period in time? * If you happen to recall, what versions of: Linux (kernel), Mesa, and Xorg? With the exception of the latest AMD GPUs (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), which will hopefully be better supported in kernels a few versions from now, less bleeding edge AMD GPUs just work if your distribution has reasonably recent releases. I happen to be using Arch Linux (a rolling release distribution) on my main gaming workstation. Thus my R9 285 is supported by Linux 4.13.4, Mesa 17.2.2, and Xorg 1.19.3. My overall system stability appears to be either approximately as stable as, or possibly more so than, the same hardware on a Windows platform. The only area of issues I run across these days are games that ship their own copies of libraries that /should/ be expected (and should be required) to be native libraries instead. A few games that should work have issues resulting from that general root cause and Steam doesn't always do the best job of utilizing the more up to date native libraries. Things weren't as bright when I first bought the hardware, but they have improved vastly as support in the drivers caught up, and I am confident that it will not regress in the future, at least not until long past when it would make sense to buy newer hardware.

kuschku 9y ago
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.

kuschku 9y ago

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.