On Mon, 8 Oct 2001, Sottek, Matthew J wrote:
> Vladimir,
> The drm _does_ allow the client to mmap the video ram. Of course
I don't want video ram. I want to transfer data from video ram into plain
memory and then access it there - pci reads are way slow.
> there are security reasons to limit this behavior. The X server
> handles the memory management and then sets up drm maps which are
> areas of video memory that can be mapped by a drm client.
> Take a look at the xc/lib/XvMC/hw/i810 code and the drm driver from
> the XFree sources and you can see that I do something very similar
> to what you are trying to achieve. The X server allocates some
> chunks of video memory for use by the Hardware motion comp. engine,
> it then sets up a drm map for this memory. The client (via the XvMC
> library) maps these surfaces and could write to them just like
> direct draw. (In fact to clear a surface or to composite a
> subpicture I use this direct access)
>
> Mark V. and I had talked about using the XvMC protocol to allow
> more general surface allocation and even direct access in some
> specific cases. The problem is that the drm does not handle the
> memory mapping very well as is. You cannot dynamically add a map
> for a specific region of memory and then remove it later, as you
> would need to do on a per surface basis. As with XvMC you can only
> add a map once then allow a client to map the whole region.
>
> It would be possible to extend XvMC to just allow you to map the
> overlay surfaces (for video) as I do with XvMC, which you could then
> directly access as you see fit. In fact the i810 code could already
> do this if you dereference the private pointer in the XvMCSurface
> structure. To make this clean you would just need a function that
> returns an XImage pointer from an XvMCSurface pointer such that you
> get access to the mapped surface without dereferencing void
> pointers.
>
> > Basically I want to DMA a chunk of video ram into plain RAM. This
> >is useful for: video capture, VBI/closed captioning, taking screen
> >snapshots.
>
> I think you are going about this the wrong way. Video capture does
No it's the right way - AIW (All-in-Wonder) cards have a capture engine
built into video chip. So the data arrives right into video ram. The
question is how to get it out of there. Besides video capture you would
also want when making snapshots.
> not need to get video ram into system ram. Whatever application is
> doing the drawing needs to capture before putting the data in video
> ram. If you are using a capture card then you need to have a client
> that reads the data, stores it to disk, then copies it to video
> ram via Xv. (NOT: capture card -> video ram->dma back to system ram)
> Also for cc etc you want to do the blending in the application
It is not about display, it is about capturing.
Vladimir Dergachev
> before putting the data in the video memory. XvMC does this with
> hardware acceleration... just leave out the XvMCRender() call if
> you have no Mpeg to decode.
>
>
> -Matt
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 08, 2001 3:23 PM
> To: [EMAIL PROTECTED]
> Subject: [Dri-devel] Using drm
>
>
>
> After reading documentation (and confirming that I already know all the
> acronyms) and sifting thru driver code I decided to ask on the list, while
> the people who wrote this stuff can still answer ;)
>
> Basically I want to DMA a chunk of video ram into plain RAM. This is
> useful for: video capture, VBI/closed captioning, taking screen snapshots.
>
> I got drm handle, size of the buffer, AGP offset and pointer to the buffer
> in XFree86. What can I do with this ? At the moment I am mostly concerned
> with Radeon AIW AGP, but this will spread to other (non AGP) cards.
>
> The docs seem to indicate that both XFree and client can use this - it
> would be really fabulous if clients could just mmap the buffer.
>
> thanks
>
> Vladimir Dergachev
>
>
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
