David A Kondrad wrote: > Craig, > > I haven't actually tried this, but here's the scoop: > > The davinci driver acceleration is done using a custom kernel module that > you have to integrate into your kernel build and enable in the kernel > config.
You can build it like this: - go to gfxdrivers/davinci (needs to be updated, just did a fix) - edit Makefile.kernel (edit kernel source tree of target in first line) - make -f Makefile.kernel (you should have c64x.ko now) > Then you have to modprobe that kernel module which loads the acceleration > code into the DSP and sets up a shared memory queue between the kernel > driver and the DSP acceleration code. Yep. Here's more info on acceleration: The DSP functions for filling, blitting, blending, converting ARGB->RGB16+A3, stretching, and all other code snippets are tough coded in assembler with the goal to have the minimum number of cycles per pixel using paralellelism where possible. The sploop is really great! Implications and constrains the same ;) But thanks to Olaf Dreesen we might be getting the DSP to burn when almost all units are used at once and all the time. The blend routine is even a bit faster, maybe due to read/write not done on same cycle? Benchmarking 256x256 on 640x464 ARGB (32bit)... Anti-aliased Text 0.112 secs (* 128.571 KChars/sec) [100.0%] Fill Rectangle 2.002 secs (* 36.008 MPixel/sec) [ 4.5%] Fill Rectangles [10] 15.648 secs (* 37.693 MPixel/sec) [ 0.6%] Fill Spans 0.428 secs (* 30.624 MPixel/sec) [ 9.5%] Blit 2.091 secs (* 28.207 MPixel/sec) [ 5.2%] Blit colorkeyed 1.661 secs (* 31.564 MPixel/sec) [ 6.0%] Blit from 32bit (blend) 1.741 secs (* 30.114 MPixel/sec) [ 6.3%] Blit from 32bit (blend) with colorizing 1.738 secs (* 30.166 MPixel/sec) [ 5.7%] Stretch Blit 8.594 secs (* 8.051 MPixel/sec) [ 1.2%] > Denis, please correct me if I'm wrong but: > > The major issue that I see with the acceleration driver for the davinci is > that you can't use the TI Codec Engine and still maintain the driver code > in the DSP because the first the Codec Engine does is wipe the DSP and load > it's own framework and requested codecs. The memory is not the worst problem. I don't know how Codec Engine works. In a very small loop our scheduler compares the ring buffer indices and runs (into) a task or increases the idle counter and does the next comparison. I don't see a chance for Codec Engine to get something of the cake, but I'd wonder if our scheduler could be run as a thread(?) or module(?) in Codec Engine. Does it support (preemption of) DSP tasks? > The obvious solution would be to make a version of the DFB acceleration > driver that fits the codec engine framework so that it can be loaded by > program before initializing DFB and then notifying DFB to use codec engine > calls instead. It seems like a boat load of work it would have to be a > collaborative effort on the part of the DFB dev community to get it > working. Or some hardware, software and € into our direction... Sure it's a boat? Writing a module for the DSP BIOS(?) or LINK(?) is most likely well documented and the interfaces should be clean if not mean ;) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
