Hi,

This is the first time I write on this list, so I'll introduce myself briefly:

I've been working/developing for the european space industry for 7 years, but have decided that I want to do SW research, which is why I'm currently doing a Master (to be followed by a PhD).

During this MSc I'm specialising in parallelism.

The second half of this master, (first half of 2009) is a research project. This will be on the subject of optimising image treatment algorithms using different parallel languages/addons such as : - CUDA
- AMD Stream
- OpenMP
- MPI
- the Barcelona Supercomputing Center's Cell/SMP Superscalar

So, now to the point: I'd like to know if you would find it useful if I do and contribute this work on algoritms in GEGL?

Would you have any restrictions on which technologies to use (availability of open source compiler/runtime, size etc...) ?

If it interests you, could you point me towards the algorithms that needs performance?

Regards,

Henrik

Le 14 sept. 08 à 19:14, Øyvind Kolås a écrit :

On Sun, Sep 14, 2008 at 5:01 PM, Henrik Akesson wrote:

Hi,

This is the first time I write on this list, so I'll introduce myself briefly:

I've been working/developing for the european space industry for 7 years, but have decided that I want to do SW research, which is why I'm currently doing a Master (to be followed by a PhD).

During this MSc I'm specialising in parallelism.

The second half of this master, (first half of 2009) is a research project. This will be on the subject of optimising image treatment algorithms using different parallel languages/addons such as : - CUDA
- AMD Stream
- OpenMP
- MPI
- the Barcelona Supercomputing Center's Cell/SMP Superscalar

So, now to the point: I'd like to know if you would find it useful if I do and contribute this work on algoritms in GEGL?

At the moment GEGL is not paralellised beyond usage of SIMD instructions.
The usage of SIMD instructions follows the add-on like approach that you suggest,
this is currently done by having GEGL switch to different implementations of the
core algorithms. A runtime regression testing framework for different implementations
based on the readable C version is on the wish list for GEGL.

I think that this testing framework (and the tests) is indispensable for implementing and maintaining several implementations in parallel. I would even be prepared to do a great part of it myself, as a way of learning GEGL.

With the public API of GEGL as stable as it is now, it would be possible for you to create
an API compatible fork of GEGL where you significantly changed how it worked internally
as well, doing perhaps a subset of what GEGL can do built around other ways of traversing
the data when rendering it. I can imagine such an approach could be potentially easier to
implement some possible ways of parallellising GEGL.

I agree on forking, I will need to have the liberty to change the internals (especially for the streaming part).

The planned approach is to use existing divide and conquer for dividing the rendering task,
and it's dependency graph computation as currently used to segment the work when GEGL is
rendering result pixels. Different parts of the final result would be distributed to rendering slaves
that would be doing the computation for the controlling process. The slaves are planned to be
either on the same machine or on the network. The rendering host will be able to share it's open
GeglBuffers with processes on the same machine or even over the network. The slaves will
be given graphs of nodes to render that have the rendering hosts GeglBuffers as sources and
destinations for rendered data. IO of pixel data will be a potential bottleneck. The way it is planned done is by extending the tiled buffer storage backend to work over the network. (Proof of concept of sharing the same GeglBuffer objects for local processes through a shared swap file is already implemented.)

You astound me! These plans go much further than just an ordinary GIMP usage ! What kind of users are you aiming for with these kinds of features?
To me, this sounds like a lot of work! You have any plans to use an existing framework such as MPI?

Would you have any restrictions on which technologies to use (availability of open source compiler/runtime, size etc...) ?

As long as additional dependencies are optional and are freely available for download and compatible with GEGLs existing licensing, good code contributions are always welcome.

I will have very limited time to put on this until the end of this year because of plenty of courses. Ah, I need to have my tutor's approval, but I'm quite sure she'll agree.

/Øyvind K.