Bug 91562

Probably best if Tvrtko takes the first look. Can you please attach an Xorg.0.log with the xf86-video-intel compiled with --enable-debug=full and the dmesg with drm.debug=6.

You should have at least attached the regular Xorg.0.log considering this is an X related bug, and attaching the drm.debug=6 dmesg should be standard practice.

Created attachment 117538 [details] [review]
New IGT test case.

Please test with the new IGT test cases "primary-rotation-90-270" and "sprite-rotation-90-270".

Compile tested only since I don't have a SKL machine at the moment.

Using IGT we are able dump below registers sequence:


root@appala:/home/appala# tursulin/intel-gpu-tools/tools/intel_reg_read 0x70180 0x7019c
WARNING: Use of tursulin/intel-gpu-tools/tools/intel_reg_read has been deprecated and replaced by intel_reg.
0x70180 : 0xC4802400
0x7019C : 0x3100000
root@appala:/home/appala# xrandr -o left
root@appala:/home/appala# tursulin/intel-gpu-tools/tools/intel_reg_read 0x70180 0x7019c
WARNING: Use of tursulin/intel-gpu-tools/tools/intel_reg_read has been deprecated and replaced by intel_reg.
0x70180 : 0xC4802400
0x7019C : 0x3100000
root@appala:/home/appala# xrandr -o right
root@appala:/home/appala# tursulin/intel-gpu-tools/tools/intel_reg_read 0x70180 0x7019c
WARNING: Use of tursulin/intel-gpu-tools/tools/intel_reg_read has been deprecated and replaced by intel_reg.
0x70180 : 0xC4802400
0x7019C : 0x4980000
root@appala:/home/appala# xrandr -o normal
root@appala:/home/appala# tursulin/intel-gpu-tools/tools/intel_reg_read 0x70180 0x7019c
WARNING: Use of tursulin/intel-gpu-tools/tools/intel_reg_read has been deprecated and replaced by intel_reg.
0x70180 : 0xC4802400
0x7019C : 0x4980000
root@appala:/home/appala#

I've run this new IGT on Appala's machine remotely and it works fine. This eliminates potential corner cases where i915 potentially wouldn't handle direct transition from 90 to 270 degree rotation.

But playing with rotation via xrandr and intel_reg_read on PLANE_CTL and PLANE_SURF registers suggests that Xorg is not trying to use hardware rotation at all.

Tvrtko, you should know better than leaving such a statement hanging in midair without any full-debug logs!

Appala is working on providing them.

Created attachment 117811 [details]
skl-y_4.2-rc7_dmesg

Created attachment 117812 [details]
skl-y_4.2rc7_Xorg.0.log

Reproduced on SKL-Y with eDP1 and external HDMI and DP screens.
Screen is black, cursor is available (it rotated).

Platform: SKY LAKE Y A0
CPU : Intel(R) Core(TM) m3-6Y30 CPU @ 0.8GHz 4MB (family: 6, model: 78  stepping: 3)
MCP : SKL-Y  D1  2+2
QDF : QVY3 
CPU : SKL D1
Chipset PCH: Sunrise Point LP C1       
CRB : SKY LAKE Y LPDDR3 RVP3 CRB FAB2
Reworks : All Mandatories + FBS02 & FBS03, O-06
Software
BIOS : SKLSE2R1.R00.X093.B02.1507222151
ME FW : 11.0.0.1163
Ksc (EC FW): 1.15
Linux distribution: Ubuntu 14.04 LTS 64 bits
Kernel: drm-intel-nightly 30263ef782e0548c114fb6f2771b58b27c56ba0d 4.2.0-rc7 from git://anongit.freedesktop.org/drm-intel 
Mesa: mesa-10.6.3 ddc976368fef367e464472ebcc2ac4fd89eb9fd8 from http://cgit.freedesktop.org/mesa/mesa/ 
Xf86_video_intel: 2.99.917 baec802b21387d04aebb10ac29e719a1800c5aa0 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ 
Libdrm: libdrm-2.4.62 ba4b5ac010ab85406ec52e3906e13d58cd9aa782 from http://cgit.freedesktop.org/mesa/drm/ 
Cairo: 1.14.2 from 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d http://cgit.freedesktop.org/cairo 
libva: libva-1.6.0 a8008998bc0d4a76ae6927607c048e52ba50fd0e from http://cgit.freedesktop.org/libva/ 
intel-driver: 1.6.0 32268c46d538667d437dc9266aa4c183e51c1286 from http://cgit.freedesktop.org/vaapi/intel-driver 
Xserver: xorg-server-1.17.2 2123f7682d522619f101b05fb75efa75dabbe371 from http://cgit.freedesktop.org/xorg/xserver 

