On Fri, Mar 26, 2010 at 7:37 PM, Rahmati Fateme <ftm.rahmati@xxxxxxxxx> 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.
--
«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
