Re: [Gegl-developer] OpenCL support in GEGL is almost there
- From: johannes hanika <hanatos gmail com>
- To: Victor Oliveira <victormatheus gmail com>
- Cc: darktable-devel lists sourceforge net, gegl-developer-list <gegl-developer-list gnome org>, gimp-developer-list gnome org
- Subject: Re: [Gegl-developer] OpenCL support in GEGL is almost there
- Date: Wed, 11 Apr 2012 09:12:47 +1200
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 gmail com> 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 gnome org
http://mail.gnome.org/mailman/listinfo/gegl-developer-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]