Øyvind Kolås wrote: > On Mon, Jun 15, 2009 at 8:12 PM, Patrik Östman<pa.ostman@xxxxxxxxx> wrote: > >> node 1 to node 2. Are there any significant changes of cache >> handling done between 0.0.20 and 0.0.22 or are there a >> setting that must be turned on to get 'per node caches' >> functionality? >> > > The caching policies and mechanisms in GEGL are still basic and rough. > At the moment the GeglOperationClass has a boolean no_cache member > that is checked. Which operation subclasses automatically do cache > have changed lately since the memory consumption of caching every > single node probably outweighs the benefits of caches for every single > node. In particular I think point operations now explicitly do not > cache their results. > > Ive entertained the idea to use special nodes to indicate caches, but > that would to some extent muddle the graph. Perhaps a better solution > is to allow turning the caches on dynamically on demand and not only > define such hints in the class, the existing implementation should be > possible to bend in both ways. > > I've been thinking a while lately what the overall model would be for a redesign of the caching strategy used in GEGL. First of all, I don't think explicit cache nodes would solve that many problems. We would still need a way to propagate invalidation of nodes through the graph to invalidate the cache, and that logic still needs to be on the lowest node level. Furthermore, as you say, only allowing caching in explicit cache nodes will be very cumbersome if one needs to do clever on-demand caching in parts of the graph, and that will be needed in an interactive application with a large graph such as GIMP. For example, when you interactively apply geometric transforms on a layer, you will want to have caching right before the compositor op that composes the transformed layer onto the projection. You will not want to have caches on the compositor ops all the time though because it would cause a giant memory overhead. One caching strategy that I think we will come pretty far with is to handle caching in a wrapper function to GeglOperation::process(). That is, the GeglEvalVisitor would not call GeglOperation::process() directly but instead something like GeglOperation::do_process(). This method would contain common logic for caching. If caching is turned off, it would simply call GeglOperation::process() and not do much more. If caching is turned on, it would not bother calling GeglOperation::process() and instead just return what it has cached. This strategy would also collect caching to a common place instead of spreading it across the GeglEvalVisitor and the GeglNeedVisitor (former GeglCrVisitor). The wrapper function GeglOperation::do_process() would also be a natural place to have logic for turning off the "visibility" or "activeness" of a node. When a node is invisible/inactive, it acts as a gegl:nop and just passes its input directly to its output. That will allow us to easily implement toggling the visibility of traditional layers, and also toggling the "visibility" of layer effects such as a blur or emboss. Another thing worth mentioning is that caches on every node doesn't scale well to concurrent evaluation of the graph since the evaluators would need to all the time synchronize usage of the caches, preventing nice scaling of performance as you use more CPU cores/CPUs. / Martin _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