Kernel commit log:
commit 30263ef782e0548c114fb6f2771b58b27c56ba0d
Author: Jani Nikula
Date: Mon Aug 17 10:19:43 2015 +0300
drm-intel-nightly: 2015y-08m-17d-07h-19m-25s UTC integration manifest

Updated to Highest and Blocker. This is a PV blocker.

Does SW rotation still work properly? (assuming there's a flag to disable HW rotation)  That is an acceptable PV workaround for the platform, though the issue should still be root-caused and fixed.

We didn't find how to disable HW rotation.
For information fbcon rotate works which looks like a SW rotation.
Also here are kms_rotation_crc igt results:
igt@kms_rotation_crc@bad-pixel-format 		        Pass 	
igt@kms_rotation_crc@bad-tiling 			Pass 	
igt@kms_rotation_crc@cursor-rotation-180 		Pass 	
igt@kms_rotation_crc@primary-rotation-180 		Pass 	
igt@kms_rotation_crc@primary-rotation-270 		Pass 	
igt@kms_rotation_crc@primary-rotation-90 		Pass 	
igt@kms_rotation_crc@sprite-rotation-180 		Pass 	
igt@kms_rotation_crc@sprite-rotation-270 		Pass 	
igt@kms_rotation_crc@sprite-rotation-90 		Fail 	
igt@kms_rotation_crc@sprite-rotation-90-pos-100-0 	Fail

Some comments:

1. I couldn't reproduce the IGT failures on todays nightly kernel. Can you explore those failures on your end more?

2. Xorg.log you attached will need to be full debug for Chris to analyse (see comment #1). Also it is not clear to me it is attempting any rotations - "rotation normal" ?

3. Kernel log also does not suggest HW rotation is being attempted. You would see something like:

   [drm:intel_rotate_fb_obj_pages] Created rotated page mapping for object size...

Created attachment 118121 [details]
ddx full debug log

I tried the "rotate left then right" scenario and it did not result in a black screen here. Log attached.

Thing I realised though is - hardware 90/270 rotation requires Y tiling which AFAIR DDX will not do unless recompiled with a different default.

Created attachment 118122 [details]
ddx debug log in Y tiling mode

With the DDX rebuilt to default to Y tiling, this logs shows that when "xrandr -o left" it abandons the Y tiled FB and goes back to X tiled. Presumably falling back to software rotation in the process.

(In reply to Tvrtko Ursulin from comment #14)
> Created attachment 118122 [details]
> ddx debug log in Y tiling mode
> 
> With the DDX rebuilt to default to Y tiling, this logs shows that when
> "xrandr -o left" it abandons the Y tiled FB and goes back to X tiled.

It sets the rotation, and then the kernel rejects the setcrtc and so it is forced to use a shadowfb, X without rotation, and perform manual rotations (using the GPU of course!) from the Y-tiled frontbuffer to the X-tiled framebuffer.

(In reply to Chris Wilson from comment #15)
> (In reply to Tvrtko Ursulin from comment #14)
> > Created attachment 118122 [details]
> > ddx debug log in Y tiling mode
> > 
> > With the DDX rebuilt to default to Y tiling, this logs shows that when
> > "xrandr -o left" it abandons the Y tiled FB and goes back to X tiled.
> 
> It sets the rotation, and then the kernel rejects the setcrtc and so it is
> forced to use a shadowfb, X without rotation, and perform manual rotations
> (using the GPU of course!) from the Y-tiled frontbuffer to the X-tiled
> framebuffer.

Does it try to go Y tiled when attempting to rotate, in the default build? 

Interestingly in the Y tiled build there seems to be a path where it doesn't use fb modifiers ("[drm:intel_framebuffer_init] No Y tiling for legacy addfb").

(In reply to Tvrtko Ursulin from comment #16)
> (In reply to Chris Wilson from comment #15)
> > (In reply to Tvrtko Ursulin from comment #14)
> > > Created attachment 118122 [details]
> > > ddx debug log in Y tiling mode
> > > 
> > > With the DDX rebuilt to default to Y tiling, this logs shows that when
> > > "xrandr -o left" it abandons the Y tiled FB and goes back to X tiled.
> > 
> > It sets the rotation, and then the kernel rejects the setcrtc and so it is
> > forced to use a shadowfb, X without rotation, and perform manual rotations
> > (using the GPU of course!) from the Y-tiled frontbuffer to the X-tiled
> > framebuffer.
> 
> Does it try to go Y tiled when attempting to rotate, in the default build? 

It's tricky. The buffer cannot be exported and Y-tiling is so much slower for common operations that I am not convinced it is worth it. It is possible for the client to provide a Y-tiled buffer that we will then use. But since the setcrtc failed...


> Interestingly in the Y tiled build there seems to be a path where it doesn't
> use fb modifiers ("[drm:intel_framebuffer_init] No Y tiling for legacy
> addfb").

Right, during the start up it tests whether the interface is deliberately broken.

(In reply to Chris Wilson from comment #17)
> (In reply to Tvrtko Ursulin from comment #16)
> > (In reply to Chris Wilson from comment #15)
> > > (In reply to Tvrtko Ursulin from comment #14)
> > > > Created attachment 118122 [details]
> > > > ddx debug log in Y tiling mode
> > > > 
> > > > With the DDX rebuilt to default to Y tiling, this logs shows that when
> > > > "xrandr -o left" it abandons the Y tiled FB and goes back to X tiled.
> > > 
> > > It sets the rotation, and then the kernel rejects the setcrtc and so it is
> > > forced to use a shadowfb, X without rotation, and perform manual rotations
> > > (using the GPU of course!) from the Y-tiled frontbuffer to the X-tiled
> > > framebuffer.
> > 
> > Does it try to go Y tiled when attempting to rotate, in the default build? 
> 
> It's tricky. The buffer cannot be exported and Y-tiling is so much slower
> for common operations that I am not convinced it is worth it. It is possible
> for the client to provide a Y-tiled buffer that we will then use. But since
> the setcrtc failed...

So basically the reported black screen has nothing to do with hardware rotation, since hardware rotation is not supported since it requires Y tiling which the DDX won't attempt.

And either way, since I could not reproduce the black screen, someone else will have to provide full debug logs for that case.
 
> > Interestingly in the Y tiled build there seems to be a path where it doesn't
> > use fb modifiers ("[drm:intel_framebuffer_init] No Y tiling for legacy
> > addfb").
> 
> Right, during the start up it tests whether the interface is deliberately
> broken.

I am pretty sure I've seen it when requesting rotation, not on startup.

(In reply to Tvrtko Ursulin from comment #18)
> (In reply to Chris Wilson from comment #17)
> > (In reply to Tvrtko Ursulin from comment #16)
> > > (In reply to Chris Wilson from comment #15)
> > > > (In reply to Tvrtko Ursulin from comment #14)
> > > > > Created attachment 118122 [details]
> > > > > ddx debug log in Y tiling mode
> > > > > 
> > > > > With the DDX rebuilt to default to Y tiling, this logs shows that when
> > > > > "xrandr -o left" it abandons the Y tiled FB and goes back to X tiled.
> > > > 
> > > > It sets the rotation, and then the kernel rejects the setcrtc and so it is
> > > > forced to use a shadowfb, X without rotation, and perform manual rotations
> > > > (using the GPU of course!) from the Y-tiled frontbuffer to the X-tiled
> > > > framebuffer.
> > > 
> > > Does it try to go Y tiled when attempting to rotate, in the default build? 
> > 
> > It's tricky. The buffer cannot be exported and Y-tiling is so much slower
> > for common operations that I am not convinced it is worth it. It is possible
> > for the client to provide a Y-tiled buffer that we will then use. But since
> > the setcrtc failed...
> 
> So basically the reported black screen has nothing to do with hardware
> rotation, since hardware rotation is not supported since it requires Y
> tiling which the DDX won't attempt.

The scenario is the same, hw rotation is still requested. We depend on the kernel reporting the failure to go back to manual rotation. So whilst the GTT view should never be created, setting the rotation property during a setcrtc would seem to be the trigger.

> And either way, since I could not reproduce the black screen, someone else
> will have to provide full debug logs for that case.
>  
> > > Interestingly in the Y tiled build there seems to be a path where it doesn't
> > > use fb modifiers ("[drm:intel_framebuffer_init] No Y tiling for legacy
> > > addfb").
> > 
> > Right, during the start up it tests whether the interface is deliberately
> > broken.
> 
> I am pretty sure I've seen it when requesting rotation, not on startup.

On reflection, we only try addfb2 if addfb says no (so everytime).

Since I couldn't reproduce the black screen, and we have determined DDX will effectively not try hardware rotation for 90/270, ressigning back to Cristophe to provide debug logs.

Created attachment 118181 [details]
dmesg log with rotation 90-270 on drm-nightly ww37 (tar.gz)

Here the dmesg log file for the kms_rotation_crc tests on IGT with the patch on Sky Lake Y with the drm-intel-nightly kernel at :
commit b7be838c844cbccef1c863e2cbcc44952c7f657c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Sep 9 16:49:55 2015 +0200

    drm-intel-nightly: 2015y-09m-09d-14h-49m-13s UTC integration manifest

The result is dmesg-warn, and sometimes IGT return dmesg-fail.

I don't reproduce the bug with xrandr on this kernel.

On the last drm-intel-testing tag (2015-08-28), I reproduce the IGT test cause a kernel panic.

(In reply to Olivier Berthier from comment #21)
> Created attachment 118181 [details]
> dmesg log with rotation 90-270 on drm-nightly ww37 (tar.gz)
> 
> Here the dmesg log file for the kms_rotation_crc tests on IGT with the patch
> on Sky Lake Y with the drm-intel-nightly kernel at :
> commit b7be838c844cbccef1c863e2cbcc44952c7f657c
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Sep 9 16:49:55 2015 +0200
> 
>     drm-intel-nightly: 2015y-09m-09d-14h-49m-13s UTC integration manifest
> 
> The result is dmesg-warn, and sometimes IGT return dmesg-fail.

I don't see any test fails or warnings triggered by it in the log you attached. Is that the correct log?
 
> I don't reproduce the bug with xrandr on this kernel.
> 
> On the last drm-intel-testing tag (2015-08-28), I reproduce the IGT test
> cause a kernel panic.

Log?

Created attachment 118183 [details]
piglit results file igt@kms_rotation_crc* with 90-270

I add the results.json file from piglit.

(In reply to Olivier Berthier from comment #23)
> Created attachment 118183 [details]
> piglit results file igt@kms_rotation_crc* with 90-270
> 
> I add the results.json file from piglit.

I don't see the kernel panic?

Bug scrub:
Assigned to Olivier. Please check logs and report the kernel panic in another bug if reproduced

Not reproduced on Sky Lake Y with the kernel 4.3.0-rc2-drm-intel-testing-2015-09-28.

So closed as not reproduced