[cairo] JIT for pixman

Soeren Sandmann sandmann at daimi.au.dk
Thu Jan 8 08:24:10 PST 2009

"keita abdoul-kaker" <abdoulk.keita at gmail.com> writes:

> i am interested on working on a JIT for pixman compisiting code
> (http://cairographics.org/summerofcode/ideas/). I have some very
> (very...) early ideas on what can be done and how it should be done
> using the llvm framework.

I consider a JIT compiler for pixman and multithreading in cairo and
pixman the two most important long-term projects right now, so thanks
for your interest in this.

> Is there anyone working on the same topic ?

Besides Dan's jitblit, I know of two other projects that intend to
make a jit compiler for pixman.

One is 'orc', which is a subproject of liboil and maintained by David
Schleef. Here is a description he wrote in an offlist mail from a
while back:

    The goal of orc at the present time is to be an extensible runtime
    compiler.  I originally intended to work on genrender, but I
    accidentally got carried away writing a register allocator, and
    then an MMX assembler, then an Altivec and SSE assembler, etc.

    The general idea is that users of orc will define a kernel that is
    run for each element of an array, using a simple assembly-like
    language.  The list of instructions can either be parsed from a
    file or generated programmatically at runtime.  There will be a
    set of built-in "opcodes", and additional opcodes can be created
    by a library that uses orc, such as pixman.  New opcodes can
    either be macros, that break down into simpler base opcodes, or
    the library can define how to convert those instructions directly
    into machine code.  The opcodes are scalar in nature; being
    restricted to operating only on arrays makes them easy to

    In addition, I intend to add load and store operations that can be
    customized, so that the application can indicate potential
    optimizations such as caching needs, alignment, minimum array

    This is all roughly modelled after CUDA and pixel shaders, as well
    as pulling heavily from liboil and DSP architectures.  The design
    is very restricted on purpose, in order to make it easy for a wide
    range of people to write code that fully uses the CPU.

The code for 'orc' is here:


The other project is my own "genrender", which is here


Genrender started out as an attempt to write a really simple
code-generator that would directly emit machine code with no
additional analysis, but it turned out that register allocation would
either be very low quailty or very complicated, and I realized that
having an intermediate format would allow an interpreter to written,
which would be really helpful for debugging among other things. So now
the intention is to compile an intermediate assembly language with
vector instructions into machine code.

I did look at LLVM at one point, and I think it's a very good project
in many ways. The main showstopper at the time was that it is written
in C++ with STL, which - because GNU libstdc++ is inlining way too
much code - meant that even a simple 'hello world' jit compiler took
hundreds of kilobytes of text.

At the time I think SIMD instructions were only supported as
intrinsics, which basically meant that all the optimizations LLVM does
treat them as black boxes. This means LLVM's vector output was not as
great as it's normal scalar output.

Finally, there is Mozilla's tracemonkey project, which I haven't
looked at closely. I know and like many of the basic ideas in it, but
I'm not convinced they are the right fit for pixman. Also, it may
still be MPL licensed. For pixman, we would need something close to
the BSD license.

That's the state of the art as far as pixman JIT compilers are
concerned. If you want to work on a JIT compiler, don't necessarily
feel like you have to work on any of these projects; if you have
different ideas, doing your own project can be more fun.

> Do pixman have an official maintainer ?

Yes, I am the maintainer of pixman.


More information about the cairo mailing list