[Gimp-developer] GEGL_THREADS

[Øyvind Kolås <pippin gimp org>]

GEGL master can now be thread-accelerated. Different approaches have
been tried; the approach that first yielded promising results was
parallelizing each individual operations process call. Most GEGL
operations now have threading support; some are opted out of the
automatic threading provided by the base classes by setting
operation_class->threaded = FALSE in their respective class_init
functions.

The original plan was making each thread do a full graph processing,
but initial profiling of that approach gave worse results than doing
it individually per op. Doing it individually per op has the added
benefit that each op can be free to use different parallelization
techniques, OpenMP, OpenCL or thread-pool provided by GEGLs base op
classes.

It is not enabled by default yet; since it still might be crashing or
giving wrong results. To test it, run GEGL/start GIMP with
GEGL_THREADS set to the number of threads to use and GEGL_USE_OPENCL
to "no" in the environment (with this threaded processing; we probably
do not want to use on CPU based OpenCL implementations). The full
environment I currently test my GIMP with is:

GEGL_USE_OPENCL=no GIMP_DISPLAY_RENDER_BUF_SIZE=256x512
GIMP_PROJECTION_CHUNK_SIZE=256x512 GEGL_TILE_SIZE=256x128
GEGL_THREADS=2

Some of the ops with ->threading=FALSE in class_init are implemented
in non-thread-safe ways or rely on the wrong arguments for determining
their geometry.

There is room for improvement in re-arranging/adding more local locks
in GeglBuffer. A bigger improvement might be adding new API for
threaded buffer iteration; combined with refactoring of how threading
is done at for point-filter/-composer /-render/transform sub-classes

/pippin

(please continue this thread on gegl-developer-list and not gimp-developer)