So can I use the framebuffer driver for the davinci without the c64x.ko? I assume it will not have any acceseration and work as a normal /dev/fb0, framebuffer? Because we are currently using the dsp for some other stuff we can not load it with any acceleration code yet.
Once I have the fb working on our platform. I can pursue the acceleration support. Thanks, Craig On Wednesday 09 January 2008 4:38:24 pm Denis Oliver Kropp wrote: > 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 ;) _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
