On Fri, 19 Oct 2001, Billy Biggs wrote:
> [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>
> > > If we had the vsync as an interrupt (/dev/vsync or something),
> > > then quality would increase with less system load! Very nice!
> > > But SCHED_FIFO would still be needed to guarentee accurate blits.
> >
> > The other approach is to have a device which you mmap and write your
> > frames into. Then you issue an ioctl and the driver DMAs the buffers
> > at the next available opportunity.
>
> Yes, you could make a cool API to solve the issue. It would be really
> neat. My only concern would be the difficulty of implementing it with
> consumer video cards. Ideally I'd want 'here's a frame, blit at time X'
What do you mean "consumer video cards" ? I was talking about ATI cards -
l let's see: mach64, Rage Pro, Rage128 and Radeon. A good portion of
notebooks (I would guess at least 50% - just by looking at which
manufacturers use which chips) made uses these and a fair number of
desktop systems.
> 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 !
>
> > > Check out deinterlace.sf.net (aka dscaler.sf.net). [...]
> >
> > How big are the cpu requirements ? This is something that is quite
> > useful, because, at the moment, v4l does not allow to convey such
> > information as field parity..
>
> Not sure yet. For v4l, I assume all frames are top-field-first. v4l2
> provides field parity information, and I'm getting flamed on the
> video4linux list to switch to it.
>
> > One thing - did you try your dvd player with recent ATI drivers ? ATI
> > can doublebuffer frames switching them automatically on vsync. If you
> > still see the issue you are worried about something is wrong with our
> > drivers - I'd appreciate a lot if you could write a test up to debug
> > the issue. (or a test mpeg stream)
>
> 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 ?
Vladimir Dergachev
>
> --
> Billy Biggs
> [EMAIL PROTECTED]
>
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
