On Thu, 25 Apr 2013 11:58:17 -0600 Mike Steinert <[email protected]> wrote:
[snip] > I'm currently using an approach you've suggested here, i.e. a locked > DirectFB surface. I have a git tree if you're willing to take a look at my > progress so far: > > https://github.com/msteinert/cairo/commits/directfb > > I believe the caching details will be left up to the backend that DirectFB > is using using. I'm targeting a Broadcom 7420 where DirectFB is provided as > a high-level interface to their 2D hardware. The implementation is on top > of Broadcom's graphics drivers which handles the caching/flushing/etc. > Perhaps other backends are uncached, e.g. fbdev? I tried to look for some documentation about Broadcom 7420, but it appears to be scarce. This was possibly the best information I could find: http://www.broadcom.com/docs/articles/MPR_11-22-10.pdf And it says "This CPU implements the MIPS32 v2 instruction set with Broadcom-specific DSP and multi-threading extensions." Pixman library (cairo software rendering backend) supports some assembly optimizations for MIPS32r2 and DSP ASE thanks to the ongoing work of Nemanja Lukic. These optimizations may potentially provide some performance improvement on your hardware, but are only enabled for MIPS 74K cores in the runtime detection code: http://cgit.freedesktop.org/pixman/tree/pixman/pixman-mips.c?id=pixman-0.29.2#n68 Tweaking the runtime detection code, you can also enable it on your CPU. I'm a bit worried about the "broadcom-specific" description of the DSP extensions in BCM7420. But it might still make sense to give it a try. Also some of the optimizations (simple blits and fills) in fact do not use DSP instructions and should also run fine on any MIPS32 core. > Damage tracking is a good idea. If I understand you correctly, the surfaces > would track damage and provide an interface so a minimal area could be > computed prior to flipping the display buffer. > > cairo-xlib-render-compositor.c would only be an interesting comparison > > if directfb gained a useful set of acceleration primitives. If it has, > > then you would probably want to write a compositor to first try and use > > the acceleration and then fallback to the damage tracked surface. > > > > For the 2D hardware I'm interested in DirectFB has acceleration for blits > and fills. I've been able to accelerate solid fills so far basing my work > off of cairo-xlib-core-compositor.c. I'll continue down this path unless > somebody has a better idea. Mixing software rendering and hardware acceleration sometimes may not provide the best performance. If you have to do cache flush/invalidate operations too often, they can diminish any benefits of hardware accelerated solid fills and simple non-scaled blits. If you want a fair comparison of the hardware acceleration vs. software rendering backend, using assembly optimized blits and fills (with optimal prefetch, etc.) is quite important. Generic C implementation of blits and fills may be severely underperforming. I have also added pixman mailing list to CC. -- Best regards, Siarhei Siamashka _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
