Please note that this section applies only to i810fb. The i810fb-lite version will not support the gfxdriver. However, you can still use DirectFB in software fallback mode with i810fb-lite. Also, DFB-0.9.9 changed the formatting of options in which some requires that it be prepended with --dfb :. For example, the --no-hardware flag, must be set as --dfb:no-hardware . Modify the instructions as needed.
The Intel(R) 810/815 driver should be compatible with most applications that run on top of the framebuffer device, including DirectFB. DirectFB is an interface layer which provides standard drawing functions and special effects such as alpha blending, alpha modulation, color-keying, etc. This runs on top of the framebuffer device, and as long as the device is VESA compatible, or the framebuffer driver is compatible with version 2.4 of the API, you would be able to run DirectFB in software mode. Currently, ports of various toolkits/libraries have been written for DirectFB. These would include OpenGL, GTK+, SDL. Various applications have also been written for DirectFB. Please visit their website for more information.
To directly access the hardware itself, DirectFB provides hooks for specific chipset drivers. Currently, DirectFB already has support for Matrox(R), ATI(R), TDFX(R), nVidia(R) and NeoMagic(R) cards. At present, I'm currently developing an i810 driver for DirectFB as well. Please note that even if DirectFB runs on the i810/i815 framebuffer device in software mode, you would still get respectable performance. The main reason is that the actual framebuffer memory is the System RAM itself, thus the bottleneck of writing to the PCI/AGP bus is avoided. In fact, even with acceleration, the i810 does not provide that much increase in performance as you would normally expect with other video chipsets. So, don't even dream of comparing the i810 with the nVidia(R), ATI(R) and Matrox(R) cards.
Current Drawing Support
Fully Accelerated: FillRectangle, Simple Blit, and Blit with colorkey
Pseudo-accelerated: This is combined software and hardware. DrawRectangle and FillTriangle
Full Software: The rest, and functions that utilizes special “effects”.
Grab DirectFB-0.9.8 from the DirectFB site.
Untar the package somewhere in your system
Get DFB-0.9.8-i810fb-0.0.xx.tar.bz2 from the i810fb Sourceforge Project Site and untar the package. Within the tree is the patch file. Apply the patch.
Once you've applied the patch, just compile the source, and i810 support will be included with DirectFB.
Get the "example" demo programs from DirectFB site too. This is a collection of demo programs that demonstrates the capabilities of DirectFB. It also contains a benchmarking program, df_dok.
Compile the "example" package as you would compile any package.
Copy fb.modes (found in the DirectFB-0.9.8 top directory) to /etc. This is a collection of video modes that directfb can use. Most, if not all of the modes should be supported by the i810 framebuffer driver. Just make sure you enable the 'use VESA GTF for Video Timings' option in your kernel configuration.
Then make sure you have /dev/psaux or /dev/ttySx so you can have mouse support. Kill gpm for now, if you have it.
Once you have patched the DirectFB source tree, there's no need to patch it again.
Grab the updated i810 gfxdriver package from the Sourceforge Project site.
Untar the package somewhere
Copy the pertinent files
cp untarred/package/DFB-0.9.8-i810fb-x.x.x/gfxdriver/i810/* ./
This part should provide you with some information on how to get the best out of the driver (not much, though). Run a few baseline benchmarks in software mode (df_dok --no-hardware), then run df_dok with i810 support (df_dok) and check the numbers. You'll note that some functions are faster in software than in hardware. It's a bit complicated to explain, so I'll leave it for now.
There are extra options for the i810 framebuffer driver that will affect the performance of DirectFB. One of them is nosyncpan. Try running df_andi. With this option, the graphics device will disregard the vertical retrace when updating framebuffer contents. You can enable this to maximize performance.(Note: nosyncpan will work only if the 'render' option is enabled). Another is render. The render option will enable 'memory tiling' which makes it easier for the device to access pixels in a more localized manner. This will actually increase performance of DirectFB running in software mode, but slightly degrade performance of DirectFB when using accelerated drawing functions. Actually, some of the software-only functions are really boosted up by 'render', sometimes to around 70%. So take your pick.
After doing all the above, you may want to get more information on how the driver is performing. First of all, you must compile DirectFB again with debugging enabled (./configure --enable-debug). Run the benchmark program again, and when you exit, you should be able to see some statistics on how the driver performed. Concentrate on IDLE wait cycles per i810_wait_for_blit_idle call, BUFFER wait cycles per i810_wait_for_space call and cache hits.
This measures the number of CPU cycles which are spent waiting for the graphics engine to finish. This is dependent on how fast the graphics device is, and how fast we are giving data to the graphics device, which in turn is dependent on the efficiency of the software giving out instructions, and the size of the buffer itself. The slower the device is, or the higher the number of data received, the higher will be the wait cycle. You want this number to be as low as possible.
This measures the number of CPU cycles spent waiting for the buffer to empty just enough so we can transfer to it the next batch of instructions. Again, this is dependent on the speed of the graphics device, and the size of the buffer. The smaller the buffer is, or the slower the device is, the longer is the wait time. You want this number to be as low as possible.
This is the percentage of the number of times the driver was successful in requesting buffer space without having to wait, divided by the total number of requests. We want this to approach 100%.
The ideal combination (when the bottleneck is not in the graphics device, but in the CPU) is zero wait cycles , and 100% cache hits. Unfortunately, it's difficult to achieve this ideal combination with this chipset. You may try to increase or decrease the buffer size (see Directfb-0.9.8/gfxdrivers/i810.c on how to change buffer sizes) to see the effect. If you limit the buffer size, you will decrease idle waitcycles, but increase buffer wait cycles and decrease cache hits. If you do increase the buffer size, you can get 100% cache hits and zero buffer wait cycles, but the system might waste CPU time waiting for the graphics engine to finish (idle wait cycles). Once we approach 100% cache hits, and very high IDLE wait cycles, we may have maxed out the performance of the chipset relative to the CPU. It's, time to get a real video card :)