AMD Releases New "AMDGPU" Linux Kernel Driver & Mesa Support

[Prescience500]

Ok, somebody please explain to a complete noob what all of this means. The way I understand it - AMD are pushing all current users under the bus. Yet I see people saying that the new driver will not be ready in a long time and we'll be stuck with fglrx for a while. Also what does it mean for performance because obviously this is the year that Linux gaming may gain momentum? If AMD are just going to be using the same old crappy driver for 90% of its user base why would I even bother to pup into my Linux partition - Photoshop and GTAV are on Windows anyway. My 290x struggles to keep 60fps on a game like Pillars of Eternity (in Linux) which has static hand drawn backgrounds. And that is with the latest beta driver. What about anybody who doesn't use Ubuntu or a derivative distro or people who don't want to use beta drivers? How are they going to catch up by November when the Steam Machines are coming?

This shouldn't have any direct effect on performance. The reason people are so happy is that it ends the proprietary kernel blob. Due to only having one kernel-side driver instead of two, developer time that is currently spent on kernel-side drivers will either be reduced to be spent on other driver parts or increased to make both drivers have less bugs. Also, it likely means that from here on out, both the mesa and Catalyst drivers will have same day support when the cards hit the market. Right now, we often have to wait. Every new kernel release shouldn't break Catalyst now. It will reduce the burden on distro devs and anyone who manually installs the proprietary drivers as well. Also, it will bring Catalyst much closer to Wayland support. In the long run, if having one less kernel driver allows developers to work more on the user space drivers, then features and performance will improve faster.

Edit: It seems Adarion beat me to responding. but I'll leave my comment here anyway since I mention additional advantages of the new kernel driver.

[brent]

Ok, somebody please explain to a complete noob what all of this means. The way I understand it - AMD are pushing all current users under the bus

Not at all. amdgpu just opens up new possibilities for recent and future GPUs. The old driver won't disappear and will still be maintained. The new driver stack also shares various components with the old one, so that's a given.

[Ziple]

Anyone know what Iceland is?

The GPU inside my laptop which is a R7M260 (Topaz chip) is detected as a member of the Iceland family by AMD CodeXL. So there are some members of this family which are not so recent (I bought my laptop 6 months ago).

[marek]

This is exciting. Can't wait for the R9 285 tests.

The R9 285 driver doesn't support dynamic power management yet, so it will run at the lowest clocks.

why it was necessary to create a new kernel driver ? Couldn't they use radeon for all generations ?

First of all, we needed a driver that was designed around HW blocks (e.g. a module for GFX7, GFX8, DCE9, DCE10, ..) and then the driver for certain hardware is assembled by combining the appropriate HW block implementations. We also needed to incorporate requirements from Catalyst. Finally, the code cleanup and the ability to design ioctls from scratch was worth it.

large amount of the point of amgpu was to start fresh without worrying about a decade old or more hardware; radeon is already a lost cause in that sense

I'd like to make clear that this will have no impact on users of the radeon driver. The radeon driver will continue to be supported and new features will continue to be added there.

can this already bring wayland support? can anyone use this on fedora 22 on wayland?, does Xwayland work on this puppy?

Wayland support is orthogonal. If there is Mesa support, there is also Wayland support no matter what the kernel driver is.

[ua=42]

Ok, somebody please explain to a complete noob what all of this means. The way I understand it - AMD are pushing all current users under the bus.

Umm. No.

The open source userspace (Gallium3d) is the same for the old cards and the new cards. So support for OpenGL/Vulkan will be the same between the two. (As long as the hardware is capable)
The open source drivers and the new binary drivers will share the same 2D code.
The new open source driver and the new binary driver will share the same kernel code.

The kernel side of the codebase for current and older hardware is pretty well done. Most of the speed improvements for 3d are in user space (LLVM, Mesa, etc).

They still plan to release binary drivers for current hardware. Its just that those binary drivers will still have all the current flaws (need specific kernels or it will break).

[GuercH]

But...

Wayland support is orthogonal. If there is Mesa support, there is also Wayland support no matter what the kernel driver is.

Please explain, will the new blob on user space have anything to do with wayland support?, Will the proprietary blob accelerate the wayland desktop? this new still to come user blob will use mesa beneath it?

[bridgman]

Please explain, will the new blob on user space have anything to do with wayland support?, Will the proprietary blob accelerate the wayland desktop? this new still to come user blob will use mesa beneath it?

Rather than thinking about "the new blob on userspace" it's probably easier to think about the existing Catalyst stack being rebuilt around the amdgpu kernel and X drivers, so that (a) we can have more developers working on common code rather than separate Catalyst/OSS code, and (b) we can have the bits that depend on kernel or X version living in open source.

The GL driver in the "hybrid" stack would not be based on mesa -- the code released yesterday already has a mesa-based driver.

If we do things right then both all-open and hybrid stacks should work identically with Wayland AFAIK.

[boffo]

Congratulation

I wont to congratulate AMD and all the AMD team working on the drivers.

[birdie]

I'd love NVIDIA to do something similar.

I.e. break their driver into two parts: a kernel driver which is 100% open source and provides a set of APIs to access the hardware and a userspace blob to talk to the driver/hardware beneath it.

This way the kernel driver might be included in the Linux kernel and we could safely update kernels as often as we want to without having to recompile anything else.

I'm a dreamer, ain't I?

[RussianNeuroMancer]

It should be easy to use amdgpu for all radeonsi+ cards and radeon for all the rest but i did not get why there was a new ddx introduced, isn't modesetting the way to go as it already has 2d accelleration via glamor?

Same question here. It would be nice if someone from devteam comment on that

The other way would be: fglrx just drops support for all pre radeonsi cards...

Agree, that quite likely. Last driver branch with pre-Evergreen (TeraScale 1 actually) support was 8.97 (released as Catalyst 12.6 at July 24, and later 13.1 and 13.9 as legacy releases of same 8.97 branch with little fixes) and three weeks later after Catalyst 12.6 release Windows 8 ISO's was pushed to MSDN at Aug 15.
Sooo... well, straight dropping support of all D3D Feature Level 11.0 hardware (pre-GCN / TeraScale 2&3) this summer by Catalyst Team would be expected, and shitstorm about dropping fresh hardware like Trinity/Richland support is expected too, since HP, ASUS, Lenovo, MSI still sell Richland-based laptops (but with current level of open source driver I guess users will have more problems with removing fglrx after Ubuntu upgrade, like "I upgraded Ubuntu and now there is just black screen after reboot, what can I do?" and stuff, than with open source driver itself).