On Fri, Mar 26, 2010 at 7:37 PM, Rahmati Fateme wrote:

Hello,
I'm a master's student in computer science at Strasbourg university (France).

I start working on a project related to GEGL library, my goal is to study how to optimize "operators' graph" to reduce execution time.It would be nice if I could  have some information about the optimizations which are already implemented in GEGL.

I would be grateful if you can give me some informations about these questions:

1.   Is there any optimizations done on the graph in the last version of GEGL?

For instance, one could think of several optimizations:

·    Precomputation of node compositions: If you apply several nodes maybe the composition of the nodes is computable and easier to compute.

Lets say that we have two nodes "increase lightness by 10" then "increase lightness by -20", the graph could be automatically simplified to "increase lightness by -10", is it already the case in GEGL ?

Of course one could assume that the application which is using GEGL should not generate such graphs, but maybe for more complicated composition it would be easier to do it in GEGL. For instance, is the composiion of two gaussian blur another "blur" operation ? Another example could be to combine,  Lightness and Curves operations into a single Curves operation with different parameters.

Currently GEGL does not do any extensive optimizations on the graph level, some operations make sure that when the given parameters are a no-op the pixels are not touched but the original buffer passed through (blurs with radius == 0.0, rotations, and scales or translates with no change). The porter duff over (normal layer compositing) op also optimizes to a passthrough when only one input buffer is provided.

Consecutive affine operations (a scale and then a translate) is also collapsed to be a single affine operation (avoiding the inherent loss of multiple resamplings). This is handled within the affine ops by making them all be subclasses of a common operation. Ideally this would be extended in such a manner that GEGL would be able to re-arrange all affine operations to happen only once, immediately after loading the pixel data - this would reduce the number of resamplings as well as reduce total processing time.

·    Precomputation of operators' graphs for several pictures: If you want to apply the same graphs to several pictures it could be nice if some precomputation is done on the graph before it is evaluated on all the pictures.

For instance, given a point operators f which performs the same operation on the different channels of the image (r,g,b) (lightness, contrast, ...), if one is working with 8 bits pictures, one could precompute an array containing f(x) for x in 0->255, and then using this same array for evaluating the graph on all the pictures.

Is it already the case in GEGL ?

GEGL has lazily initialized lookup tables that even work for floating point, doing processing on 8bit image data is best avoided.

·    Evaluation in parallel of several nodes of the graph using OpenMP

There is an experimental multi processing configure option, the paralellization is done by having separate threads compute separate parts of the final render. There is no need to use OpenMP to achieve this.

·    Evaluation of the nodes using GPU, I have read it was the subject of a Google summer of code, what is the current status of this ?

The result of last years summer of code was proof of concept code allowing automatic migration of tiles for GeglBuffers between system memory and GPU memory. Large gains can not be made until many ops exist in a GPU version thus avoiding excessive migrations back and forth.

2.   How the "operator's graph" is maintained and how the nodes are saved?

Can you also give me some references where I could find more related information?

Please study the source code, for further questions please join the irc channel #gegl on gimpnet (irc.gimp.org).

/Øyvind K.

On Mon, Mar 29, 2010 at 4:58 PM, Nicolas Robidoux wrote:

Øyvind (and all):

"Long term" development question:

If one was to try to optimize gegl operations which involve resampling (image rotation, affine and perspective transformations), do you think this should be done on the GPU, or should be done, outside of the GPU, by exploiting SSE-type operations? Any other idea?

Note that multiple other ops will eventually also be using the resampler infrastructure, at least when using C code, among these are displacement maps, mirrors/kaleidoscope (already exist in git), ripples/waves ported from GIMP, mapping to and from polar coordinates and more.

It is likely that such transformations would, at least initially reuse the texture resampling units found in the GPU and thus probably only provide "standard" samplers.

It is not obvious to me that the goal should be to port "everything" to the GPU. Is it obvious to you?

To get the benefits offered by the GPU, at least in a scenario where texture data has to be migrated between the systems, any operations that does not exist on the GPU will slow down GPU based acceleration, potentially to the degree where benefits from using the GPU will be lost.

The approach I think makes sense for GEGL is to allow ops to opt-in to be able to do GPU processing. With the GSOC GPU branch GPU and CPU usage of the same GeglBuffer is transparent and tiles are automatically migrated from RAM to texture memory and back as needed.

What parts of GEGL are more likely to benefit from having a GPU version? Least likely?

Image processing algorithms that are embarassingly parallel will benefit from having GPU versions. This at least includes compositing, with good caching in place it might be possible to do fast gpu recomposition of cached subgraph results from slow/non-gpuable renderings.

/Øyvind K.