Le 14 sept. 08 à 19:14, Øyvind Kolås a écrit : > 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. > 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. > -- > «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
