[cairo] JIT for pixman

[Bobby Salazar]

Could someone please explain the benefits of JIT for pixman? I seen a lot of talk about the best ways to approach JIT for pixman, but I so far haven't been able to figure out what the benefits are? Does it yield faster code/better performance for pixman, or easier maintainability?

Thanks!

> -----Original Message-----
> From: sandmann at daimi.au.dk
> Sent: 08 Jan 2009 17:24:10 +0100
> To: souldadguy2 at hotmail.com
> Subject: Re: [cairo] JIT for pixman
> 
> "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
>     vectorize.
> 
>     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
>     size.
> 
>     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:
> 
>     http://cgit.freedesktop.org/~ds/orc
> 
> The other project is my own "genrender", which is here
> 
>     http://cgit.freedesktop.org/~sandmann/genrender
> 
> 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.
> 
> 
> Thanks,
> Soren
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo