Don't Expect AMDGPU To Enable SI/CIK Support By Default Anytime Soon

[bridgman]

pixo
amdgpu-pro is a userspace proprietary non-open source binary driver that depends on amdgpu.
amdgpu is a new open source driver

https://wiki.archlinux.org/index.php/AMDGPU

That wiki is a bit ambiguous... the kernel driver for amdgpu-pro is open source but not everything in it is upstream yet. It's important to distinguish the two.

[bridgman]

Also, I'm only okay with AMD dropping official driver support for my card when it gets to be like 5+ years old. 290x is not old enough for them to be telling me I'm at the mercy of the community.

What do you mean by "at the mercy of the community" ? Most of the developers working on the open source drivers are AMD employees, and we have been shifting developers from closed-source to open source for a couple of years now and building up the open source team for longer than that.

Not sure what happened to make people suddenly start thinking that "only blobs are official"... for years people have been asking for us to focus on the open source driver for consumer users and we have been doing just that. The only things that changed recently are (a) Vulkan came along and in the short term we had to support that via a blob, and (b) we got agreement to work on open sourcing our own OpenCL implementation rather than pushing ahead with CLover.

Last question - you talked about "blaming the users" although I can't find the post now - what did you mean by that ? I don't think we have ever said anything that could be twisted into a statement like that.

Thanks..

[bridgman]

He's not authorized to speak for his employer. Take it from his position and if you want the answer to this you have to go to the source who oversees all the GPU division.

Huh ? User spstarr asked why there was no plan, I said that the plan was the same one we have talked about multiple times - finish developing amdgpu (workstation features, resolve regressions relative to radeon) and then switch. Maybe spstarr meant "schedule" instead of "plan" ?

[bridgman]

I mean to me the latter sounds way better but that begs the question - why are they bothering with a consumer facing AMDGPU anything that isn't like hardware locked to -PRO/firepro/etc cards? They should dump all those resources into boosting the OSS as much as possible.

That's what we are doing (although locking to FirePRO hardware would be a Bad Thing until we have Vulkan & OpenCL open sourced) but it sure seems to be unpopular today.

[bridgman]

I would like to know if I understand the situation correctly.
We have 3 OSS kernel drivers:
- radeon - which is mature and mostly in bugfixing and maintenance mode
- amdgpu-pro - which is the driver AMD is working on
- amdgpu - which is stripped amdgpu-pro driver that dont have DAL, DKMS and IOCTL used only by Crimson userspace
There may be more code differences between amdgpu-pro and amdgpu but from what i read OSS userspace is compatible with both.

If this is correct AMD is not adding SI/CIK support to amdgpu but backporting that code from amdgpu-pro.
And they probably need SI/CIK support for their FirePro cards as they are not creating new FGRLX builds for newer RHEL and Ubuntu LTS.

What i want to see than is the amdgpu-pro kernel driver to be provided separately of the Crimson package so i can easily download it and build it.
This should be done until the DAL functionality is in amdgpu.

Probably more correct to say:

- radeon - which is the driver AMD is working on for currently supported HW
- amdgpu - which is the driver AMD is working on for new HW
- amdgpu-pro - which is amdgpu with a couple of extensions for workstation & blob support (the latter will go away as blobs get open sourced) plus Kernel Compatibility Layer code which basically encapsulates the effort required for backporting to older/newer kernel versions

(KCL-type functionality is not allowed up stream, or it would be in amdgpu as well)

Separately we are working on improving SI and CI support in amdgpu so that it can replace radeon for those HW generations. This is primarily driven by a desire to replace fglrx with amdgpu-pro as the ongoing workstation driver for SI- and CI- FirePro hardware, but also benefits open source stack users by enabling access to Vulkan and (currently) closed source OpenGL.

CIK support was always in amdgpu - we did initial development on CIK before VI hardware was available. Nothing gets backported from amdgpu-pro to amdgpu other than the occasional bug fix that gets made while a developer is working on something workstation- or blob-related.

SI support was ported forward from radeon.

We publish our internal amdgpu development trees (which include DAL) on agd5f's repo as amd-staging-N.N, latest is amd-staging-4.7 AFAIK.

[bridgman]

Giving up for now. Some posts are unapproved, others simply disappear, one or two made it through.

EDIT - yeah, that one made it through. Figures

[dungeon]

Giving up for now. Some posts are unapproved, others simply disappear, one or two made it through.

EDIT - yeah, that one made it through. Figures

Problem is probably too many posts you want a row during short period of time... remember that bot bombs works similarly

[agd5f]

Will HDMI audio come through DAL for SI and CI as well?
I assumed they would just port the old code eventually.

DAL supports CI, but not SI.

[Holograph]

What do you mean by "at the mercy of the community" ? Most of the developers working on the open source drivers are AMD employees, and we have been shifting developers from closed-source to open source for a couple of years now and building up the open source team for longer than that.

Not sure what happened to make people suddenly start thinking that "only blobs are official"... for years people have been asking for us to focus on the open source driver for consumer users and we have been doing just that. The only things that changed recently are (a) Vulkan came along and in the short term we had to support that via a blob, and (b) we got agreement to work on open sourcing our own OpenCL implementation rather than pushing ahead with CLover.

Last question - you talked about "blaming the users" although I can't find the post now - what did you mean by that ? I don't think we have ever said anything that could be twisted into a statement like that.

Thanks..

At the mercy of the community meaning the reduced pace that drivers like Radeon and such seem to move at... I mentioned this before but Michael had talked a lot about a Radeon 290 performance regression for months and months with the Radeon driver that didn't happen with AMDGPU... yet AMDGPU has been a pain to use. I compile my own kernels but I don't like being forced to do so, and I also help several friends out with Linux and they, like most people, can't and won't become interested in compiling a kernel. We've had quite a few kernel releases with CIK support being disabled by default and I just cannot come to respect that decision. I feel like your company is just purposely delaying proper support until the hardware becomes old enough that you no longer have to care. Now, this may not be the case, but from the customer's viewpoint, that's how it'll be seen. We pay your company good money for a GPU and we expect quality drivers from that, and not just in Windows.

[Holograph]

Giving up for now. Some posts are unapproved, others simply disappear, one or two made it through.

EDIT - yeah, that one made it through. Figures

I also just somehow lost a post... Friggin awesome. Gotta love forum software that doesn't value the time we put into our posts!