AMDGPU-PRO's OpenCL stack crashes the whole system down to its knees on SI

[bridgman]

Darkbasic posted this: https://openbenchmarking.org/result/...or=y&obr_rro=y

There RX460 wins HD7950 in every benchmark.

Ahh, now I understand. I thought the same thing the first couple of times I looked at the charts.

What Darkbasic said though was that the "7950" numbers were believed to be running on CPU, and that the "7950 + Linux 4.13..." numbers were the ones he posted (not the "7550" numbers.

The "7950 + 4.13..." numbers appear to be faster than the 460 in every case.

[darkbasic]

My understanding is that Kaveri and Tahiti have quite different display controllers. Kaveri is CI, not SI.

https://www.x.org/wiki/RadeonFeature/#index7h2

So there is no hope at all to get DP MST before I get rid of that card? This is a pity because it's still a pretty damn modern card in my opinion, probably the one which better faced aging above all the cards I owned, especially considering it is already almost 6 years old and still able to top an OpenCL chart. This would have never been possible if it wasn't for FOSS drivers and it would be a great pity to let SI die without atomic modesetting and DP MST, which would require just the last little bit of efforts.

Ahh, now I understand. I thought the same thing the first couple of times I looked at the charts.

What Darkbasic said though was that the "7950" numbers were believed to be running on CPU, and that the "7950 + Linux 4.13..." numbers were the ones he posted (not the "7550" numbers.

The "7950 + 4.13..." numbers appear to be faster than the 460 in every case.

Exactly, my initial numbers were my CPU results, because apparently some cards need GPU_FORCE_64BIT_PTR=1 to be able to use OpenCL.
Since darktable spits a warning when it cannot operate in OpenCL mode it would be interesting to know if phoronix-test-suite could parse the output, intercept the warning and invalidate the result. I wonder if Michael receives the notifications when someone mentions him.

[bridgman]

So there is no hope at all to get DP MST before I get rid of that card? This is a pity because it's still a pretty damn modern card in my opinion, probably the one which better faced aging above all the cards I owned, especially considering it is already almost 6 years old and still able to top an OpenCL chart. This would have never been possible if it wasn't for FOSS drivers and it would be a great pity to let SI die without atomic modesetting and DP MST, which would require just the last little bit of efforts.

My impression from earlier discussions was that extending DC back to DCE6 wasn't "just a little bit" of effort. It might end up making more sense to port the existing DP MST support from radeon across to amdgpu instead, if that has not already been done.

[Berniyh]

My understanding is that Kaveri and Tahiti have quite different display controllers. Kaveri is CI, not SI.

Yes, Kaveri has been working with amdgpu almost from the beginning on, way before there was support for SI.
I haven't been using radeon since linux 4.4 (January 2016).

I can confirm though that amdgpu-pro opencl + linux 4.13 mainline does not work, it segfaults upon loading.
I think it might be better to wait until hopefully rocm is in a somewhat usable state.

[rdemaria]

Can someone confirm that OpenCL and a recent xorg (from AMDGPU-PRO) works, at the same time, on an AMD 280X (Tahiti XTL) using the experimental support SI support in the opensource AMDGPU driver and this hybrid kernel? Will all this simplify in the future?

[Berniyh]

FTF you have been reading for 10 years, Phoronix,Bridgman and I have written several times that use the following kernel with amdgpu-pro user space software.

https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-mainline-hybrid-4.12

which is a kernel that is EOL …

Sorry, no. Not using custom kernels, that just leads to more problems.