On Mon, Feb 1, 2016 at 10:35 PM, Daniel Rogers <daniel@xxxxxxxxxxxxxxxxx> wrote: >>> * Anyone can do dynamic compilation nowadays with llvm. Imagine >>> >>> taking the gegl dynamic tree, and compiling it into a single LLVM >>> dynamically compiled function. >> >> What exactly do you mean? How is this supposed to work and where is the >> performance advantage if done at runtime? > > To your first question. I made that statement as a counterpoint to vips > turning a convolution kernel into a set of sse3 instructions and executing > them. > > I believe, though haven't proven rigorously, that a gegl graph is > homomorphic to a parse tree of an expression language over images. For a subset of operation this might work, but not for generic ops - that possibly use shared libraries rather than arithmetic in their implementation, an approach that might work out for some of the subset and permit reusing existing infrastructure in GEGL is to recombine the cores of OpenCL point filters/composers and submit one image processing kernel for OpenCL compilation - which for many(/most?) OpenCL implementations would end up using LLVM in the background. This is however different from my complaint of the benchmark comparison - where VIPS is using a 3x3 convolution kernel, and the GEGL code uses gegl:unsharp-mask which is : gegl:gaussian blur + a point composer .. which in turn is a horizontal blur, and a vertical blur + a point composer. Comparing a 3x3 area op with a composite much more general purpose sharpening filter that can do (and already for the parameters provided) would do larger input area as well as by its nature have more temporary buffers is not a proper apples to oranges comparison. Adding a gegl:3x3-convolution (or adapting gegl:convolution-matrix to detect the extent of the kernel) might make GEGL perform closer to VIPS on this benchmark which caters well to VIPS features. I do however not think we should add "hard-coded" 3x3 sharpen/blur ops in GEGL. /pippin _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
