I'm currently configuring a Thinkpad T400 with an ATI RV620 and an Intel GM45.
I noticed that using the default config, with an Intel iGPU desktop while running specific programs with DRI_PRIME, the discrete graphics performance is very low, only slightly better than the Intel graphics. But if I use radeon.runpm=0 and run only the dGPU the performance is much higher.
Glmark2 benchmarks
intel only
255
radeon with dynamic power management enabled (with an intel desktop, running the radeon card on a per-process basis with DRI_PRIME=1)
317 (+24.3% over intel)
radeon.runpm=0 (running only radeon, with no power saving and no intel driver)
495 (+94.11% over intel)
The problem is that runpm=0 results in more heat, current draw, fan noise, etc.
So what is the way to get a decent performance without completely disabling the radeon power management?
Is there a radeon option, or maybe something has to be tweaked on the intel driver side?
Any ideas and suggestions would be welcome.
I've got the same Intel iGPU/AMD dGPU configuration in my laptop and it works fine, I only set the kernel boot parameters to help things a little:
radeon.si_support=0 amdgpu.si_support=1 (this is for SI cards and newer).
Take a look at the PRIME Arch wiki page, it applies verbatim to Artix.
I've read everything I could find on the topic...
Do you get exactly the same performance (in glmark2 for example) by using your dGPU dynamically (with DRI_PRIME) as by loading the full desktop with the dGPU? That's the crux of the matter. In my case, as you could see, the performance is about 56% worse using DRI_PRIME.
You can also compare performance with:
vblank_mode=0 DRI_PRIME=1 glxgears
It occurred to me that maybe the XFCE compositor is to blame, but I wouldn't know what to change to make it more compatible. That's how I found this thread. Someone has the same issue, but using newer hardware.
https://bbs.archlinux.org/viewtopic.php?id=253915
I tried using the following kernel parameters to no avail
amdgpu.ppfeaturemask=0xffffffff
amdgpu.power_dpm_state=performance
radeon.dpm=1
It doesn't make much sense to set amdgpu paramenters since the dGPU uses the radeon driver, but surprisingly (why?) the amdgpu module is loaded automatically too.
More benchmark results now using gputest
Intel
365 FPS
Radeon (PRIME)
423 FPS
Radeon
766 FPS
There's something preventing the dGPU to work to its full potential if it's used alongside the iGPU.
That's also my ad-hoc benchmark, I don't remember the exact numbers but it was something like 12000 fps with PRIME=1/dGPU. I don't use the full desktop on dGPU setup because I don't need it. You must blacklist the radeon module, it shouldn't be loaded.
My point is that a full dGPU desktop would probably perform faster. How much faster, you will only know if you ever try it. In my case it was 56% faster than with PRIME. Maybe this is so because my laptop is old and this kind of integration has evolved... It would be interesting to know what are the results in your case to see if I should stop pursuing it.
If I blacklist or rmmod the radeon module, the dGPU temperature goes UP... So radeon.dpm=1 is a must to keep temps low, since dpm is not loaded by default.
It's unfortunate that nobody knows or cares how to tame a setup like this to make the dGPU give a better performance while loaded dynamically. Otherwise, there's no considerable benefit (only 24% faster) over the iGPU at the expense of some extra 10°C and some system stability. Changing between TTYs and X sometimes results in a hard crash.
My laptop is also aged - around 9-10 years old - and the reason I don't use dGPU for desktop is precisely the raised temperatures (way more than 10°C btw), besides battery drain. Unfortunately, you can't have it all. But I understand your frustration, because at least it should perform well under PRIME. Seems like a buggy implementation from Lenovo.
This doesn't surprise me as it needs to share I/O (chipset/PCI-E/AGP depending on the laptop model and how it's built) resources with eachother, remember that on Windows official proprietary vendor drivers might have some sort of load balancing that optimises stuff with task at hand in realtime. Yes, stuff like this was possible at that time.