On Wed, May 13, 2009 at 6:08 PM, utkarsh shukla <utk.shukla@xxxxxxxxx> wrote:
> So you are suggesting to parallelize the Gimp image operation means that
> multiple GEGL processes should run at the same time. So currently the GEGL
> has graph manipulation and then the rendering.
> I am not sure how you tried to split the rendering from graph manipulation.
By having a dedicated thread that does the actual processing work, and
reporting that results have finished rendering in the main thread
(which is with the application/GUI/graph manipulation code).
> Dou you mean to say that
> curretnly Gimp first processes the graph and then renders the whole of the
> image afterwards. So if I get a clear overview then what I feel that this
> thing is much different than the GPU thing as here the parallelization is
> needed at much higher level and just very below the Gimp interface infact on
> the interface the things should be parallel threaded. Am I correct??
Not quite sure I understand what you mean. The paralellization in GEGL
should occur within the existing API and be splitting up the workload
into paralell rendering tasks for different subregions of the output
image.
GEGL is a demand driven caching data-flow based rendering system.
First the graph is set up, nodes connected and properties set. Then
either a sink node is processed or more normally like in a GIMP use
case; a GeglProcessor is set up with a full region to be computed.
GEGL doesn't compute all data at once but splits the requested region
into rectangular chunks and processes these chunks in paralell. As
chunks are computed GEGL signals will be emitted on the node reporting
which areas have been computed. Behind the scenes a GeglProcessor
could be doing it's real work in a thread, or even create multiple
GeglProcessors that operate on separate parts of the output in
paralell. Going beyond this, with buffers shared between processes and
hosts it should be possible to extend the processing even further.
After this GSOC I hope to have the means to have a unified memory
architecture for GeglBuffers, at that stage GEGL could perhaps even do
portions of the processing and|or compositing on the GPU (IO will be a
concern in this case).
/Ø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
