Hello,
On 24/01/11 07:03 AM, René Dudfield wrote:
Hi,
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 advantage to LLVM, there is already a Python wrapper to play with. I
could find no ORC equivalent.
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.
I would have to look into that. From what little I've seen, the pixel
stuff is in a separate, optional, library. I don't the pixel library
packaged for Debian.
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.
I look at Python's SVN. A py3k-jit was created, but nothing has happened
there in 7 months. So Unladen Swallow would seem irrelevant to which
back-end, if any, is chosen.
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
I will look at it. One consideration I made after adding the scroll
method to Surface was whether or not to special case shifts where the
surface pitch equaled width * pixel size. I decided not to bother as it
would make shift times more variable. Unless the optimizations can be
made consistent, they may be more of a nuance than anything.
pypy, seems to have near C speed now for some numeric loops. Still
not near SIMD speed though.
http://morepypy.blogspot.com/2011/01/loop-invariant-code-motion.html
I will have a look. But I really don't know what to make of anything
that comes out the the PyPy project.
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.
But will the library support all the blits we may want to do? As it is,
only those blits not supported by SDL are handled internally by Pygame.
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.
At first this would only spit out C code, like orcc. Later it might
generate LLVM assembly language, or even platform specific assembly.
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.
I can't find the VJ tool for freej. But likely if it took a javascript
function it used the javascript interpreter to handle it. By generic
loops I meant a single loop that handle all pixel formats for a given
blit operation, say adding. Of course, the pixel operation could be
handled by a function pointer C call, with the attendant overhead. But
if we could use gcc's Labels as Values language extension it would be
faster. I know, I know; I'm just saying. :-)
Lenard
cu.
On Sun, Jan 23, 2011 at 11:58 PM, Lenard Lindstrom <[email protected]
<mailto:[email protected]>> wrote:
Hi René,
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.
Lenard
On 23/01/11 02:00 PM, René Dudfield wrote:
Hi,
Sounds cool.
have you seen orc? http://www.schleef.org/blog/category/liboil/
cya.
On Sun, Jan 23, 2011 at 8:14 PM, Lenard
Lindstrom<[email protected] <mailto:[email protected]>> wrote:
The problem:
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.
The proposal:
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.
Alternatives:
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.
Lenard Lindstrom
