Dear Maintainer, I have a Lenovo laptop with hybrid AMD/Intel graphics cards. I would like to use the discrete Radeon card for heavy rendering operations such as game development and gaming. Output of xrandr --listproviders: Provider 0: id: 0x76 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 4 associated providers: 1 name:Intel Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 1 name:radeon But I get lower fps when I run games with discrete GPU: xrandr --setprovideroffloadsink radeon Intel env DRI_PRIME=1 <game> <- results in barely 20 fps for Dota 2 than if I run them with integrated Intel's card: env DRI_PRIME=0 <game> <- results in 50-60 fps for Dota 2 The output of DRI_PRIME=0 glxinfo | grep 'OpenGL renderer' is: OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile and the ouput of DRI_PRIME=1 glxinfo | grep 'OpenGL renderer' is: OpenGL renderer string: Gallium 0.4 on AMD HAINAN From dmesg I can see this error occuring after starting the game with DRI_PRIME=1 flag set: [ 1406.107887] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 1406.107892] [drm] PCIE gen 2 link speeds already enabled [ 1406.110997] [drm] PCIE GART of 1024M enabled (table at 0x0000000000040000). [ 1406.111090] radeon 0000:0a:00.0: WB enabled [ 1406.111093] radeon 0000:0a:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0xffff88009ae5bc00 [ 1406.111094] radeon 0000:0a:00.0: fence driver on ring 1 use gpu addr 0x0000000080000c04 and cpu addr 0xffff88009ae5bc04 [ 1406.111096] radeon 0000:0a:00.0: fence driver on ring 2 use gpu addr 0x0000000080000c08 and cpu addr 0xffff88009ae5bc08 [ 1406.111097] radeon 0000:0a:00.0: fence driver on ring 3 use gpu addr 0x0000000080000c0c and cpu addr 0xffff88009ae5bc0c [ 1406.111098] radeon 0000:0a:00.0: fence driver on ring 4 use gpu addr 0x0000000080000c10 and cpu addr 0xffff88009ae5bc10 [ 1406.305207] [drm] ring test on 0 succeeded in 1 usecs [ 1406.305213] [drm] ring test on 1 succeeded in 1 usecs [ 1406.305218] [drm] ring test on 2 succeeded in 1 usecs [ 1406.305226] [drm] ring test on 3 succeeded in 4 usecs [ 1406.305233] [drm] ring test on 4 succeeded in 4 usecs [ 1406.305294] [drm] ib test on ring 0 succeeded in 0 usecs [ 1406.305347] [drm] ib test on ring 1 succeeded in 0 usecs [ 1406.305399] [drm] ib test on ring 2 succeeded in 0 usecs [ 1406.305412] [drm] ib test on ring 3 succeeded in 0 usecs [ 1406.305424] [drm] ib test on ring 4 succeeded in 0 usecs [ 1406.305677] [drm:si_dpm_set_power_state] *ERROR* si_upload_sw_state failed I know the GPU is being used because the vgaswitcheroo shows it as DynPwr when I run apps with it. What I would expect to see is performance AT LEAST as good as integrated GPU, instead I get a very bad performance. The poor perfomance is also observable when I run Unity 3D editor (with DRI_PRIME=1) in terms of screen tearing and system freezing. I also tried running the game with vblank_mode=0 option but it had no effect on performance. The scenario is similar with any app I run with DRI_PRIME=1 and it's mostly noticeable with screen tearing. Kernel version: Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux I have searched tons of forum threads and websites and I couldn't find a solution (there were some similar open and unresolved threads but nothing useful), so I turn to you for some hardcore professional help. Is there anything I can try to fix this? Oh, I also tried using LXDE desktop but it made no difference, the problems were the same. Let me know if you need other logs and outputs in order to figure this thing out. I am more than happy to help. Thank you in advance, Marko. P.S. Forgive me if I've post this to the wrong package thread but it definitely has something to do with DRI/radeon/xserver package(s).
Here are some messages that system spits out after running google chrome with discrete GPU. GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, OpenGL renderer string: Gallium 0.4 on AMD HAINAN [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", [23858:23858:0402/002423:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine", Gtk-Message: Failed to load module "canberra-gtk-module" [23858:23889:0402/002423:ERROR:nss_util.cc(839)] After loading Root Certs, loaded==false: NSS error code: -8018 [23916:23916:0402/002423:ERROR:sandbox_linux.cc(334)] InitializeSandbox() called with multiple threads in process gpu-process [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED Vector smash protection is enabled. [23858:23889:0402/100448:ERROR:connection_factory_impl.cc(367)] Failed to connect to MCS endpoint with error -106 [23858:23889:0402/100455:ERROR:connection_factory_impl.cc(367)] Failed to connect to MCS endpoint with error -137 [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED Vector smash protection is enabled. couldn't lock 16384 bytes of memory (secret_session): Cannot allocate memory [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED Vector smash protection is enabled. [2046:2066:0402/121635:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2066:0402/121635:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2066:0402/121635:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2067:0402/121637:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121643:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121643:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121645:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121646:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121646:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121650:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121651:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121656:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2066:0402/121657:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2066:0402/121657:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2067:0402/121702:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2067:0402/121702:ERROR:sctpdataengine.cc(987)] SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1280 vs max of 1200 even after adding 76 extra SCTP overhead [2046:2066:0402/121703:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2066:0402/121718:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2066:0402/121738:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2066:0402/121747:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2066:0402/121753:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [2046:2066:0402/122017:ERROR:webrtcsession.cc(1446)] ConnectDataChannel called when data_channel_ is NULL. [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED Vector smash protection is enabled. [23858:23889:0402/135348:ERROR:connection_factory_impl.cc(367)] Failed to connect to MCS endpoint with error -106 [23858:23889:0402/212205:ERROR:connection_factory_impl.cc(367)] Failed to connect to MCS endpoint with error -137 [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED Vector smash protection is enabled. [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED Vector smash protection is enabled. [23858:23889:0403/013115:ERROR:connection_factory_impl.cc(367)] Failed to connect to MCS endpoint with error -106 [23858:23988:0403/013512:ERROR:get_updates_processor.cc(250)] PostClientToServerMessage() failed during GetUpdates [23858:23988:0403/013515:ERROR:get_updates_processor.cc(250)] PostClientToServerMessage() failed during GetUpdates [23858:23889:0403/013517:ERROR:connection_factory_impl.cc(367)] Failed to connect to MCS endpoint with error -137 [23858:23988:0403/013518:ERROR:get_updates_processor.cc(250)] PostClientToServerMessage() failed during GetUpdates [23916:23916:0403/030913:ERROR:sync_control_vsync_provider.cc(63)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0. [23858:23889:0403/030913:ERROR:connection_factory_impl.cc(367)] Failed to connect to MCS endpoint with error -106 [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED Vector smash protection is enabled.
Please attach your full dmesg output. Does setting radeon.runpm=0 on the kernel command line in grub help?
Created attachment 122701 [details] dmesg output
I haven't tried turning off dynamic power management during boot time. Just in case I edit that line, does that mean that I would have to start DPM manually if I want to use discrete GPU? Thanks for replying btw.
(In reply to Marko Tikvic from comment #4) > I haven't tried turning off dynamic power management during boot time. Just > in case I edit that line, does that mean that I would have to start DPM > manually if I want to use discrete GPU? dynpm != dpm. dynpm controls whether the dGPU is powered down when not in use or not. dpm dynamically adjusts the clocks on the GPU based on load.
I see. Thanks for clarifying that. I'll edit grub now and report the status.
I added radeon.runpm=0 line to the /etc/default/grub and after running update-grub (as sudo) I got this error /usr/sbin/grub-mkconfig: 35: /etc/default/grub: radeon.runpm=0: not found
Created attachment 122702 [details] dmesg output (2)
I've added GRUB_CMDLINE_LINUX_DEFAULT="radeon.runpm=0" to the grub. You can still see the error in dmesg output (dmesg_2) after reboot.
The "[drm:si_dpm_set_power_state] *ERROR* si_upload_sw_state failed" error is visible with both radeon.runpm=0 and radeon.runpm=1. There is no difference in performance (screen tearing and window corruption is the same in both cases).
Error/behaviour is still present at: Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GN U/Linux
I am also facing a similar issue. I also get very low performance when using the DIS Card and the radeon driver in comparison with the IGD Intel card. # vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. ATTENTION: default value of option vblank_mode overridden by environment. 35719 frames in 5.0 seconds = 7143.730 FPS 35715 frames in 5.0 seconds = 7142.853 FPS 34593 frames in 5.0 seconds = 6910.545 FPS # DRI_PRIME=1 vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. 8298 frames in 5.0 seconds = 1659.484 FPS 8313 frames in 5.0 seconds = 1662.389 FPS 8315 frames in 5.0 seconds = 1662.897 FPS I posted this issue a few days ago on ask.fedoraproject.org but so far no luck: https://ask.fedoraproject.org/en/question/87235/low-performance-when-using-the-dis-card/ In any case, I think this is the best place to seek help. Here are more details on my system: Distributor ID: Fedora Description: Fedora release 23 (Twenty Three) # lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6730M/6770M/7690M XT] # cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :Pwr:0000:01:00.0 # glxinfo | grep "OpenGL renderer" OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile # DRI_PRIME=1 glxinfo | grep "OpenGL renderer" OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.7.0) # Xorg -version X.Org X Server 1.18.3
(In reply to Arthur Hrast Essenfelder from comment #12) > # vblank_mode=0 glxgears > ATTENTION: default value of option vblank_mode overridden by environment. > ATTENTION: default value of option vblank_mode overridden by environment. > 35719 frames in 5.0 seconds = 7143.730 FPS > 35715 frames in 5.0 seconds = 7142.853 FPS > 34593 frames in 5.0 seconds = 6910.545 FPS > > # DRI_PRIME=1 vblank_mode=0 glxgears > ATTENTION: default value of option vblank_mode overridden by environment. > 8298 frames in 5.0 seconds = 1659.484 FPS > 8313 frames in 5.0 seconds = 1662.389 FPS > 8315 frames in 5.0 seconds = 1662.897 FPS > gears is not a good test for PRIME systems. It basically tests how fast the driver can swap buffers. With PRIME the dGPU rendered buffers ends up getting copied several times before getting to the IGP.
I was about to say the same thing about gears. I see now that I have not mentioned another issue when using discrete card: If I play a video in browser or with a media player and go to full screen I can clearly see some image corruption bellow or over the main diagonal (imagine picture being made of two triangles). The problem is more severe as more pixels need to be rendered, on still portions of video the corruption is not as visible. I assume not many people can dedicate their time to solving this so I will keep posting here as new kernel and driver packages versions get uploaded to debian repos.
(In reply to Alex Deucher from comment #13) > gears is not a good test for PRIME systems. It basically tests how fast the > driver can swap buffers. With PRIME the dGPU rendered buffers ends up > getting copied several times before getting to the IGP. Dear Alex, Thank you for your reply. Could you please tell me a test I can run to verify this issue? I tried also glmark2 and glxspheres64, none of which showing better results. Also when gaming this behaviour is observable. Cheers, Arthur
Created attachment 123499 [details] dmesg-radeon.dpm=1
Created attachment 123500 [details] dmesg-radeon.dpm=0
Created attachment 123501 [details] GPU-radeon.dpm=1
Created attachment 123502 [details] GPU-radeon.dpm=0
Ok, so I've managed to get my discrete GPU running by disabling DPM (by adding GRUB_CMDLINE_LINUX_DEFAULT="radeon.dpm=0" to the grub configuration file). Then, I was able to run a game using DRI_PRIME=1 and use the full power of my GPU. I'm uploading some files to show the results of the two cases (radeon.dpm=0 and radeon.dpm=1), and also the full dmesg of both runs. Note that when DPM is enabled, the GPU load gets stuck at 100%, even if it is capable of performing way better. The problem I'm facing now is that the computer gets way hotter when disabling DPM, even when idle. In any case, hope this results can help somehow. Cheers, Arthur
Created attachment 123503 [details] [review] possible fix Does the attached patch help?
How to apply the patch?
(In reply to Marko Tikvic from comment #22) > How to apply the patch? if you are using git, just: git am <patch file> if you are not using git, in your kernel source tree: patch -p1 -i <patch file> Then rebuild and re-install the kernel.
(In reply to Alex Deucher from comment #21) > Created attachment 123503 [details] [review] [review] > possible fix > > Does the attached patch help? Sorry for taking some time to reply. I had to re-compile and re-install the kernel (never done it before, so I had to look up how to do it under Fedora). Anyways, the patch does not seem to have fix the problem. It did, however, point me to a possible cause of the problem. I've discovered that if I remove the laptop from the power source, leaving it on battery, and then plug the power cord in again, I can start applications using DRI_PRIME=1 and the GPU won't get stuck at 100% usage. If I don't force this power state change (battery -- power cord), the GPU will get stuck at 100% usage. This is true for both the original kernel-4.4.8-300.fc23.x86_64 and the patched version. Also, since I am running the session with radeon.dpm=1, the GPU is not heating up and the fan is running at normal speed. If you need, I can upload the dmesg of these tests. Again, hope this can help somehow. Cheers, Arthur
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/705.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.