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

[Zgembo]

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.

I have this curios case of Lenovo Kaveri APU laptop, where none of the three driver mentioned above are able to fire up built-in eDP display, which is similar to what Michael had with amdgpu on his Kaveri laptops. It's very sad situation, I've been trying a year worth of kernel released radeon & CIK-enabled amdgpu drivers, to no avail. Recently I also tried amdgpu-pro dkms 16.40, and despite it compiling and loading fine, supposedly enabling DAL, it still does not enable my eDP. All three drivers enable external HDMI properly, only thing that seemingly work on the on the built-in laptop display is the backlight, the screen is just black...

The bug was reported like a year and a half ago, see https://bugs.freedesktop.org/show_bug.cgi?id=90320.

But to my utter surprise, fglrx knows how to enable eDP, due to some dark display initialization voodoo magic, likely due to a workaround in its code dedicated to handle some buggy eDP link training or i2c link issues that are known for some LCDdisplays. Naturally, being forced to use fglrx in (what's almost) year 2017 is next to going insane, no new distros would work, gnome refuses to cooperate, console switching would fail, just pure pain and misery.

Now, a question related to all this new and awesome AMD open driver efforts (which I deeply respect); now that we have almost fully featured OpenGL, with all the GPU and accel optimizations coming in, what is the plan with these display init workaround code support that is obviously present in fglrx, but somehow amdgpu is missing it (including amdgpu-pro).

If by any mean this workaround code in fglrx can be made available and back-ported to amdgpu (or even radeon) as a part of DAL or whatever, I'm sure many of us will have much smoother AMD experience, and Linux inclined people may actually want to start buying these APU laptops. To what use it all the fancy 3D when one can not even have a working display...

[Zgembo]

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

. . .

I have this curios case of Lenovo Kaveri APU laptop, where none of the three driver mentioned above are able to fire up built-in eDP display, which is similar to what Michael had with amdgpu on his Kaveri laptops. It's very sad situation, I've been trying a year worth of kernel released radeon & CIK-enabled amdgpu drivers, to no avail. Recently I also tried amdgpu-pro dkms 16.40, and despite it compiling and loading fine, supposedly enabling DAL, it still does not enable my eDP. All three drivers enable external HDMI properly, only thing that seemingly work on the on the built-in laptop display is the backlight, the screen is just black...

The bug was reported like a year and a half ago, see https://bugs.freedesktop.org/show_bug.cgi?id=90320.

But to my utter surprise, fglrx knows how to enable eDP, due to some dark display initialization voodoo magic, likely due to a workaround in its code dedicated to handle some buggy eDP link training or i2c link issues that are known for some LCDdisplays. Naturally, being forced to use fglrx in (what's almost) year 2017 is next to going insane, no new distros would work, gnome refuses to cooperate, console switching would fail, just pure pain and misery.

Now, a question related to all this new and awesome AMD open driver efforts (which I deeply respect); now that we have almost fully featured OpenGL, with all the GPU and accel optimizations coming in, what is the plan with these display init workaround code support that is obviously present in fglrx, but somehow amdgpu is missing it (including amdgpu-pro).

If by any mean this workaround code in fglrx can be made available and back-ported to amdgpu (or even radeon) as a part of DAL or whatever, I'm sure many of us will have much smoother AMD experience, and Linux inclined people may actually want to start buying these APU laptops. To what use it all the fancy 3D when one can not even have a working display...

[bridgman]

OK, can you please give the bug report a bump and include the information you mentioned above ? Key points IMO are:

1. still happening with recent upstream kernels (be specific with latest version tried if you can)

2. also happens with AMDGPU-PRO 16.40 where you believe DAL code is running instead of native display code

3. display works correctly with fglrx (version # and distro used iif you can)

Generally when a bug report sits unchanged for a long time there's a good chance the problem has been fixed by other work, so it helps to update the ticket periodically with test results from <latest version of relevant component>.

The workarounds in fglrx will mostly be in DAL code (albeit an earlier version than DAL3 in the -pro stack) - the DAL team is particularly busy with new HW work for another month or so but hopefully time should start to free up after that.

[Zgembo]

bridgman thanks a bunch for the hints, I've updated the bug ticket.

Hoping DAL team will have a time to look at https://bugs.freedesktop.org/show_bug.cgi?id=90320

Cheers!

[hjahre]

No hardware reason, it's just not implemented.

Do you plan to implement DAL for SI hardware?

I have a R9 270X card, and fully functioning HDMI audio would be nice. As of now my HDMI audio is garbled when I use ALSA and the CPU is idling, e.g. listening to music. Also, there is no streaming of HD audio formats when the screen output differ from 60Hz, e.g. when watching a movie and setting the display refresh rate to 24Hz.

[Zgembo]

We have no problems with kaveri apu (A8-7600). Using Debian testing XFCE

http://cdimage.debian.org/cdimage/stretch_di_alpha8/amd64/iso-cd/

, Oibaf ppa

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/+packages

and a custom kernel from here:

https://cgit.freedesktop.org/~agd5f/linux/log/drivers/gpu/drm/amd?h=drm-next-4.10-wip

Gnome and ubuntu are slow and buggy.

We have no problems with Kaveri APU, we have problems with its drivers who fail to fire up eDP display properly. In particular, radeon, amdgpu as well as amdgpu-pro fail to do so, only fglrx can do it, but it is so lame in the other departments that being forced to use it brings nothing but frustration. Perhaps DAL could save the day. Perhaps...

[bridgman]

DAL on its own won't make a difference - the amdgpu-pro driver is already using it - but the DAL team might remember what was done for the kind of issue you are seeing.

The problem is that a it's often not a case of "we saw that problem and did XYZ to fix it" but rather "we did everything differently and never saw the problem"

[Zgembo]

DAL on its own won't make a difference - the amdgpu-pro driver is already using it - but the DAL team might remember what was done for the kind of issue you are seeing.

The problem is that a it's often not a case of "we saw that problem and did XYZ to fix it" but rather "we did everything differently and never saw the problem"

According to Alex Deucher, DAL is disabled for Kaveri (and I guess for SI as well); https://bugs.freedesktop.org/show_bug.cgi?id=90320#c15

[dungeon]

DAL on its own won't make a difference - the amdgpu-pro driver is already using it - but the DAL team might remember what was done for the kind of issue you are seeing.

The problem is that a it's often not a case of "we saw that problem and did XYZ to fix it" but rather "we did everything differently and never saw the problem"

Congrats on 10K posts, that deserves a medal... article from Michael

[bridgman]

According to Alex Deucher, DAL is disabled for Kaveri (and I guess for SI as well); https://bugs.freedesktop.org/show_bug.cgi?id=90320#c15

Ahh, interesting. I knew DAL did not include SI support, didn't know about Kaveri though...