|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga
On Mon, 2002-12-09 at 00:33, Ville SyrjÃ¤lÃ¤ wrote: > On Sun, Dec 08, 2002 at 06:32:18PM +0500, Antonino Daplas wrote: > > Right :) Perhaps I wasn't clear enough, and I never said you were > > wrong. I said earlier that for hardware capable of synchronous flips, > > you have the option to wait for vsync, or not wait at all. The > > difference between synchronous flips/asynchronous flips is the ordering: > > Ok so we agree. Yes > > > case 1: asynchronous hardware flips: > > > > request flip->wait for vsync ->program registers > > > > case 2: synchronus hardware flips > > > > request flip -> program registers -> wait for vsync/not wait at all > > Ah I see we understand sync vs. async the oppostite ways. You use the > terms from the perspective of the display device while I think about the > calling process. Yes. > > > In case 2, when you only have a double buffer, you still do useful work > > while waiting for the vsync instead of the whole time idling the cpu (as > > in case 1). Not much to be gained here but perhaps a few % difference, > > but you give Mplayer extra processing time. The difference will probably > > even out in the end, anyway. > > You'd still need a signal to notify the process that it's safe to decode > the next frame. > Yes, that's why for double buffers, I still wait for the vsync _after_ processing the registers. > > The real advantage is if you have a kind of triple buffering scheme > > (which is your argument). If this is the case, there is no need to wait > > at all. I have actually modified vo_directfb.c to process to a temp > > buffer in system memory which is copied later to the backbuffer. (You've > > mentioned that this is what you're doing, right?). > > Yes I just use CreateSurface w/o specifying where the surface goes. This > way DirectFB will take care of copying the data to video memory when I > request a blit to the back buffer. And since I never touch the surface > with anything but Lock/Unlock the copy in system memory is always up to > date and there's no need to copy it back from the video memory. At least > that's what I hope is happening :) And if and when we get proper AGP > surface support the same code should work but with added speed. > > > I also have the > > added advantage that the backbuffer and frontbuffer are in AGP memory, > > so copying from temp to backbuffer is very fast. Then in the driver > > level, I just swap the front and backbuffer pointers. This isn't exactly > > triple buffering but the same scheme used by Xvideo. It's good enough > > that I actually get smooth displays with low cpu usage. > > Ok so we're doing pretty much the same thing. > > > Anyway, my point in this thread is that, depending on the hardware, you > > can choose to program the registers before or after waiting for vsync. > > And secondly, there might be useful need for further differentiation of > > the DSFLIP_WAITFORSYNC flag, and it's not too difficult to apply it in > > software if the hardware is capable of doing so. > > You may be right. Altough I'm still a bit sceptical because you need a > signal of some sort to notify you that the flip has actually occured. > Yes. I mentioned that sync hardware flips/async software flips are pretty useless for standard 2d/3d apps, because their request for flips is unthrottled. It can probably flip hundreds to thousands per second depending on the load, but your display can only do 60-100 some Hz. You have 2 options: 1. You wait for vsync, to slow the app down and make the display pretty-looking. (--vsync-after) 2. or, match each flip with an asynchronous hardware flip (like what most 3d gamers do to reach gazillions of fps, they don't mind if it's not as pretty :-). At flips in the hundreds/sec, the flicker will be mostly unnoticeable anyway (--vsync-none). For apps, on the other hand, which are throttled (a video player requesting flips at a stately pace of 25-30/sec) and your display device is capable of doing more than that, then you are pretty much guaranteed that the flip will occur before the arrival of the next frame, which negates the need to wait for the arrival of the vsync. The only thing left for the driver to do is guarantee that it occurs during the vsync pulse, and that is where synchronous hardware flips come into play (This is async_flip in the perspective of the software). > Perhaps we should just let the programmer worry about the signal and keep > the DirectFB part very simple. So we just need a new DSFLIP_ASYNCHRONOUS > (from the calling process' pov) And possibly a new layer capability flag > DLCAPS_ASYNCHRONOUS_FLIP or something like that. > Yes, I only wanted extra flags so the gfxdriver knows when and how to do the flip:) No need to change DirectFB, that was never my intent. Nor would I even advocate a generic async flip handler. Just driver caps, extra flags, I'll do everything in the software. Tony -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.