On Sun, Sep 14, 2008 at 5:01 PM, Henrik Akesson <h.m.akesson@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
