Bug 94708

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.