The Slides Announcing The New "AMDGPU" Kernel Driver

[dungeon]

The regular desktop & gaming market (what we call "client") has the lowest share but is also the only one that people seem to care about, unfortunately.

Ah Bridgman, anyone can say whatever he want about those, it can be lowest or highest . Why? No one can count nor measure those, probably because most of them are passive users who just pick up a product and shut up . If you mean by lowest share == lowest response - that is always to be expected for "client" market .

[asdfblah]

I imagine only joining forces and hope for more people will work on the open source code (some only because of blob ).

I said "from radeon user POV", that is someone who was not fglrx user

If I understand correctly, the "new" AMDGPU driver is just a new name for the current Radeon open-source driver, right? Which means, we will still have a complete open-source driver PLUS Catalyst as an option. Catalyst would, in fact, use the kernel parts of Radeon as well as some other parts, while replacing the userspace part.

I think people are confused because of the marketing speak... not everyone follows the development of these drivers, so you should try to clear things up.

Also, hopefully, some day, someone will reverse engineer the firmwares... and we will have a complete Free/Open Source kernel driver

[dungeon]

If I understand correctly, the "new" AMDGPU driver is just a new name for the current Radeon open-source driver, right? Which means, we will still have a complete open-source driver PLUS Catalyst as an option. Catalyst would, in fact, use the kernel parts of Radeon as well as some other parts, while replacing the userspace part.

Yes, but it is not just a rename - those are all separete drivers and for entirely different generations of products . radeon is (name and) old driver for old and only now current devices (you can expect that driver will not get anything major anymore (OK, maybe major OpenGL version and few points here and there ), you can call that maybe longterm kind of support if you wish or whatever...

On the other hand there will be new amdgpu driver for new and not yet released products, that is the driver where will be major development focus in future....

All in all, what most users need to know next year when you got new AMD hardware, you will use amdgpu driver .

[asdfblah]

Yes, but it is not just a rename - those are all separete drivers and for entirely different generations of products . radeon is (name and) old driver for old and only now current devices (you can expect that driver will not get anything major anymore (OK, maybe major OpenGL version and few points here and there ), you can call that maybe longterm kind of support if you wish or whatever...

On the other hand there will be new amdgpu driver for new and not yet released products, that is the driver where will be major development focus in future....

All in all, what most users need to know next year when you got new AMD hardware, you will use amdgpu driver .

I thought the kernel driver was called "Radeon", while the other parts were called radeonsi/r600g/r600? There is also this: http://lists.cs.uiuc.edu/pipermail/l...ly/075151.html
But anyways, I guess understand what I mean. AFAIU, this is basically the continuation of the current work, nothing would change in the open-source side of thing (except that there will be another driver for a new generation of GPUs? I haven't followed the news on this, but IIRC AMD isn't abandoning the GCN arch any time soon). Am I right, AMD devs?
This is really confusing, devs could clarify in a separate blog post or something...

[johnc]

Linux market share varies widely from one market to another. Linux usage in embedded applications is quite high, possibly over 50% depending on who you ask. Tablet/phone share is also quite high assuming you include Android (which is fair IMO). IIRC the next highest is server (historically CPU only although GPU compute is changing that), followed by workstation graphics.

The regular desktop & gaming market (what we call "client") has the lowest share but is also the only one that people seem to care about, unfortunately.

In all of those markets the customer desire for a FOSS GPU driver is practically nil. Not to take away from those who see that as a major benefit (we all make purchases based on different needs), but from a business perspective I don't think it's a strong selling point in the GPU market.

And I'm only mentioning this in the context of the other poster's conviction that you have to have an open-source Linux strategy to sell product.

[bridgman]

In all of those markets the customer desire for a FOSS GPU driver is practically nil. Not to take away from those who see that as a major benefit (we all make purchases based on different needs), but from a business perspective I don't think it's a strong selling point in the GPU market.

And I'm only mentioning this in the context of the other poster's conviction that you have to have an open-source Linux strategy to sell product.

The interesting thing is that maintainability is a huge issue, which implies either open source drivers or proprietary drivers with a source code license. Open source drivers tend to be very attractive because more people are familiar with the code. Agree that open source itself is not a must-have, but the side effects of being open source are very attractive. This was a bit of a surprise, ie we had not considered it when we made the original decision to restart our open source driver efforts.

[Ibidem]

In all of those markets the customer desire for a FOSS GPU driver is practically nil. Not to take away from those who see that as a major benefit (we all make purchases based on different needs), but from a business perspective I don't think it's a strong selling point in the GPU market.

And I'm only mentioning this in the context of the other poster's conviction that you have to have an open-source Linux strategy to sell product.

Embedded, you're definitely wrong.
AMD found a (semi-)open driver to be beneficial enough there to port it to Windows. (http://www.phoronix.com/scan.php?pag...amd_linux_wec7)
Also witness nvidia's contributions to nouveau, which are because one oem insisted on an open source driver.

Android/tablet/phone, there are not really any viable open source driver options for stock systems yet (except the very newest Atoms, which seem to not be widely used in Linux systems.) But the AOSP team was pushing unsuccessfully for open drivers, and the minor phone OSs would greatly benefit from them.
AMD doesn't really have a horse in that race yet though, as far as I can tell; I think their x86 chips are still a little too high power, and their ARM chips are new and strictly for servers. But given that Android's coming to arm64 and is on x86, it doesn't sound like a bad idea to plan for it.

In compute, there are numerous projects based on non-x86 architectures (especially MIPS and POWER, with some ARM).
For some of these, an OSS compute stack might be preferable because the alternative is paying to get source and port it.

[clavko]

Well, it all sound very nice... if and more important when it's done.

But enough talking, AMD. Enough slides, promises, ideas, futures,
roadmaps, etc, etc. You need to actually make it so, not talk. You
are curently a bit low on delivery.

And it's really easy. Your workforce measures in thousands. Thousands!
Your opensource team is, what, 3 guys? Doubling your opensource
efforts requires an investment of 3 paychecks. Granted, those are
high level paychecks, but still. Find the people, hire them, do the walk.
And if you find those guys in India or China, you can get even more
developers at the same price.

Now repeat after mr. Ballmer and me - developers, developers, developers...

[BSDude]

So as I understand, with these changes it could be possible to use the catalyst driver even on BSDs once the kernel driver is ported over?

[oleid]

As explained in the earlier article, the prototyping of the AMDGPU kernel driver was done with Sea Islands hardware and the DRM driver is based on the existing Radeon DRM. The AMDGPU kernel driver is only going to support new, unreleased hardware while the current Radeon driver stack won't be enabled for these future "Pirate Islands" Rx 300 series hardware.

If the new driver was prototyped using Sea Island hardware, why don't they enable (opt-in) support for these in the long run? I could imagine this would make a lot of AMD supporters happy.