5 ms·

What's the practical effect of this? We'll have to wait until someone writes a reasonable alternative for these GPUs to be supported in Linux? Edit: Here's the

by bentona 10y ago

What's the practical effect of this? We'll have to wait until someone writes a reasonable alternative for these GPUs to be supported in Linux? Edit: Here's the start of the thread https://lists.freedesktop.org/archives/dri-devel/2016-December/126422.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...

orionblastar 10y ago
SteamOS and SteamMachines will be delayed as well. Nvidia support for Linux is hard to get as well. Now AMD support is also hard to get. Hardware OEM companies make Windows drivers, and don't seem to care about Linux. This is the same thing that happened to IBM and OS/2 not good third party driver support. There are open source drivers that work, but are not as fast as the proprietary drivers. Linux needs better display drivers and for that OpenCL or Vulkan support as well. Windows uses dotnet and DirectX for games.
- kstrauser 10y ago
  > SteamOS and SteamMachines will be delayed as well. Not necessarily. It not being merged into mainline Linux doesn't mean that other parties can't include it with their own distros.
- microcolonel 10y ago
  Windows games are generally not made in dotnet, and games which are made in dotnet (mostly Unity) are actually run on Mono. AMD's Mesa RadeonSI(free) driver frequently outpaces their fglrx(proprietary) driver on recent hardware. NVIDIA and AMD distribute good quality proprietary drivers for Linux, but given the pace the Linux kernel takes, and the benefits of integrating with the native interfaces of the kernel, AMD has decided to write good quality open source drivers as well as their proprietary ones. NVIDIA blocks community open source efforts by delaying the release of firmware images vital to enabling basic features of their GPUs. SteamOS is shipping fglrx for now, and fglrx doesn't currently rely on the DC kernel code. Most SteamMachines seem to be NVIDIA-based for now, and while it's inconvenient to ship their proprietary driver, it is in no danger of failing to work. Read an article or something.
  - untoreh 10y ago
    you can do a quick browse on winehq and see that quite a lot of games use dotnet
    - SXX 10y ago
      Yeah a lot of games use it for configuration / mod management and auto-update tools. But list of games that only use dotnet is relatively short.
- majewsky 10y ago
  What are you talking about? The amdgpu driver has been in the kernel for over a year and has been working just fine ever since. Source: My desktop PC has an R9 Nano, and I've used the amdgpu driver since Linux 4.5 (when it good power management support for my card and thus could enable usual GPU clock speeds).
- prodigal_erik 10y ago
  Microsoft management happened to OS/2. There was plenty of hardware that worked, OEMs just couldn't get away with selling a complete system.
deleted 10y ago
[deleted]
zanny 10y ago
This whole project from AMD was to try to unify their driver infrastructure between Linux and Windows, because their old FGLRX driver was trash and was a hacked together mess of Windows bits tied to the Linux system with its own binary kernel driver. So they wanted to get rid of the ugly kernel part that was a PITA to install and update and are now pushing a lot of their hardware abstraction code from Windows into kernel patches so the AMDGPU driver can just talk to the Windows blob pretty much verbatim (which is now AMDGPU Pro). The practical effect is a continuation of the status quo. AMDGPU Pro, without a lot of this functionality, is either broken or underperforming across all distros. It is still better than what the last FGLRX was, but nowadays the Gallium free driver they also develop is beating the blob in almost everything except the latest driver-level optimized games. Most distros have completely dropped all proprietary AMD support. Going forward, it will be up to them to ship a proprietary driver and maintain installation faculties pretty much everywhere. AMDGPU with Mesa is going to continue working fine, new GPUs are getting supported still, and a lot of what this HAL does (display / window management) has had usable support that has worked for years in various parts of Gallium / Mesa / DRM. The optimistic future is that AMD drops AMDGPU Pro, refocuses developer effort on AMDGPU / Gallium, and works with the rest of the Linux graphics community to implement Freesync / Trueaudio / whatever other tech AMD has buzzwords on into shared kernel code rather than trying to stick it in a HAL from their Windows driver. The pessimistic view has AMD just fire or reassign a lot of its Linux staff, leaving its hardware on the platform to wilt. It would never stop entirely, AMD provides programming manuals for their hardware and most of their ASM in new platforms to enable almost anyone to program their GPUs (unlike Nvidia, who publishes nothing, requiring devs to reverse engineer their hardware and ASM) so the support would still be better than Nouveau.
- pjmlp 10y ago
  Nothing is preventing AMD to only provide manuals under NDAs, just like NVidia, if they stop seeing value in their contributions.
