|Summary:||[SKL Regression] 2D and 3D accelerated programs are slow after booting on 4.2.0-rc8 drm-intel-nightly kernel|
|Product:||DRI||Reporter:||Olivier Berthier <olivierx.berthier>|
|Component:||DRM/Intel||Assignee:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Status:||CLOSED NOTOURBUG||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|i915 platform:||i915 features:|
Description Olivier Berthier 2015-09-03 12:34:07 UTC
Created attachment 118062 [details] dmesg log file Regression ----------- 2D and 3D accelerated programs become slow with all drm-intel kernels after booting on 4.2.0-rc8 drm-intel-nightly. Setup : ------- Hardware Platform: SKY LAKE Y A0 CPU : Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz (family: 6, model: 78 stepping: 3) MCP : SKL-Y D1 2+2 (ou ULX-D1) QDF : QJK9 CPU : SKL D1 Chipset PCH: Sunrise Point LP C1 CRB : SKY LAKE Y LPDDR3 RVP3 CRB FAB2 Reworks : All Mandatories + FBS02,FBS03, F23, O-02 & O-06 Software BIOS : SKLSE2R1.R00.X093.B02.1507222151 07/22/2015 ME FW : 18.104.22.1688 Ksc (EC FW): 1.15 Linux : Ubuntu 14.04 LTS 64 bits Kernel : 4.2.0-rc8 drm-intel-nightly commit 78a01ed08ac09d84cb47db59dd10fe9de1ee6c4a Author: Jani Nikula <firstname.lastname@example.org> Date: Mon Aug 31 18:43:56 2015 +0300 drm-intel-nightly: 2015y-08m-31d-15h-42m-59s UTC integration manifes cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d libdrm: (HEAD, origin/master, origin/HEAD, master) c3301d013444b7b5d02c58307e188e292d8cf18a mesa: (HEAD, origin/10.6) 99793e2541510fe208d29e69fedf97a6fff006f8 xf86-video-intel: (HEAD, origin/master, origin/HEAD, master) 9b0ed16385ae076c262a2e09639822d9488ccf57 xserver: (HEAD, origin/master) 533fb627398e20f863234d780f4463e37007515b Steps : ------- 1. Boot on the 4.2.0-rc8 drm-intel-nightly kernel. 2. Use the system. 3. Reboot on the 4.2.0-rc8 drm-intel-testing-2015-08-28 or older kernel (eg. 4.2.0-rc4 drm-intel-testing-2015-07-31) . 4. Use the system. Actual result : --------------- On step 2, the Unity desktop environment is slow, and after rebooting on another kernel (steps 4), the system kept to be slow. This has an impact on all 2D and 3D applications and the test suites (see the piglit sanity test result file). On Unity environment, compiz is now a very heavy cost process on the CPU. Expected result : ---------------- No lag on all kernels. Also tested with mesa on origin/master, same result.
Comment 1 Olivier Berthier 2015-09-03 12:34:38 UTC
Created attachment 118063 [details] kern.log file
Comment 2 Olivier Berthier 2015-09-03 12:35:02 UTC
Created attachment 118064 [details] Xor.0.log file
Comment 3 Olivier Berthier 2015-09-03 12:35:37 UTC
Created attachment 118065 [details] piglit sanity test result
Comment 4 Chris Wilson 2015-09-03 16:01:03 UTC
The trigger is mesa/dri2 not loading: [ 10.124] (EE) AIGLX error: Calling driver entry point failed [ 10.125] (EE) AIGLX: reverting to software rendering [ 10.218] (II) AIGLX: Loaded and initialized swrast [ 10.218] (II) GLX: Initialized DRISWRAST GL provider for screen 0 which I guess is due to no context support. One most likely error from the kernel is Sep 3 11:40:41 SKLY7 kernel: [ 6.301563] [drm:guc_fw_fetch] before requesting firmware: GuC fw fetch status PENDING Sep 3 11:40:41 SKLY7 kernel: [ 6.302057] i915 0000:00:02.0: Direct firmware load for i915/skl_guc_ver3.bin failed with error -2 Sep 3 11:40:41 SKLY7 kernel: [ 6.302068] [drm:guc_fw_fetch] GuC fw fetch status FAIL; err -2, fw (null), obj (null) Sep 3 11:40:41 SKLY7 kernel: [ 6.302166] [drm:intel_guc_ucode_init [i915]] *ERROR* Failed to fetch GuC firmware from i915/skl_guc_ver3.bin (error -2) Sep 3 11:40:41 SKLY7 kernel: [ 6.309483] [drm:intel_guc_ucode_load] GuC fw status: fetch FAIL, load NONE Sep 3 11:40:41 SKLY7 kernel: [ 6.309562] [drm:intel_guc_ucode_load] GuC fw fetch status FAIL Sep 3 11:40:41 SKLY7 kernel: [ 6.309674] [drm:i915_gem_init_hw [i915]] *ERROR* Failed to initialize GuC, error -5 (ignored) which is meant to be ignored. However, the dmesg lacks the logging (needs drm.debug|=1) to see why the context failed.
Comment 5 Olivier Berthier 2015-09-03 17:15:04 UTC
Created attachment 118070 [details] dmesg log file with all drm.debug tags This file must contain all drm.debug tags.
Comment 6 Chris Wilson 2015-09-03 17:57:30 UTC
Ok, that scratched my theory. No unexpected errors from a drm_ioctl(). Then again, no attempt to create a context either. Can you search for something like lightdm/:0.log ? Or start X from a VT and see if any addition warnings are written out to stderr to explain why mesa fails to load?
Comment 7 Olivier Berthier 2015-09-04 08:54:59 UTC
Created attachment 118074 [details] startx stderr log
Comment 8 Olivier Berthier 2015-09-04 08:58:28 UTC
Created attachment 118075 [details] xsession-errors file I add startx stderr and xsession-errors files. Maybe this is related to these two lines : libGL error: pci id for fd 4: 8086:191e, driver (null) i965_dri.so does not support the 0x191e PCI ID.
Comment 9 Chris Wilson 2015-09-04 09:05:54 UTC
(In reply to Olivier Berthier from comment #8) > Created attachment 118075 [details] > xsession-errors file > > I add startx stderr and xsession-errors files. > Maybe this is related to these two lines : > > libGL error: pci id for fd 4: 8086:191e, driver (null) > i965_dri.so does not support the 0x191e PCI ID. Yes, X is not using the right i965_dri.so. No idea how different kernels affect that, and that should not be impacting 2D either.
Comment 10 Olivier Berthier 2015-09-16 14:56:34 UTC
For the 2D, I think it's because compiz was very slow. I had this problem when I have installed Ubuntu 14.04.3 LTS instead of Ubuntu 14.04 LTS. My script for the installation of the graphic stack had automatically removed some package with a suffix like *-lts-vivid so I don't think it's a Sky Lake regression, just a none support from some packages.