> > 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; }