- witty_username 10y ago
  Why can't AMD work on the open-source driver? It works good in my experience unlike fglrx.
saalweachter 10y ago
Someone at AMD is not making their Q4 OKRs.

by bentona 10y ago

orionblastar 10y ago

SteamOS and SteamMachines will be delayed as well. Nvidia support for Linux is hard to get as well. Now AMD support is also hard to get. Hardware OEM companies make Windows drivers, and don't seem to care about Linux. This is the same thing that happened to IBM and OS/2 not good third party driver support. There are open source drivers that work, but are not as fast as the proprietary drivers. Linux needs better display drivers and for that OpenCL or Vulkan support as well. Windows uses dotnet and DirectX for games.

kstrauser 10y ago
> SteamOS and SteamMachines will be delayed as well. Not necessarily. It not being merged into mainline Linux doesn't mean that other parties can't include it with their own distros.
microcolonel 10y ago
Windows games are generally not made in dotnet, and games which are made in dotnet (mostly Unity) are actually run on Mono. AMD's Mesa RadeonSI(free) driver frequently outpaces their fglrx(proprietary) driver on recent hardware. NVIDIA and AMD distribute good quality proprietary drivers for Linux, but given the pace the Linux kernel takes, and the benefits of integrating with the native interfaces of the kernel, AMD has decided to write good quality open source drivers as well as their proprietary ones. NVIDIA blocks community open source efforts by delaying the release of firmware images vital to enabling basic features of their GPUs. SteamOS is shipping fglrx for now, and fglrx doesn't currently rely on the DC kernel code. Most SteamMachines seem to be NVIDIA-based for now, and while it's inconvenient to ship their proprietary driver, it is in no danger of failing to work. Read an article or something.
- untoreh 10y ago
  you can do a quick browse on winehq and see that quite a lot of games use dotnet
  - SXX 10y ago
    Yeah a lot of games use it for configuration / mod management and auto-update tools. But list of games that only use dotnet is relatively short.
majewsky 10y ago
What are you talking about? The amdgpu driver has been in the kernel for over a year and has been working just fine ever since. Source: My desktop PC has an R9 Nano, and I've used the amdgpu driver since Linux 4.5 (when it good power management support for my card and thus could enable usual GPU clock speeds).
prodigal_erik 10y ago
Microsoft management happened to OS/2. There was plenty of hardware that worked, OEMs just couldn't get away with selling a complete system.

deleted 10y ago

[deleted]

zanny 10y ago

This whole project from AMD was to try to unify their driver infrastructure between Linux and Windows, because their old FGLRX driver was trash and was a hacked together mess of Windows bits tied to the Linux system with its own binary kernel driver. So they wanted to get rid of the ugly kernel part that was a PITA to install and update and are now pushing a lot of their hardware abstraction code from Windows into kernel patches so the AMDGPU driver can just talk to the Windows blob pretty much verbatim (which is now AMDGPU Pro). The practical effect is a continuation of the status quo. AMDGPU Pro, without a lot of this functionality, is either broken or underperforming across all distros. It is still better than what the last FGLRX was, but nowadays the Gallium free driver they also develop is beating the blob in almost everything except the latest driver-level optimized games. Most distros have completely dropped all proprietary AMD support. Going forward, it will be up to them to ship a proprietary driver and maintain installation faculties pretty much everywhere. AMDGPU with Mesa is going to continue working fine, new GPUs are getting supported still, and a lot of what this HAL does (display / window management) has had usable support that has worked for years in various parts of Gallium / Mesa / DRM. The optimistic future is that AMD drops AMDGPU Pro, refocuses developer effort on AMDGPU / Gallium, and works with the rest of the Linux graphics community to implement Freesync / Trueaudio / whatever other tech AMD has buzzwords on into shared kernel code rather than trying to stick it in a HAL from their Windows driver. The pessimistic view has AMD just fire or reassign a lot of its Linux staff, leaving its hardware on the platform to wilt. It would never stop entirely, AMD provides programming manuals for their hardware and most of their ASM in new platforms to enable almost anyone to program their GPUs (unlike Nvidia, who publishes nothing, requiring devs to reverse engineer their hardware and ASM) so the support would still be better than Nouveau.

pjmlp 10y ago
Nothing is preventing AMD to only provide manuals under NDAs, just like NVidia, if they stop seeing value in their contributions.
witty_username 10y ago
Why can't AMD work on the open-source driver? It works good in my experience unlike fglrx.

saalweachter 10y ago

Someone at AMD is not making their Q4 OKRs.