There's Not Yet A Catalyst 15.4 Beta For Linux

[username4983]

Note that AMD has been clear from the start that the R9 285 and upcoming Rx 300 generation will continue to be using the old fglrx stack.

The plan is for them to do behind the scenes testing on that generation to get the AMDGPU kernel working, but users will still be using the old fglrx driver only. The switch for users will occur with the Rx 400 series (assuming it works out well).

No, that has not been clear. That isn't what phoronix has been saying and I vaguely remember AMD directly saying that AMDGPU would be THE driver for 285 and newer. Could we get some confirmation that users should not expect anything from AMDGPU until the 400 series? With 300 not even out yet and it taking years to go from one generation the the next, it seems premature for users to even consider the 400 series.

[bridgman]

The statement about amdgpu being THE driver for R9 285 (Tonga) and newer was in the context of radeon vs amdgpu kernel drivers, nothing to do with Catalyst.

The amdgpu kernel driver will be the upstream driver for Tonga, Carrizo, and all GPUs using a VI gfx core (which I think we are calling GCN3 publicly), while the radeon kernel driver will continue to be the upstream driver for Kaveri, Bonaire, Hawaii and all older parts.

The transition from current Catalyst to an amdgpu-based "hybrid stack" (closed userspace over amdgpu kernel driver) will be slower and will have a lot of overlap. The only place we can't overlap is upstream, so we had to make a sharp cutover there.

[bridgman]

Stupid edit limit.

The amdgpu "hybrid stack" will be supporting VI parts (what you're calling 300 series) as well as future HW generations, no plans to wait until the next HW generation, but launch time support will generally still be with Catalyst for 2015 since that work had to be done almost a year ago.

[nanonyme]

The statement about amdgpu being THE driver for R9 285 (Tonga) and newer was in the context of radeon vs amdgpu kernel drivers, nothing to do with Catalyst.

The amdgpu kernel driver will be the upstream driver for Tonga, Carrizo, and all GPUs using a VI gfx core (which I think we are calling GCN3 publicly), while the radeon kernel driver will continue to be the upstream driver for Kaveri, Bonaire, Hawaii and all older parts.

The transition from current Catalyst to an amdgpu-based "hybrid stack" (closed userspace over amdgpu kernel driver) will be slower and will have a lot of overlap. The only place we can't overlap is upstream, so we had to make a sharp cutover there.

Hmm, how come? Isn't the hybrid stack's proprietary part development primarily throttled by how many developers AMD can afford to throw at coding and with IP review not really being a thing?

[bridgman]

Hmm, how come? Isn't the hybrid stack's proprietary part development primarily throttled by how many developers AMD can afford to throw at coding and with IP review not really being a thing?

To a large extent the proprietary part already exists, it just needs to run over new IOCTLs (basically the same work we did for the open source userspace stack). The amdgpu effort is primarily a kernel & X driver project using existing code for the other parts, and that applies to both open and closed stacks.

In order to provide launch-time support for parts shipping this year the code had to be written a year or so ago, before the amdgpu stack even existed, so support was added to Catalyst. Development pipelines are long.

[nanonyme]

To a large extent the proprietary part already exists, it just needs to run over new IOCTLs (basically the same work we did for the open source userspace stack). The amdgpu effort is primarily a kernel & X driver project using existing code for the other parts, and that applies to both open and closed stacks.

In order to provide launch-time support for parts shipping this year the code had to be written a year or so ago, before the amdgpu stack even existed, so support was added to Catalyst. Development pipelines are long.

Well, right, but we were still expecting amdgpu would be The Driver and Catalyst to go away long-term. It sounds pretty bad if you guys feel you need something out-of-tree to push available-on-hardware-release drivers if this doesn't turn out to be a passing phase. Then again, drm drivers did use to live outside kernel tree at a point, current delivery setup is mostly the path of least maintenance. You could also make amdgpu compilable against various kernel versions and hence easily backportable

[bridgman]

Well, right, but we were still expecting amdgpu would be The Driver and Catalyst to go away long-term. It sounds pretty bad if you guys feel you need something out-of-tree to push available-on-hardware-release drivers if this doesn't turn out to be a passing phase.

Huh ? I don't see any connection between what I typed and "if this doesn't turn out to be a passing phase". I said "the code for this year's parts had to be written before we had an amdgpu driver", right ?

Then again, drm drivers did use to live outside kernel tree at a point, current delivery setup is mostly the path of least maintenance. You could also make amdgpu compilable against various kernel versions and hence easily backportable

Actually no. Including code for different kernel versions in the upstream tree is generally not allowed. That's one of the advantages out-of-tree drivers have which upstream drivers do not. With Catalyst we had the Kernel Compatibility Layer to help abstract across kernel versions.

With amdgpu I believe backporting will have to be done "the old fashioned way" unless we can figure out an acceptable way to abstract kernel versions.

[smitty3268]

No, that has not been clear. That isn't what phoronix has been saying and I vaguely remember AMD directly saying that AMDGPU would be THE driver for 285 and newer. Could we get some confirmation that users should not expect anything from AMDGPU until the 400 series? With 300 not even out yet and it taking years to go from one generation the the next, it seems premature for users to even consider the 400 series.

amdgpu will be used by 285 and newer for the open source drivers.

It will not be used by fglrx, not until the next 400 series generation.

AMD has been clear about this, Michael and phoronix have not. That's why i posted it.

[mao_dze_dun]

Once again AMD's middle finger proudly sticks in the face of its customers. You know they don't give a damn when there hasn't been an a stable driver release since December. And why should they - obviously the new strategy is throw all the older generation cards under the bus. Good thing I'm mostly doing gaming in Windows or the 290x I got myself for Christmas would really sting. Then again there hasn't been a stable driver release for Windows as well since... you guessed it - December. But you know - it's an "old" card. However, AMD, please explain to all customers who got the relatively "new" 8GB version of 290x, why exactly it will not be supported by the upcoming amdgpu kernel (at least by the official driver). It's like - why even bother to hope when Nvidia sells its most popular gaming cards with half a gig of slow VRAM and AMD just cuts off all current users from proper driver support in the future. A part of me secretly hopes Intel would just drive both companies out of business so at least then I'll get screwed by a company whose entire attitude is "We're Intel - f*ck you", anyway, and not make lame excuses why they do things.