Hello, >Implementing multi-threading in GEGL is out of my scope and I'm not >even sure if it's in GEGL's scope. I understand that as your project's task is adding OpenGL support. In my opinion, multi-CPU support would be more important, but that is of course another big task/project. > GEGL is pretty low-level and >threading can be implemented on top of GEGL by the relevant client >(i.e. GIMP). I don't understand this. How should GIMP provide threading support for GEGL processors? I mean, if you for instance scale a picture using GEGL, it is one GEGL operation. How can GIMP create multiple threads for this? > Furthermore, be aware that threading doesn't really map >into multiple cores and not using threads doesn't really mean that the >code will not be parallelized[1]. I had a look at Graphite/autopar and can say: Wow! Splitting loops to multiple threads automatically [http://gcc.gnu.org/ml/gcc/2009-03/msg00239.html] is a good thing, but I think it's not true that threads don't map into multiple cores automatically. That's what threads (or processes, when threads are processes with same address space) are for. >I'm not really an expert with regards to how GEGL uses threading >frameworks (if at all) to parallelize tile/rectangle-level operations. I think it doesn't use threads at all and is designed for single-threaded use only... :/ > My work will be concerned with accelerating pixel-level operations by >parallelizing each pixel operation in the GPU. The key in my work is >that all pixel operations should (theoretically) work in parallel. That would indeed be very nice to have. -- Richard H. (via www.gimpusers.com) _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
