AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver

[d2kx]

Awesome strategy Sharing the code means it has to be good, because everyone depends on it. And that the new AMD cards will use the opensource DDX aswell is even better, as everyone knows how much better the opensource driver is in everything 2D related (2D performance, tearing, video...).

Would be interesting to know if the R9 285 will be supported, because that's a brand new IP, newer than Hawaii (R9 290) or Bonaire (R7 260). Anyways, I will upgrade the GPU when the new drivers are out in the coming months.

[dungeon]

So eagerly waiting for 20nm products next year , hm maybe i will be interested in switchable ARM_64/X86_64 socket

But really new driver is expected with APU raise and ARM in the game, together with HSA that might need also entirely new MM, etc.

[BoTuLoX]

"There are no current plans to enable support for any ASICs which are already supported in Radeon."

So... Intel / Intel+nVidia for my new laptop and discrete nVidia for my desktop.

Got it, thanks AMD.

[CrystalGamma]

I still feel pretty hazy on how this works and what products will be affected. It seems like a good idea overall but:
1. Is catalyst itself just a closed-source user-space application used to configure the GPU, but the drivers themselves stand separately as open source?
2. Will you be able to install strictly the drivers without catalyst? In the event where you want to install these drivers on a non-x86 platform (or perhaps a completely GNU-friendly platform), what options do users have?
3. Will features like openGL 4.x, crossfire, freesync, etc be available at launch?
4. It appears everything before the R9 290 series will not be part of this driver. If this is true, will the current state of the FOSS drivers remain in development maintaining these older devices?
4a. If the last answer is yes, what exactly is the plan for that? Will they eventually gain all their advertised hardware features or will they just try to maintain mesa compliance and leave it at that?
5. Will this new catalyst driver be mesa compliant?

Sorry if some of these questions are obvious or have already been answered, there just seems to be a bit of ambiguity here.

1. On Linux, (and probably everywhere else as well) drivers have two parts: one system-wide (which is privileged and has control over things like modesetting - this part is a kernel module called a DRM/KMS module under the Linux model, also the DDX in the display server) and one per application (this part translates API calls into hardware-specific commands - under Linux this is typically a shared library).
The latter part is the one that is supposed to remain closed-source, while the former one will be open-source and shared with the Mesa Radeon driver (for supported hardware)
2. Likely the Mesa driver for Radeon will get support for this new Kernel module and the DDX will be open-source as well, so yes - you will be able to install a working GUI system without Catalyst, which will probably even support games when [Insert gfx API here] is supported well enough in Mesa.
3. Well, Mesa does not have support for OpenGL 4 right now, but it may get it in the next months (but if support for it will be supported day-one is doubtful).
Catalyst will most likely support GL4 at launch (would be an embarrassment if it didn't).
FreeSync would likely mostly need Kernel support. IDK if support for this is planned for launch of the new driver or launch of the hardware it supports.
AFAIK there are no games or APIs that support Multi-GPU on Linux thus far, but since the new kernel module supports DRM/KMS and therefore likely DMABUF, cross-device data transmission will be supported by the infrastructure.
4. IDK, I would assume so
5. In the sense that you could use both on the same machine at the same time, yes. If you mean it being a part of mesa or using Mesa infrastructure (like Gallium3d) then no.

If anyone knows better than me, feel free to correct me.

[My8th]

This is like Chrome and Chromium, we have a open source base with some closed parts (Flash, Widevine, formerly PDF, ect). Keep up the good work AMD, I'll definitely be sticking with you for my gaming rig.

[schmidtbag]

I still feel pretty hazy on how this works and what products will be affected. It seems like a good idea overall but:
1. Is catalyst itself just a closed-source user-space application used to configure the GPU, but the drivers themselves stand separately as open source?
2. Will you be able to install strictly the drivers without catalyst? In the event where you want to install these drivers on a non-x86 platform (or perhaps a completely GNU-friendly platform), what options do users have?
3. Will features like openGL 4.x, crossfire, freesync, etc be available at launch?
4. It appears everything before the R9 290 series will not be part of this driver. If this is true, will the current state of the FOSS drivers remain in development maintaining these older devices?
4a. If the last answer is yes, what exactly is the plan for that? Will they eventually gain all their advertised hardware features or will they just try to maintain mesa compliance and leave it at that?
5. Will this new catalyst driver be mesa compliant?

Sorry if some of these questions are obvious or have already been answered, there just seems to be a bit of ambiguity here.

[_SXX_]

All new open-source GPU support will be on this new driver with no new GPU support being planned for AMD's existing Radeon Linux driver -- the open-source driver as we know it today. This new kernel driver is based on the current Radeon DRM code and Alex explained they used Sea Islands graphics processors for prototyping and testing the new kernel driver, but when merged and in production this driver will be used for post Radeon R9 290 graphics cards. "There are no current plans to enable support for any ASICs which are already supported in Radeon."

This is bummer. It's mean none of AMD hardware I have going to be supported by this new driver.

Still will be interesting to wait if this driver going to be mainlined before new AMD GPUs released.

[89c51]

but the kernel/X.org drivers which were custom for *NIX anyway will now be sharing development with the open-source driver.
.

Are there serious performance problems in that part of the driver?? I thought more development was needed in the g3d part of the driver.

[Veerappan]

I think this way could be better for their Linux drivers in the long run. However, I am concerned that if the Windows and Linux drivers won't share the same code, features won't be implemented in the Linux drivers and it will just add another driver to support with it's own idiosyncrasies. Supporting another driver code base might be too expensive for AMD unless they get a lot of outside help from the community.

From what I understand, the existing Catalyst kernel driver and X.org driver are the few things that aren't shared with the Windows/Mac driver. So the GL compiler, CL runtime, CL Compiler, etc for Catalyst will still be sharing code with the windows driver, but the kernel/X.org drivers which were custom for *NIX anyway will now be sharing development with the open-source driver.

So what used to be shared with windows will still be shared, and the open-source drivers will now get to share some (more?) development resources with the closed driver.

EDIT: And now that I think of it, this might also open up the way to Catalyst on BSD.

[somini]

This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.

You call it "distro getting in the way", I call it "assurance that some brainfart by some of their employees doesn't crash my kernel".