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) _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
