[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] speculation: a JIT for Pygame
a few random thoughts below.
Catching up on LLVM, it seems someone has made experimental support for DSP co processors too - such as the SPU and OMAP3 dsp chips found on some mobile devices. This is great since these chips are basically very GPUs - and have been done for tasks as complex as video decoding. Not a very big requirement really... but interesting. note that ORC supports this too. LLVM is available on some platforms automatically(many osx, and linux machines), but would not be there on some platforms. orc seems highly available on linux, but not on other platforms as much.
One nice thing about liboil/orc is that they already support a number of image based routines - since it is used for video software like gstreamer.
Catching up on the unladen swallow project, it seems the project is abandoned for the last several of months. Except they still plan to try to get it into python 3.3 if someone from the cpython project steps up and does the work. http://en.wikipedia.org/wiki/Unladen_Swallow They plan on making it an optional build, but if built into python it would be much more likely to be there with python.
Another interesting JIT technique I've been thinking about for a while is image specific blitters. This could technique could be done in python now. For example, if you detect an image is entirely 255,255,255,0 then blitting that image with an alpha blitting routine is not optimal(a fill could be used). Another common example would be an image which has say a blob of colour in the middle, some semi transparent pixels on the edges, and fully transparent on the sides. The image may be broken up into 4-8 sub surfaces which could then be blit with optimal blitters for each part. Another example is for low colour images. Say an image only has 150 colours in it, then the image could be turned from a 32bit per pixel alpha image into an 8bit RLE encoded image. This could even consider simple techniques like doing a surface.convert() if one has not been done. I kind of touched on this idea here: http://renesd.blogspot.com/2010/03/super-surfaces-for-pygame-in-effect.html
pypy, seems to have near C speed now for some numeric loops. Still not near SIMD speed though.
On the SDL mailing list there is some talk in making blitters a separate SDL library... but I'm not sure if that'll happen. Might be cool if that existed... perhaps in SDL_gfx.
btw, The code generation approach is likely a good one I guess. Maybe it wouldn't be too hard to support multiple backends if needed, given high level descriptions of the blitters.
Also the generic blitter is an interesting idea. The freej VJ tool had a mode at one point where you could enter in a function for a pixel, and it used that for the blitter... not sure how they did it, maybe a simple compiler/interpreter or something.
On Sun, Jan 23, 2011 at 11:58 PM, Lenard Lindstrom <len-l@xxxxxxxxx>
Orc looks interesting. Certainly it needs further consideration. LLVM itself has abstract vector instructions. It can also return a C function that can be called directly.
On 23/01/11 02:00 PM, René Dudfield wrote:
have you seen orc? http://www.schleef.org/blog/category/liboil/
On Sun, Jan 23, 2011 at 8:14 PM, Lenard Lindstrom<len-l@xxxxxxxxx> wrote:
Unlike other image packages, Pygame supports operations on many different
pixel formats: 32 bit pixel with alpha can blit to 24 bit without alpha,
eight bit palette can blit to 16 bit without alpha, and so on. This makes it
cumbersome to add new blit operations, like exclusive-or, and even more
difficult to add a new pixel format.
With the acceptance of PEP 3146 the Unladen Swallow offshoot of CPython will
be merged back into trunk Python sometime around Python 3.3. Unladen Swallow
brings with it a Python JIT powered by LLVM. LLVM is a compiler tool kit
that also provides runtime compilation to machine code. So the idea is to
generate blitters on demand for various pixel configurations with LLVM.
Another possibility is to design as generic a blitter loop as possible, then
include some specialized loops for common pixel formats. Or one could
develop a preprocessor that translates a specialized blit description
language into corresponding C code, much the way Pyrex transforms Python
like code into C. This approach is used to write sound modules for the Lisp
based sound processing language Nyquist.
This is all just far out speculation. It is a long term goal not intended
for the next Pygame release.