hey! good news, and congrats on putting it into gimp. actually darktable's pixel pipeline was based on gegl as the project started (you'll still notice some #ifdef HAVE_GEGL if you look around the code closely). that was 2-3 years ago and at that time it turned out a simple DIY pipeline was a lot faster, to a point where it just didn't seem practicable to use gegl. that said i love the clean gegl api and would totally love to see dt/gimp use the same rendering api and have some compatible interchange format. i guess the biggest issues back then were: - processing the image as a whole, not just the region of interest at the currently visible scale. darktable pre-downsamples and processes only these pixels (comes with issues, mostly works fine). - i had the feeling that even resampling the image to these small tiles came with a huge overhead - we have plugins that need filter radii of 128px or more. so tiled processing is hard to make fast. these are some crucial features for us: - needs to be fast (1Mpix < 100ms if possible, our equalizer is on the limit). that's because we always process the whole pipe potentially, might be 20 active plugins and you want interactive feedback. - easy to insert a cache (we cache the input to the plugin the user is currently tweaking for example). - i mentioned the large filter radius overlap thing before. mostly for bilateral filtering (reasonable filter size might be ~30% of the image width) and the edge aware wavelets. - we have esoteric pixel formats (bayer patterns, in 16-bit and in 32-bit float, etc.). - we have huge problems with memory usage. also our opencl support is great, fast, stable, and doesn't need to be there compile-time. which makes it easy for users to fall back to the cpu code path, which in practice happens for every system or driver update.. so i guess i'm saying the cpu codepath is very important to us, too, and we spend some considerable time optimizing it (threading/sse and such). cheers, jo On Wed, Apr 11, 2012 at 6:04 AM, Victor Oliveira <victormatheus@xxxxxxxxx> wrote: > Hello everyone, > > I'm a GEGL developer and I've been working since last year implementing > OpenCL support in GEGL. We have for now: > > - An API to write OpenCL point and area operations > - A way to share image data between operations in the GPU (so we don't have > to bring the image back and forth the CPU for each operator) > - +20 GEGL operations have OpenCL support already > - It's fast > - It's been included in GIMP 2.8RC1 > > Darktable has its own OpenCL support code (which is pretty good, by the > way). I'd like to start talks to avoid work repetition in both programs and > to make an argument pro-GEGL use in Darktable :) > > bye! > Victor Oliveira > > _______________________________________________ > gegl-developer-list mailing list > gegl-developer-list@xxxxxxxxx > http://mail.gnome.org/mailman/listinfo/gegl-developer-list > _______________________________________________ gegl-developer-list mailing list gegl-developer-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gegl-developer-list
