RadeonSI Compute Shader Patches Revised

[bridgman]

You mean that radeon pro hybrid driver, right?

Correct (amdgpu not radeon though) - amdgpu open source stack plus Catalyst OpenGL/OpenCL plus Vulkan

It was already stated (by yourself, if I'm not mistaken) that Catalyst will never get xorg 1.18 support. This means that in a few months no supported linux distribution will exist that can run Catalyst. Eventually even Debian and the likes will upgrade xorg. Basically Catalyst (fglrx) is dead.

To be precise, we said that we are not currently planning to support 1.8 with Linux Catalyst, focusing on the amdgpu hybrid driver instead. If, for example, we ran into problems with supporting SI on amdgpu hybrid then we might end up extending Linux Catalyst after all, but at the moment we want to switch all the GCN parts to amdgpu hybrid.

[bridgman]

This: https://www.phoronix.com/forums/foru...-i-report-this

Does it sound like the following ? That's the flickering issue I mentioned that was solved by reverting a quirk:

https://bugzilla.kernel.org/show_bug.cgi?id=103271

If you boot with radeon.dpm=0 does the flickering stop ?

[Amarildo]

Does it sound like the following ? That's the flickering issue I mentioned that was solved by reverting a quirk:

https://bugzilla.kernel.org/show_bug.cgi?id=103271

If you boot with radeon.dpm=0 does the flickering stop ?

You have got to be kidding me Hehehehe.

Yes, that was it.

LABEL arch
    MENU LABEL Arch Linux
    LINUX ../vmlinuz-linux-grsec
    APPEND root=/dev/mapper/system-root cryptdevice=/dev/sda2:root radeon.dpm=0 rw
    INITRD ../initramfs-linux-grsec.img

Thank you very much once again You've proven to be very valuable to this forum.

Do you happen to know why the flickering occurs on lower power modes, and if that is every going to be fixed?

[Amarildo]

Arch linux user that does not play with kernel parameters when having problems, weird.

It's not weird considering I only had one kernel problem in +3 years of using Arch, and the problem was specific to an area in which I could easily identify and do some research (cryptsetup or LVM, I don't remember).

But in this case, I not only didn't have time to look for the problem more deeply, I wasn't sure where the problem was. Then there is med school, work, and every little thing that prevented me to even begin thinking this was a little problem fixable with a Kernel parameter. And of all the hundreds of people who saw my threads on different forums (Arch's forums included, BTW), none said anything about Kernel parameters, so I didn't bother to check up. For all I knew, this was a problem with Xorg's modesetting.

I'm now very pleased with Radeon and I'm not looking back at Catalyst. The only BIG thing left is AMD to properly implement OpenCL 2.0 into Radeon.

[nanonyme]

The primary reason for keeping the Catalyst GL driver is support for compatibility profiles - there are no plans to ever add that to Mesa.

That (no compatibility profile support in Mesa) is a good decision IMO, but not all market segments agree with me yet

Don't give up trying to convince them though

[haagch]

Bas Nieuwenhuizen today published V2 of his RadeonSI Compute Shader patches.

Oh, that's why they didn't apply on top of the old patches - they replace them. The missing "cover letter" made this confusing.

Convenient "download mbox":

https://patchwork.freedesktop.org/series/5688/

Finally patches that apply nicely to git master.

And Alien Isolation now works for me too! Aww yiss.

Edit: Mostly, sometimes there is some colorful flickering left, but it seems to mostly work fine. As usual, performance is not really playable though, while the GPU usage hardly ever touches 50% on any graphics setting. https://youtu.be/T9eAcYthPOc. Still crashing with default CFLAGS.

Edit2: Shadow of Mordor works now correctly though with the rain and everything. As usual, performance is far below playable. Low settings, GPU usage ~40% when not looking at the sky: https://youtu.be/y_WJBJZ1fLI High settings, GPU usage is slightly better: https://youtu.be/w7KqGdN7YYY

[Adarion]

Kinda off-topic; this looks insteresting, to say the least: https://lists.freedesktop.org/archiv...il/112385.html

Thanks for the hint. Indeed. That does sound promising. I guess esp. on a smaller APU this is also noteable outside benchmarks, and palpable for the user.

[brent]

Thanks for the hint. Indeed. That does sound promising. I guess esp. on a smaller APU this is also noteable outside benchmarks, and palpable for the user.

It definitely helps a great deal on my old E-350 netbook that has a small, fixed VRAM allocation (256 MB). Standard desktop compositing stuff is quite a bit more snappy. It used to slow down noticeably after a while, that seems to be gone now.

[rastersoft]

Am I the only one to have troubles when visiting mesamatrix.net? It says Bad Gateway... (and forces me to use https)

[bridgman]

Do you happen to know why the flickering occurs on lower power modes, and if that is every going to be fixed?

AFAIK it's because of that quirk commit (at least on other users' hardware) - revert it and the problem goes away. The problem is that the commit was probably added to solve worse problems on someone *else's* board so just reverting it upstream is probably not a good fix.

Let's double-check something first though - do your PCI IDs match the quirk (device ID 0x6810, subsystem vendor ID 0x174b "PC Partner", subsystem device ID 0xe271) ?

Running lspci -nn will give vendor/device info while lspci -vmm will give the subsystem vendor/device info, not sure if there is an easier way.