RSS/Atom feed Twitter
Site is read-only, email is disabled

OpenCL support in GEGL is almost there

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

3 of 3 messages available
Toggle history

Please log in to manage your subscriptions.

OpenCL support in GEGL is almost there Victor Oliveira 10 Apr 18:04
  OpenCL support in GEGL is almost there johannes hanika 10 Apr 21:12
   OpenCL support in GEGL is almost there Øyvind Kolås 11 Apr 11:29
Victor Oliveira
2012-04-10 18:04:40 UTC (almost 12 years ago)

OpenCL support in GEGL is almost there

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

johannes hanika
2012-04-10 21:12:47 UTC (almost 12 years ago)

OpenCL support in GEGL is almost there

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 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

Øyvind Kolås
2012-04-11 11:29:17 UTC (almost 12 years ago)

OpenCL support in GEGL is almost there

On Tue, Apr 10, 2012 at 11:12 PM, johannes hanika wrote:

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.

It is not surprising that doing a DIY pipeline would give faster results more immediately, for the first few years after I took up maintainership of the then derelict GEGL project my previous graph based full image compositor gggl continued to run circles around GEGL but slowly as GEGL matured it has gotten better - your concerns are due to things that are not completed - contributions are as always most welcome (note that for features like demosaicing GEGL has very naive support currently; and even if someone wanted to port for instance more advanced/alternative demosaicing from Darktable - they would not be able to since GEGL is LGPL).

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

Doing it with a scale node would be slow, using the built in mechanisms to generate mip-maps in GeglBuffer would fast. The plan for GEGL has been to do previews rendering of the current visible scale directly on these mip-map levels; contributions in that area would be most welcome. The support is not complete but hopefully most of the API changes neccesary landed in GEGL 0.2.0 which GIMP-2.8 depends on. GIMP will not be able to make use of such snappier compositing and preview using GEGL until close to the end of the 2.10 cycle when all drawables are native GeglBuffers.

- easy to insert a cache (we cache the input to the plugin the user is currently tweaking for example).

GEGL has had caches in the pipeline; some automatic as well as the ability to forcibly opt in and out of caching.

- we have esoteric pixel formats (bayer patterns, in 16-bit and in 32-bit float, etc.).

GEGL supports any pixel format supported by babl, this includes 16bit and 32bit integer as well as floating point. Demosaicing such bayer patterns is also well within the scope of GEGL.

In the end doing a single chained pipeline processor with GEGL should not be much code and it should end up being fast. It is just taking longer to get there because GIMP has been slow in it's own adoption of GEGL and it seems like most projects prefer to put together the simplest thing that possibly can work and grow their own custom solution from that instead of adopting and helping out with a common infrastructure.

With the recent goat-invasion of GIMP the future for GEGL is brightening up and I have hopes that GEGLs momentum and adoption will finally be increasing and hopefully be able to sustain itself also without me pushing it.

/yvind K.

The future is already here. It's just not very evenly distributed
                        -- William Gibson
http://pippin.gimp.org/              http://ffii.org/
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list