Gerd Knorr wrote: > > > So, somewhere between 0.4.0 and 0.6.3 someone made a bitmap version. And > > somewhere after 0.6.3 and the kernel driver it was made the default and the > > non-bitmap version was removed. > > Someone (Alan?) wrote the bitmapped version for the kernel and Ralph merged > it back into bttv 0.6.x (and probably added the comment about it being slow). > > As I started porting bttv to the new i2c layer and maintaining the 0.7.x > versions one of the first actions was to kill one of the two clipping > code versions. I decided to go with the bitmapped version because the > code was robust and easy to understand. As the clipping usually does'nt > change that often performance is'nt that critical IMHO. Also the bitmapped > clipping code is much faster in current versions than in 0.6.x. > > > As Alex Bakaev said, there is no need for the risc buffers to be contiguous. > > The kernel could allocate a small 4k buffer for each field's program. If the > > buffer fills up, allocate another 4k and chain the program from the first > > buffer to the next with a JUMP instruction. > > Maybe I do it this way some day. I plan to rewrite the risc code generation > and capture handling completely. There is alot of historical cruft in the > driver which predates the v4l API. Also the kernel has much better support > for PCI DMA these days (see kiobufs + dma-to-userspace, see > Documentation/DMA-mapping.txt, have a look at btaudio.c). I think the ugly > memory handling code can be killed now. > > Gerd Just a quick comment on this thread: (from the bt848 pdf) "WRITE, WRITEC and SKIP ... control the sequence of packed data written to target memory on a byte resolution basis." So there are no problems doing byte-aligned clips. I have tested this myself (with bttv2), and it works perfectly (single pixel wide clips, that is, but you obviously only get a small piece of the image before running out of RISCMEM). I seem to remember looking at bttv's clipping code once, and (at least at that stage), there were a number of possible RISC memory overflows. -justin
