On Sun, 21 Oct 2001, Billy Biggs wrote:
> Vladimir Dergachev ([EMAIL PROTECTED]):
>
> > > and hope that someone in the kernel has an accurate clock. It would
> > > also need to tell me the (exact) refresh rate + sync point.
> >
> > _You_ don't need to know that. All you need is to tell the card:
> > display this frame after sync. It will do the rest !
>
> I think that you think I'm trying to solve the tearing problem. No,
> I'm not. I understand that you won't tear.
>
> I'm talking about planning how many refreshes to show each frame. I'd
> be really surprised if you could say to the ATI card 'show this 2
> refreshes from now'.
The card won't do that, but the driver can. In this case what you do is
submit a frame and a number - show this frame n-vsync interrupts from the
previous one - and the driver can do the rest.
>
> > > I'm not worried about tearing, I'm worried about amortizing frame
> > > time over the refresh rate in a pleasing way (especially for special
> > > refresh rates like 72hz: think projector).
> >
> > I am not sure I understand the problem here. What is it again ?
>
> I'm glad you asked. :)
>
> Say I'm playing 24fps content and I have a projector which I'm going
> to run at exactly 72hz refresh. So, for every frame of video, I want to
> show it for exactly 3 refreshes.
>
> To do this correctly, I want to make sure I do my blit safely inside
> a refresh interval to account for some error (it takes time to have the
> frame copied to video memory etc). Say I don't at all know when the
> refresh is occuring (since I have no API for that), and I'm doing my
> blits at _just_ before the refresh all the time. Sometimes I blit and
> the card is in the middle of the refresh, sometimes I blit and it hasn't
> happened yet.
>
> So, say I want to blit before the refresh. Here's a possible
> scenario:
>
> Output Refreshes Blits
>
> 0 Blit 1 [ we make it in before the next refresh ]
> 1 Refresh 1
> 1 Refresh 2
> 1 Refresh 3
> 1 Refresh 4 Blit 2 [ this time, we collide with the refresh,
> 2 Refresh 5 so the card waits for the next one to show
> 2 Refresh 6 our frame ]
> Blit 3 [ we make it again, before the intended
> 3 Refresh 7 refresh ]
> 3 Refresh 8
> 3 Refresh 9
>
> So you can see in this case, frame 1 was shown for 4 refreshes, and
> frame 2 for only 2, instead of the intended refresh-per-frame average we
> wanted of 3. Over time we sometimes make it and sometimes don't, and
> our video output quality suffers.
>
> Tonight I did up some discussion on the effects of 10ms scheduling
> resolution on frame blits. However, the results do assume that we can
> determine when the video refresh occurs so that we can avoid cases like
> the above.
>
> http://www.dumbterm.net/graphics/refresh/
>
> I'll try and do up a similar experiment to show the effects of not
> being refresh-aware.
Ok.
Vladimir Dergachev
>
> --
> Billy Biggs
> [EMAIL PROTECTED]
>
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
