On Sun, Sep 14, 2008 at 5:01 PM, Henrik Akesson [EMAIL PROTECTED] 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.
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.
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.)
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.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
