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

[blackout23]

So you are actually implying I did not have to patch the nvidia drivers myself for a new kernel? That all those compiler errors were just imagination?
Fglrx doesn't need any patches in the future, userspace drivers can test for the current ABI and decide which userspace to use... Nvidia will be lagging.

Using latest driver with Linux 3.17 here without problems. Very rarely Arch Linux had to ship a patch in their nvidia package. nvidia driver never blocked releasing a new kernel or xorg-server as opposed to catalyst.

[Ardje]

fglrx, yes. nvidia, no.

So you are actually implying I did not have to patch the nvidia drivers myself for a new kernel? That all those compiler errors were just imagination?
Fglrx doesn't need any patches in the future, userspace drivers can test for the current ABI and decide which userspace to use... Nvidia will be lagging.

[sbolokanov]

Xonotic

Thanks!

[Michael]

Slides: http://www.phoronix.com/scan.php?pag...tem&px=MTgwODA

[Michael]

What's the game on the second photo??
Does anybody know?

Xonotic

[sbolokanov]

What's the game on the second photo??
Does anybody know?

[blackout23]

The current nvidia and fglrx drivers both have the obnoxious problem that their proprietary kernel modules are usually lagging.

fglrx, yes. nvidia, no.
Even if you work on implementing driver support and new features in the kernel well in advance most users will only get them after years, because distro policies. Even rolling distros have to wait for new kernel releases to get new features.
Looks like Windows has Linux beat in this regard. You just grab whatever driver you want and install it or remove it. Doesn't matter how new or old your Windows is. Nothing is split in two parts where you have to wait for release of the 3D Blob part from one company and a new release of the NT kernel for other features. No need to have a compiler toolchain and kernel headers on your system as with DKMS.

[schmidtbag]

@CrystalGamma
Thanks for clearing things up for me. I'm a little worried about what will happen with the older devices - at this point I have a feeling I will never be able to crossfire my HD 5750s in linux. I can try doing it now in catalyst but there's no way to force-enable it anymore. I don't necessarily blame AMD for the way they decided to approach this - I feel more comfortable with them starting from scratch (though technically it isn't starting from scratch). Just a bit disappointing I might be left out of features I want/need. But, when the Windows drivers drop support for my GPUs, that's when I think I might need to do a full system upgrade.

@AMBoTuLoX
Your logic makes no sense at all. You don't want to buy something new that is AMD based because they're dropping support for something old?

[drSeehas]

... this might also open up the way to Catalyst on BSD.

Very important, as on the BSDs you currently don't have a choice.

AMD's Pirate Islands graphics cards are rolling out in 2015 to succeed the Southern/Sea/Volcanic Islands.

So Tonga/R9 285 will be the only Volcanic Islands ASIC? Maybe Carrizo?

[Ardje]

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 actually mean to say that this model is very flexible, as you do not have to patch your nvidia kernel proprietary license wrapper code to match new kernel API's, since the API is already defined, and there is no proprietary code in the kernel anymore.
The current nvidia and fglrx drivers both have the obnoxious problem that their proprietary kernel modules are usually lagging.
It usually is up to the distro's to fix those drivers.
With the new model there is no proprietary code, so distro's that want to give the users the latest and best experiences do not have to wait on AMD anymore. They just have to wait on NVIDIA.
Containing your proprietary part in usersspace is the best solution ever.