> > Depends. Generating the risc code at REQBUFS time means that you'll limited
> > to a fixed set of buffers. Depending on your application it might save you
> > a memcopy() if you can put it _anywhere_ and not only to one of the predefined
> > buffers.
>
> Maybe I misunderstood, I thought you had to call REQBUFS before you could use
> the buffers for DMA?
REQBUF will just allocate "queue slots" in the dma-to-userspace case (which also
is a limit of the amount of userspace memory the driver is willing to lock down
for I/O). One major benefit of dma-to-userspace is that you are *not* limited
to some preallocated, fixed set of buffers. This means you can't do stuff at
REQBUF time. The other point is that you can dma to any memory area (MIT-SHM
memory for example), not just the mmap()'ed buffers.
For mmap()'ed kernel buffers the driver could do the initialitation at REQBUF
time, depending on how he manages the buffer memory.
> > BTW: This is how bttv works today. It will write new risc code for every
> > single frame you are capturing. So it can't be that slow as you can capture
> > full frame rate and have (on fast boxen) still enouth spare CPU time to
> > compress the video in real time...
>
> Ah, well, I can't capture and compress video in real time. I'd rather improve
> the software instead of buying a faster computer.
I don't expect you see a major difference. If you want to benchmark it:
pick up bttv 0.8.x and time stuff with and without the patch below.
warning: patch is untested (should work throuth...).
And BTW: What's bad with the suggested "you can keep stuff cached" hint
flag suggested? The one described in the paragraph you have snipped in the
reply?
Gerd
---------------------------- cut here --------------------------
--- bttv-0.8.10/bttv-driver.c~ Mon Jan 29 22:53:59 2001
+++ bttv-0.8.10/bttv-driver.c Wed Jan 31 22:55:37 2001
@@ -1196,6 +1196,7 @@
if (fh->mapped[frame]->dma->state == GROUP_STATE_IOERROR ||
fh->mapped[frame]->dma->state == GROUP_STATE_TIMEOUT)
retval = -EIO;
+#if 0
/*
TODO: we should keep the kiovec + risc code cached
for some time, for streaming capture it is very likely
@@ -1204,6 +1205,7 @@
*/
bttv_riscgroup_free(btv,fh->mapped[frame]->dma);
fh->mapped[frame]->dma = NULL;
+#endif
up(&fh->lock);
return retval;
}
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
