The Slides Announcing The New "AMDGPU" Kernel Driver

[dungeon]

It means more people working on the open source code, at least on the parts used by both stacks.

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

Don't understand where you get "unified driver infrastructure around blobs" given that all of the common code is open source. Less blobs, not more.

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

[bridgman]

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

When you pay people you get to tell them what to work on, you don't have to hope

Understand about radeon user POV, but there are no more blobs from that POV and everything is organized around open source not closed. Still don't understand where "organized around blobs" comes from.

[dungeon]

When you pay people you get to tell them what to work on, you don't have to hope

True is always where money is

Understand about radeon user POV, but there are no more blobs from that POV and everything is organized around open source not closed.

Well, there are no more blobs for radeon, there are no more blobs for flgrx both true... but together in amdgpu driver and from radeon user POV there *are* more blobs on easy access ;D

Still don't understand where "organized around blobs" comes from.

Believe it or not - kernel blobs, userspace blobs and opensource strategy - they came from AMD

[Awesomeness]

Hmm i can't see anything for OSS fans to be happy about, that already does not exists Roughly speaking as primarly radeon driver user POV , amdgpu driver story looks like to me something like - unified driver infrastructure around blobs... so if i try to imagine that driver - there are nothing, but more blobs . I can only hope there be something more opensource in future, but that is about it.

The Linux kernel devs do no accept features that are only used by proprietary userspace driver components. It appears that AMD knows that and as such they know they have to develop an open driver as well.

Considering that this new architecture won't make Catalyst's OpenGL any less buggy, I don't see myself using Catalyst OpenGL on top of amdgpu.

[Awesomeness]

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.

?????? only new????

I'm sorry but amd no more, I'm waiting for a good driver for my apu a8 5600k, I have problems with opensource drivers and sound https://www.libreoffice.org/bugzilla...g.cgi?id=76837

and the catalyst driver is a mess. NO MORE AMD

Considering that amdgpu is based on the current radeon driver, I expect that either the older drivers to be ported to it as well, should it be feasible, or backports of fixes.

[Staffan]

Sounds great to me! Essentially, they want to utilize the wheels already present in the graphics stack/kernel instead of inventing their own and then just package their unique selling points into small closed components. That is exactly what you should do, cooperate with the other kernel developers to have them to basically work for you.

[Asariati]

I'm going to go out on a limb and say that the Linux FOSS market probably accounts for 0.000001% of GPU sales.

Even when we take the Steam-usage numbers as a number to calculate the total market, I don't think it adds up business-wise or seems logical for any other reason.

I am not saying I am not thrilled for the OSS-community. Quite the opposite.

[DrYak]

Considering that amdgpu is based on the current radeon driver, I expect that either the older drivers to be ported to it as well, should it be feasible, or backports of fixes.

Mesa running on top of amdgpu instead of radeonsi (or even r600 ?): could be doable, depends on how much resources are available (mostly developers in the opensource community).
Might be useful to reduce the amount of code that needs to be shared and maintained between backends. (Depending on how much the future R300 GPUs supported by amdgpu share with the GPUs supported by radeonsi).

Catalyst for older cards running on top of amdgpu instead of fglrx ? not a chance.
- Very likely AMD doesn't have enough developers on their payroll available to port the older catalysts to the new kernel driver.
- Very likely the AMD stance will be use amdgpu/catalyst_new for recent cards...
- ...fglrx/catalyst_old for older cards
- and switch to opensource as the official supported version, once support is dropped out of catalyst (as done currently with the older non-unified shader r300 series, or for the few more recent (like HD 2x00/3x00/4x00) which are supported by r600 but aren't supported by catalyst anymore.

And again, the best part of this is:
- amdgpu will get developed at time corresponding cards will get designed (amdgpu support for R300 is going to happen over the next months, not later in 2015, long after the cards are in shops)
- amd might throw a bit resources for some features that might be useful for their drivers, but which haven't been supported in opensource drivers yet (lay more ground work for cross-fire in a future version of AMDGPU ?)

[bridgman]

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.

[Asariati]

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.

So AMD is doing this to position themselves better in the markets with Linux market share and then grow there? Does "embedded applications" include PS4/XBone or is that "client"?