[Pixman] [cairo] DirectFB

[Siarhei Siamashka]

On Thu, 25 Apr 2013 11:58:17 -0600
Mike Steinert <mike.steinert at gmail.com> 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