Bug 10675 (SyncVblanki810)

Summary:	Unable to sync to vblank (i810/i915).
Product:	Mesa	Reporter:	Agustin <arubio>
Component:	Drivers/DRI/i915	Assignee:	haihao <haihao.xiang>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	ds, elupus, michael.fu
Version:	6.5	Keywords:	NEEDINFO
Hardware:	All
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Testcase for the bug

Description Agustin 2007-04-19 00:43:53 UTC

Tested in: 
* Xorg 7.1.1 + mesa 6.5.1 + i810 1.7.2
* Xorg 7.1.1 + mesa 6.5.2 + i810 1.7.2

I have noticed a strange behaviour:
- In a light app where  more than 60 FPS are achieved, the app syncs to 
vblank (getting 60FPS) andthere is not tearing.

- In a heavy app with textures where less than 60 FPS are achieved, setting 
vblank_mode=3 doesn't sync withVertRefresh (ie: getting 37FPS) and tearing appears.

Comment 1 Agustin 2007-04-19 00:46:15 UTC

Created attachment 9652 [details]
Testcase for the bug

Make TEXTURE_SIZE greater enough to get less FPS than VertRefresh.

The apps will run at that FPS, no matter waht value vblank_has.

Comment 2 Michel Dänzer 2007-04-19 02:22:39 UTC

Would it be feasible for you to use glXSwapIntervalSGI()? That seems to work better here for this.

Also, as I pointed out earlier, i915 DRM 1.6 or newer might give better results together with Mesa 6.5.2 or newer, but I forgot that also requires xserver git master (1.3 is not enough).

Comment 3 Michael Fu 2007-12-02 19:04:53 UTC

would you please test on the latest development tip to see if this bug still exist? thanks.

Comment 4 Agustin 2007-12-03 00:43:30 UTC

OK

I'll test it and post the results.

Comment 5 Agustin 2007-12-11 08:25:46 UTC

Apparently It syncs whe fps is below vertical refresh. However tearing appears
in a 2D sprite animations.

Running the testcase, the xserver has crashed many times with the error:
intel_bufmgr_ttm.c:757: Error -16 waiting for fence fence buffers.

Any idea?

Comment 6 haihao 2008-03-18 22:04:57 UTC

(In reply to comment #5)
> Apparently It syncs whe fps is below vertical refresh. However tearing appears
> in a 2D sprite animations.
> 
> Running the testcase, the xserver has crashed many times with the error:
> intel_bufmgr_ttm.c:757: Error -16 waiting for fence fence buffers.
> 
It seems this issue has gone away, could you try again with the latest component(mesa, drm)? 

Thanks.

Comment 7 Gordon Jin 2008-03-24 22:25:06 UTC

*** Bug 13938 has been marked as a duplicate of this bug. ***

Comment 8 Michael Fu 2008-06-23 19:57:44 UTC

Augstin, Do you still have chance to verify haihao's comment# 6?

Comment 9 Agustin 2008-06-24 00:13:22 UTC

(In reply to comment #8)
> Augstin, Do you still have chance to verify haihao's comment# 6?
> 

I'm plenty of work thies week. I think I'll be able to test it by the end of the week.

Comment 10 Michael Fu 2008-07-07 19:54:18 UTC

(In reply to comment #9)
> (In reply to comment #8)
> > Augstin, Do you still have chance to verify haihao's comment# 6?
> > 
> 
> I'm plenty of work thies week. I think I'll be able to test it by the end of
> the week.
> 

any update?

Comment 11 elupus 2008-07-29 09:20:30 UTC

I found this issue when fixing up vsync on XBMC in linux and a solution (for intel anyway).

If you force a glFinish() (glFlush() isn't enough) before you swap buffers, the vsync issue goes away. My guess is that the mesa drivers wait for vsync before making sure all rendering in pipeline is complete. 

If rendering what's in the gl pipeline takes too long, you will always miss the vsync.

Regards
Joakim

Comment 12 elupus 2008-07-29 09:22:45 UTC

Oh and the comment about glXSwapIntervalSGI has no effect on this at all. glXSwapIntervalSGI is only a limit of max fps. 
If you are late to the swap interval it will still swap immidiatly not considering if that will cause tearing.

Comment 13 Gordon Jin 2008-09-09 06:44:05 UTC

I think this should have been fixed by Jesse's recent commits.
Please reopen if you still see it.

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.