Bug 16612

Created attachment 17517 [details]
xorg.0.log

Created attachment 17518 [details]
xorg conf file

sometimes,we cannot see any swap after rotation.

Created attachment 17521 [details]
glswap.c

Haien, does this still exist?

(In reply to comment #5)
> Haien, does this still exist?
> 

yes,still exists against the latest driver.

(In reply to comment #6)
> (In reply to comment #5)
> > Haien, does this still exist?
> > 
> 
> yes,still exists against the latest driver.
> 

we retest it with below commit:
Libdrm:         (master)4a0d19ef4f210cea9e60c5acc355df03723ef808
Mesa:           (mesa_7_4_branch)e2092bb23c956ba9ab940935f803ef843db81af2
Xserver:        (server-1.6-branch)4557b3f6c4273cd83b701beaf7a150c806fed298
Xf86_video_intel:              
(master)81c652e9a666a7459bcc5217c8a5ec518b6e00da
GEM_kernel:       (for-airlied)99d31f896d243c13bb90b56620d33b416a5cffa7

still exists against:
Libdrm:         (master)00d8e960ca665b7f0528438331f4d0ae77fbb4cc
Mesa:(mesa_7_4_branch)b009a32bf428192fef2dc4787d25f022a472854f          
Xserver:        (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:       (2.7)e2465249a90b9aefe6d7a96eb56a51fde54698a0
Kernel:       (for-airlied)a2e785c32b886dd7f0289d1cf15fc14e9c81bc01

I think this particular bug must be gone now since vblank_mode=3 won't have any effect with DRI2.  But we do need to support rotation better; right now we just blit from the front buffer to the rotate buffer at block handler time.  It should be done at vblank time if there's ever anything to copy.

Here's the rotation slowness bug Keith, have fun.

removing "vblank_mode=3" from title since this is not the key now.

keith, any plan to fix this "rotation slowness"? It'll be good if we fix it in Q3.

I'm fairly sure the slowness is caused by X server scheduling which limits how often the screen is redrawn under rotation. I've been considering what changes might be made within the X server to reduce the delays. But, none of this work would be done within the video driver, so it's not really related to our Q3 release.

You can test this in your environment by running two copies of glxgears; that will force the X server to schedule screen updates more often.

I'm going to refile this with the X server instead of the video driver.

commit e7dd1efef408effe52d0bd3d3aa0b5d4ee10ed90
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Aug 25 18:07:00 2009 -0700

    Ensure that rotation updates happen frequently

But now it can't be tested with glswap because SGI_swap_control was disabled by the following commit in Mesa. 

commit 279143c6e808b37c333321b696d80df77f709a04
Author: Owen W. Taylor <otaylor@fishsoup.net>
Date:   Sat Jun 6 14:46:22 2009 -0400

    Disable SGI_swap_control extension for DRI2

For the SGI_swap_control was disabled on both master and 7_5 branch, so I rebuilt it with 7_4 branch of mesa. I tested with glswap, after rotation, it becomes slower compared with before it rotates. And I tried with the method mentioned by Keith that I run two glxgears it looks a little faster than without glxgears but it still slower than before it rotates.  
I tested with 
Libdrm:         (master)ce6c68dc8a893ed8673f49d381a8500c2ee3c29f
Mesa:           (mesa_7_4_branch)4f84350abc28dc2e5153c9f5c7acab1fb23107c3
Xserver:        (server-1.6-branch)3044711412d0a08ba65a491bd2441c0c8980f5e2
Xf86_video_intel:    (master)6361c3b9af39265df9222b1f3b6fb9c4197087c1

I tested with the newest code, after I start X, run glxgears, it is 248 fps, and run openarena/stress_bases3 it is 18.1 fps. Then I rotate the screen, the glxgears is only 81 fps, and openarena is 13.1 fps. I test with: 
Libdrm:         (master)73b59c894380995a2889b98e79acadd2da0bb237
Mesa:           (master)7d361537661b93a501c9533271458a41b965ea79
Xserver:         (server-1.6-branch)3044711412d0a08ba65a491bd2441c0c8980f5e2
Xf86_video_intel:   (master)5812531e08147576de776b2dd64e7f94c08eb851
Kernel:         (master)326ba5010a5429a5a528b268b36a5900d4ab0eba
So I think this issue still existed and I reopen it. 

lower priority: Moblin has got a workaround and not pushing hard now.

(In reply to comment #18)
> lower priority: Moblin has got a workaround and not pushing hard now.

Which kind of workaround is this. Could you share more details with us, please?

The statement of " Moblin has got a workaround" came from Novell! More details:

======================================================================
That comment in freedesktop bugzilla is not totally correct, as what
we have for moblin is not a workaround at all.

At first, <vendor> requested us to provide the ability to show a 1024x768
desktop within a 1024x600 LCD screen for netbook. But then, we found the bug
https://bugzilla.novell.com/show_bug.cgi?id=527359.  At the end, due to
various performance issues with X, <vendor> dropped that requirement. So, we
didn't have a workaround for the problem, <vendor> simply dropped the
requirement so we no longer need to work on it.
======================================================================

I teseted with the newest code on master branches on piketon and pinetrail, don't see such issue now. And it has no affect on our use after the rotation. The data is as following:

On Piketon:
before rotate:
glxgears: 60 fps; glxgears without vblank_sync: 836 fps
openarena(1024x768): 69.3 fps; openarena without vblank_sync: 72.9 fps
after rotation: (I rotate it left, right, inverted and then back to normal)
glxgears: 60 fps; glxgears without vblank_sync: 835 fps
openarena(1024x768): 66.6 fps; openarena without vblank_sync: 72.9 fps

On Pinetrail:
glxgears: 60 fps; glxgears without vblank_sync: 299 fps
openarena: can't run 
after rotation: (I rotate it left, right, inverted and then back to normal)
glxgears: 60 fps; glxgears without vblank_sync: 299 fps

closing