On Thu, Sep 20, 2001 at 01:30:52PM -0700, Mark Vojkovich wrote:
> Then the client API would be the same as XvGetStill but would use
> an XvImage as the destination instead of a Drawable.
Er, not quite. XvGetStill seems to have a Drawable as a source and Port as a
destination. What I want is to have Port as source and XvImage as destination.
But I think thats what you meant.
> That's a fine API addition. Having the Bt829 copy the data to system memory
> has implemenation issues though. Kernel support is required to make sure
> the XvImage is swapped in and locked down while the hardware dumps data to
> it. That's primarily why something like that hasn't been added.
Yes I understand, however kernel support is not necessary in that large scale.
I planned to implement it on r128 similarly than I did it with XvPutImage. The
data won't be transferred into XvImage at first, but into DRM buffers, and
memcpy-ed from them to XvImage. My tests show that this extra memcpy causes
CPU load of less than 1% on DVD-sized videos (720*512*16bit*25fps = approx
18MB/s) on my Duron 650, which is imho negligible.
Of course this would require an addition to DRI definition as well because
such a thing (DMA from videoram to RAM) hasn't been done yet. Fortunately ATI
was so kind as to accept me as an official developer and since a couple of
hours I have access to the hardware docs. Another developer from gatos project
is trying to do a similar thing and we'll cooperate on doing "something". I'm
already on my way to persuade DRI developers to add a new function for this
DMA transfers as well.
However, my first implementation will definitely be without DMA (just a simple
memcpy), to see whether it works or not. Perhaps it will actually be good
enough on my AIW to be usable, but for radeon DRM is definitely needed, the
developer I mentioned told me standard memcpy can't transfer data fast enough
on his computer.
I have source of 4.1.0 on my box, I will try to add this XvGetImage function
and try a non-dma implementation for my r128, perhaps even adapt a video
grabbing proggy to use it and will report my results then. I think that this
non-drm implementation shouldn't be that difficult.
> Mark.
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
three saints: looser & lamer & hacker
PGP signature
