On 6 Sep 2000, Gerd Knorr wrote: > > > I see that the current bttv driver turns the clipping rectangles into a > > > bitmap, then turns the bitmap into a RISC program. It would be more efficient > > > to go directly from a list of rectangles to a RISC program, and skip the > > > bitmap step. When you want to change overlay on a frame by frame basis, this > > > inefficiency really does make a difference. > > > > I didn�t do it :-) > > The bitmap clipping was added after I stopped bttv development. > > Huh? Who wrote it then? /me did'nt, I just optimized it for speed some > day. I havn't touched the RISC code buffer sizes, it is still 16k or so... In bttv-0.4.0, there is no code to generate an overlay sequencer program, it's done in userspace. The userspace code for xtvscreen that comes with that driver uses a non-bitmap method. In bttv-0.6.3, the userspace code from TVscreen.c has been copied into the device driver. There is also a bitmap version, which has been ifdef'd out: /* Why is the new clipping code so slow?? vmalloc?? */ #define OLDCLIP #ifdef OLDCLIP OLDCLIP is the non-bitmap code. To whoever wrote that comment: The new clipping code is so slow because vmallocing an 80k buffer, clearing it, bit twiddling in all the clipping rectangles on top of each other (memory and processor intensive), and then run-length encoding the bitmap, is a whole lot of work. Of course it's slow! 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. > Running out of risc memory should'nt crash the driver throuth, looks like > the outofmem thing has a bug somewhere... It could be that the bt848 crashed the system when given the evil sequencer program a 1-on/1-off stipple pattern would create. Unless you've got a really small window size, there is no way the bt848 can do that kind of overlay pattern. 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.
