Open source "Radeon" driver: vsync, vblank_mode, tearing and (open)GL

[Meneer Jansen]

I know there is an issue w/ Ati cards, the closed 'fglrx' drivers as well as the open Xorg 'Radeon' driver considering GL.

If you want to use GL (video) output (example: mplayer -vo gl) then video stuttters, tears etc. See this bug report on bugs.freedesktop.org. You always get an error about "vblank_mode" (a dri setting GL uses), vsync etc. Why is vertical synchronisation (if that really is what it is called) so important for GL and why is it broken in Linux's open and proprietary drivers since 2001?

There are many topics and wiki's everywhere on the 'net about this but no solution nor a workaround. Problem also is that recently the drivers changed and sometimes I don't know if they are talking qbout the open or the closed drivers...

The only solution some give is: "buy an Nvidia card". That's gonna be pretty impossible for a laptop and it isn't a solution, more of a weird workaround advice.

What exactly is the problem and is there any chance of it ever being addressed/solved?

[bridgman]

Syncing to vblank is the simplest form of tearing avoidance - basically each displayed frame is forced to wait until the "blanking period" between frames when nothing is being displayed, to minimize the chance of a portion of the image being updated at the same time that portion of the image is being scanned out to the screen (that's where tearing comes from).

The bug report you linked to is specific to a fairly old IGP part; AFAIK the same configuration works with most other cards. The vblank/tearing avoidance code in the common driver framework went through a lot of changes over the last year and was probably broken for a while on every open driver but AFAIK the current code should be working again.

Also note that sync-to-vblank when running with a compositor is problematic on a wide range of configurations. The issue there is that it's actually the compositor that needs to sync to vblank while the video player app needs to "sync to the ocmpositor", and AFAIK the code to do that properly doesn't exist anywhere yet.

Other than possible compositor issues AFAIK sync-to-vblank with GL output works with the proprietary drivers now.

Is there a specific problem you are trying to solve ? If so can you provide more details about your configuration ?

[nanonyme]

Syncing to vblank is the simplest form of tearing avoidance - basically each displayed frame is forced to wait until the "blanking period" between frames when nothing is being displayed, to minimize the chance of a portion of the image being updated at the same time that portion of the image is being scanned out to the screen (that's where tearing comes from).

Is there a good way to playback video on multiple displays with differing refresh rates with syncing, btw? (I know, it's slightly masochistic a setup but technically one might want to do it)

[bridgman]

If you're talking about playing back the *same* stream on multiple unsynced displays (eg clone mode) then I'm not aware of any good solution for that. You can have different buffering for each display and make sure that you get tear-free results on each screen (not sure if any players/compositors do this today) but you're still going to have the frames appearing at slightly different times on each screen.

Consumer electronics have no problem with this because the display refresh is driven by the content rather than running the display at a fixed frequency, having the content come in at a slightly different frequency, and trying to make everything line up anyways.

[nanonyme]

Hmmm... I suppose it's just up to the user to find close enough resulutions and refresh rates if you want to watch a movie that's streched across multiple display and the thing to actually work. (I started playing with the idea since some time ago there were those pictures of that video playback system that played the same video on a multi-display system that consisted of quite a few monitors)

[bridgman]

Yep. I'm not sure how much time difference between screens it takes for a typical viewer to notice -- I suspect it would be pretty visible but it would be an interesting test.

Might not be that easy to set up since most implementations give you tear-free on one screen and simultaneouls, but tearing video on the other screen rather than two tear-free displays with a varying time offset.

[Agdr]

Also note that sync-to-vblank when running with a compositor is problematic on a wide range of configurations. The issue there is that it's actually the compositor that needs to sync to vblank while the video player app needs to "sync to the ocmpositor", and AFAIK the code to do that properly doesn't exist anywhere yet.

Isn't it enough to have the application draw to an offscreen buffer, and copy that to the compositor-accessible window with a single blit/render operation?

Assuming that the compositor syncs to vblank, that the GPU/driver either does not use multiple hardware contexts or synchronizes them automatically, and that either software or hardware flushes render and texture caches properly, it should be tear-free.

GTK+ 2 already automatically renders this way unless the application explicitly disables it (which it should only do if it is doing the equivalent itself).

The biggest problem here could be that the hardware needs an explicit cache flush or barrier and the driver lacks the logic to generate it properly. Not sure whether this is the case or not for any driver.

[bridgman]

The data flow is no problem, ie applications render properly to an offscreen buffer.

The question is whether the compositor syncs to vblank (there are options but they don't seem to do anything) and whether the framework recognizes the presence of a compositor and syncs the application to a "compositor buffer available" event rather than to a vblank event.

AFAIK not all of that happens today. I haven't had a chance to pick through all the code to see what is there and what is not.

[Meneer Jansen]

The specific problem I have is as follows. I also use my PC as a mediacenter. I like to use XBMC as mediacenter software which can only use GL as video out (vo). I use Metacity as my window manager then, without compositing. I use an Ati Radeon 9600 videocard now, I used to have an Nvidia card before, which worked just fine w/ XBMC. The old Ati card is not supported by the proprietry 'fglrx' driver from Ati/AMD. So I use the (exellent) open Xorg driver that's simply called "radeon". I activate the TV-out on the Radon to watch my movies and DVD's of course. No clone mode: I disable the CRT monitor (xrandr --output VGA-0 --off).

Using XBMC to watch moviesis somewhat the same thing as using mplayer with the command line option "-vo gl". On my TV the video tears in XBMC and w/ 'mplayer -vo gl' and I get the error from mplayer:

do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter

If I use 'mplayer -vo gl' on the CRT monitor I get the (classic) error that my PC is 'too slow too play this'. If I use 'xv' as vo then there's no error. That's why I think vsync is broken in the 'radeon' driver for GL. I don't know exactly which version of the radeon driver I use, but I think it's the latest because I use Ubuntu Lucid (10.04)and Synaptic says about radeon: version 6.13.0.

P.S. Every thing works fine when I use xv for video output. But not all applications can use xv (or x11): some only use gl (i.e. XBMC).

[bridgman]

I think the default for the open source GL stack is sync-to-vblank disabled. There's a driconf utility to turn it on IIRC, are you using that ?

Just going from memory here but I believe the default GL output option for mplayer still does quite a bit of processing on the CPU (eg colour space conversion aka CSC). There are sub-options to do CSC on the GPU as well, have you tried those ?