Linux 4.18 AMDGPU Tests: Vega Taking A Hit

[phoronix]

Phoronix: Linux 4.18 AMDGPU Tests: Vega Taking A Hit

Being roughly mid-way through the Linux 4.18 kernel development cycle, I spent some time this weekend running benchmarks of the AMDGPU DRM driver on Linux 4.18 Git compared to Linux 4.17 stable on three different Radeon graphics cards while using the Mesa 18.1.3 based drivers.

http://www.phoronix.com/vr.php?view=26554

[shmerl]

DisplayPort wasn't working for me

KDE Plasma Wayland session is segfaulting for me on startup when DisplayPort is used (Vega 56). Is it a bug in amdgpu?

[R41N3R]

KDE Plasma Wayland session is segfaulting for me on startup when DisplayPort is used (Vega 56). Is it a bug in amdgpu?

Is this in kernel 4.18-git? My RX480 works well on Plasma Wayland with Linux 4.17.3, except if the monitor goes to sleep or if I turn off the scree and on again, then amdgpu crashes Qt and Kwin.

[shmerl]

Is this in kernel 4.18-git? My RX480 works well on Plasma Wayland with Linux 4.17.3, except if the monitor goes to sleep or if I turn off the scree and on again, then amdgpu crashes Qt and Kwin.

No, it's 4.17.3. Are you using DisplayPort connection as well? That's what I see in dmesg:

[  176.359816] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:956
[  176.814144] QThread[2620]: segfault at f ip 00007f30f30b0e60 sp 00007f30e506e4f0 error 4 in libwayland-client.so.0.3.0[7f30f30a9000+d000]

[ssorgatem]

Displayport doesn't work for me at all on Vega 56 + linux 4.18 git.

Which is unfortunate because my monitor has no HDMI input, so I rely on DisplayPort.

[shmerl]

I wonder how such kind of regressions even happen. Don't developers test DP commonly? Sounds like something that should be caught by regression tests.

[jrch2k8]

I wonder how such kind of regressions even happen. Don't developers test DP commonly? Sounds like something that should be caught by regression tests.

in such a massively complicated thing as an GPU driver there is no such thing as "regression tests" to start with and we have to wait until someone backtrace the commit that started the problem to see if actually is on the DP relevant code or is coming from the hardware due to an unrelated commit(happens a looooooooot)

[shmerl]

in such a massively complicated thing as an GPU driver there is no such thing as "regression tests" to start with

How is that? It should be possible to automate such testing, as long as developers have access to hardware.

[bridgman]

How is that? It should be possible to automate such testing, as long as developers have access to hardware.

Display testing is actually one of the hardest areas to automate because you either need custom hardware analyzing signals or a custom rig with a camera looking at the display and figuring if the viewed image is "sufficiently close" in all the noise & pixel mismatch.

For the former you need a database of what each display vendor/model considers acceptable (which doesn't exist AFAIK, and "industry standards" don't cut it); with the latter you need a lot of displays and a lot of cameras. In the end it comes back to humans with a lot of displays (and a lot of desk space, which is hard to find in these enlightened times) .

[agd5f]

If you see a regression, please report it (https://bugs.freedesktop.org). We can't always reproduce all issues due to differences in software (different sw stack combinations), monitors, specific board/platform configurations, timing differences, etc.