[PATCH] Ensure blitter quiescience before reading pixels from the framebuffer

[Dan Amelang]

On 8/4/07, Bernardo Innocenti <bernie at codewiz.org> wrote:
> Dan Amelang wrote:
>
> > At the X dev conference next month, I'll be presenting jitblt, which
> > might solve your slow 16bpp problem. It's basically a pixman "backend"
> > that JIT compiles specialized fast paths for any given format. Since
> > both cairo and X use pixman for software compositing, jitblt-pixman
> > should get you a boost across the board.
>
> This is very good news!  Is the code available somewhere?

Mailing list:

http://vpri.org/mailman/listinfo/jitblit

pixman git repo (in the jitblt branch):

git://people.freedesktop.org/~dan/pixman

Follow the instructions in the jitblt/README file to build it.

I should point out that on ARM architecture, the code generated by
jolt (the code generation library I used) doesn't perform well
(...yet; talk to Ian Piumarta about that). x86 and PPC are supported
well.

> Carl may want to correct me on this, but I thought Cairo does not fully
> support 16bpp rendering and will keep submitting 32bpp pixmaps to X even
> when the screen is 16bpp

Using the xlib backend, cairo handles 16bpp surfaces well (for the
most part). If you want a 16bpp image surface, you have to tweak it a
bit. A couple months ago, Dave Hill submitted some patches that do
exactly that. There were no comments from Carl about them, though, so
I don't know if increasing the number of supported image format is
ever going to happen.

> I guess 16bpp in r5g6b5 is probably unsuitable for Cairo because
> of the missing alpha channel.  The Geode GPU also supports an
> r4g4b4a4 mode, but it's not supported in the driver and, as far as
> I know, totally unsupported all over the rest of Xorg's code base.

AFAIK, the missing alpha channel doesn't make it "unsuitable" for
cairo. Cairo used to support r5g6b5 image formats quite well. Support
for it was dropped just in the last year. I don't remember the exact
reasons, but I don't think the decision was set in stone.

Regarding r4g4b4a4: one of the nice things about jitblt is that it
takes 1-10 lines of code to add another pixel format (it should really
just be 1 line of code, but I haven't got around to making that
happen). But you still have the problem with the fact that pixman
doesn't even have r4g4b4a4 in its format enumeration, and the driver
problem you mentioned, etc.

> > I'll be visiting the OLPC offices later this month, so I can bring a
> > jitblt-enabled OLPC with me if you or Jim or whoever might be
> > interested.
>
> Looking forward to meet you!  I'm currently in Italy, but I'll be back
> at the OLPC offices on August the 8th.

I'll be there Aug. 21, so let's plan to meet in person then.

Dan