You are sort-of correct. Mark and I actually had some discussions about
making a more expanded version of it or another API that was more
generic.

In the implementation for i810 You can allocate XvMC surfaces and then,
if you know where to look. You can access the surfaces directly as
they are mapped into your memory space via DRM. You can then just use
the XvMCPutSurface() to get the surface displayed on the overlay, complete
with Top surface/Bottom Surface functionality and very small latency.

The problem is that while I implemented XvMC by mapping the surfaces
into the clients memory, there is no requirement to do so, and no
generic way to access the surfaces. Plus there is no good way for DRM
to dynamically handle adding and removing mappable areas. So you are
left with a fixed amount of video surface memory mappable by all
clients all the time.

If you actually wanted a direct rendered video solution here is a short
list of missing parts (or at least they were missing last time I looked)

1) Completly dynamic DRM maps. I.e. at any time a video memory area can
be added as a mappable region to the DRM and removed later without
having fixed offsets/ids etc.

2) XvMC(ish) API to allow creation of Video "context" that hides all the
DRM related stuff. Needs to allow you to allocate surfaces by type and
size. Get direct access to the surfaces, and use the surfaces with some
sort of video display device.

I think #1 is the hard one. Last time I checked the DRM drivers were
allocating fixed memory chunks at init rather than dynamically
sharing memory with the rest of the X server at runtime.

-Matt



-----Original Message-----
From: Michel Dänzer [mailto:michel@;daenzer.net]
Sent: Wednesday, November 06, 2002 2:53 PM
To: Billy Biggs
Cc: [EMAIL PROTECTED]; Elladan
Subject: [Xpert]Re: But *why* no vblank?


On Mit, 2002-11-06 at 17:39, Billy Biggs wrote:
> Michel Dänzer ([EMAIL PROTECTED]):
> 
> > > It would be preferable in general for video apps, though, to provide
> > > a DRM-based api to use the overlay buffer, too.  Like, a DRM-Xv.
> > > For desktop use, the X11 context switch may be fairly acceptable
> > > with something like XSYNC, but to achieve really excellent quality
> > > (eg, suitable for output to a TV/broadcast/etc.) in, say, a video
> > > player, a direct API would be nicer.
> > 
> > If I'm not mistaken that's what XvMC is for.
> 
>   No, XvMC is an API to hardware motion compensation, basically for
> hardware MPEG decoding.

Don't let the name mislead you. Sure, motion compensation was probably
the initial motivation, but my understanding from reading posts about it
on Xpert (Mark or someone please correct me if I'm wrong) is that it
supports non-MC surfaces, so it's basically a beefed up Xv which
supports MC and direct rendering.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to