Re: [Dri-devel] Using drm

[<vo...@mi...>]

On Tue, 9 Oct 2001, Peter Surda wrote:

> On Mon, Oct 08, 2001 at 03:54:14PM -0700, Sottek, Matthew J wrote:
> >  The drm _does_ allow the client to mmap the video ram.
> I am not completely sure about this, but as I'm also working on the same thing
> as Vladimir, capturing for ATI AIWs, I think he is talking about mmap-ing DMA
> buffers, not the videoram directly.
> 
> > > 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.
> No he isn't.
> 
> > Video capture does not need to get video ram into system ram. 
> If it is a combo card such as AIW, you indeed need to do that. When you
> instruct the capture board to provide the data, it will appear in videoram.
> 
> > ram via Xv. (NOT: capture card -> video ram->dma back to system ram)
> This indeed is how AIW cards work.
> 
> Back to volodya: I already asked the same question as you about 2 times
> withing last 6 weeks and the result seems to be that neither DRM nor X have an
> interface of doing captures. I'm currently working on a new Xv function
> (XvShmGetImage) that will do this, and also when I see some code from your

I am asking about a different problem - not how to get the data from X to
the client, but how to ask drm nicely to make a DMA transfer. I suspect
(!) that I can simply write the correct values into the registers and the
DMA will happen, but I am not clear about the semantics. For example, is 
AGP Offset the address from the point of view of video card or something
else ? Do I have to subtract framebuffer address from it ? What is the
significance of card specific drm structures ? Why do we need them ? Why
have a separate area for textures ? Can I modify it dynamically ? (so as
not to reserve 1mb chunk of ram for capture buffer). What drm handles are
for and whether there is a small test app that exercises drm interface
from command line (i.e. not inside Xserver or glx client). What do I do
about IRQ support ? there seems to be no mention of it in drm structures,
but there are a number of IRQs that could occur (vsync, hsync, DMA
completion (several different sources, i.e. 4 VIP, textures, command
processor..)) Each time irq happens the handler needs to acknowledge it or
the system will hang (it will keep entering the handler).

Not to mention: how do I behave nicely w.r.t. other DMA transfers ? Lock
them, flush queues, etc. ?

> radeon captures I'll adapt it to r128 and create a new DRM function as well,
> but first I want to have a non-dma function so that I can test it if it really
> works and worry about the speed later. Yes I know memcpy from videoram is slow
> as hell.

Well, it's not that it slow - it is that it ties up cpu. For example do
the following test: x11perf -getimage500. I was recently surprised to find
out that X can do only 4 of these per second (!) when Radeon is running at 
1600x1200@32bpp@85hz (that's on PIV-1.8ghz, AGP card). switching to 16bits
increased the rate to 10 per second. My counting is that 4 are attributed
to less data that needs to go around and 2 to the increased bandwidth
inside the card. Now, with video capture (if you want to get
everything) you want to be getting one field 640x240, 16bpp 60hz in
NTSC. We could (barely) make it if we set the display at something like
1024x768, but it will be cutting close and cpu will be waiting most of the
time for card to stop fetching data for the DAC and pass something to PCI. 

> 
> I imagine that, similarly to r128's new XvPutImage, XvGetImage will try the
> DRM function and if it fails or isn't implemented, falls back to memcpy.
> 
> I think this is the right way to do it: think about a new DRM function that is
> somewhat similar to BlitTexture but the opposite way, implement it on ATI's
> and send a patch.
> 

You are too far ahead. At the moment I just want a hacked Xserver that
does a DMA transfer. Or an Xserver with usermode app that does DMA
transfer - I don't care. As for protocls - yep that's a good idea.. While
you are doing it could you check how hard it is to implement a new
extension ? There are a number of things that don't fit cleanly inside
current Xv and instead of pushing another incompatible change to the API 
we could just make a separate extension and use it quietly.

                         Vladimir Dergachev

> The code inside DMAXvGetImage will look like this:
> drmDMA (blahblah); // allocate buffers
> for (buffer = 0; buffer < buffer_size; buffer ++;) {
> 	drmNewUberCoolCapturingFunction;
> 	memcpy (shm segment for capturing + buffersize*buffer, drm buffer, buffersize);
> }
> drmFree (blahblah);
> 
> Has anyone a better idea?
> 
> Bye,
> 
> Peter Surda (Shurdeek) <shu...@pa...>, ICQ 10236103, +436505122023
> 
> --
>               To boldly go where I surely don't belong.
>