Sign up now! · Forgot password?
RSS/Atom feed Twitter

OpenCL platform

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.

4 of 5 messages available
Toggle history

Please log in to manage your subscriptions.

a64602ee-6de9-c78a-4046-2de... 25 Jan 18:21
  OpenCL platform Øyvind Kolås 20 Jan 17:49
   OpenCL platform Richard B. Kreckel 21 Jan 08:54
    OpenCL platform Debarshi Ray 21 Jan 14:09
     OpenCL platform Øyvind Kolås 21 Jan 14:39
Øyvind Kolås
2019-01-20 17:49:51 UTC (4 months ago)

OpenCL platform

Sorry for the delayed reaction, thank you for the patch which has been integrated in the git repo.

In addition to git/gitlab and infrequently used mailinglist, the developers do chat in the IRC channels #gegl and #gimp on GIMPnet - also used by GNOME on irc.gimp.org

Note that the OpenCL code in GEGL works but multi-core CPU code most often will be faster (in particular in GIMP with lower OpenCL coverage of operations than in the GEGL provided set), thus the opencl / GPU acceleration is most often best left off. I however think OpenCL still is a good fit for GPU accelerating GEGL and hope for future improvements to both GEGL operations and OpenCL platforms.

Richard B. Kreckel
2019-01-21 08:54:01 UTC (4 months ago)

OpenCL platform

On 20.01.19 18:49, Øyvind Kolås wrote:

Sorry for the delayed reaction, thank you for the patch which has been integrated in the git repo.

Great, thanks!

In addition to git/gitlab and infrequently used mailinglist, the developers do chat in the IRC channels #gegl and #gimp on GIMPnet - also used by GNOME on irc.gimp.org

Okay.

Note that the OpenCL code in GEGL works but multi-core CPU code most often will be faster (in particular in GIMP with lower OpenCL coverage of operations than in the GEGL provided set), thus the opencl / GPU acceleration is most often best left off. I however think OpenCL still is a good fit for GPU accelerating GEGL and hope for future improvements to both GEGL operations and OpenCL platforms.

I noticed that, too. And it made me wonder, because on the same hardware Darktable seems to work much faster when OpenCL is enabled than when it is disabled. Any clues what's so different?

-richy.

Richard B. Kreckel
Debarshi Ray
2019-01-21 14:09:51 UTC (4 months ago)

OpenCL platform

On Mon, Jan 21, 2019 at 09:54:01AM +0100, Richard B. Kreckel wrote:

Note that the OpenCL code in GEGL works but multi-core CPU code most often will be faster (in particular in GIMP with lower OpenCL coverage of operations than in the GEGL provided set), thus the opencl / GPU acceleration is most often best left off. I however think OpenCL still is a good fit for GPU accelerating GEGL and hope for future improvements to both GEGL operations and OpenCL platforms.

I noticed that, too. And it made me wonder, because on the same hardware Darktable seems to work much faster when OpenCL is enabled than when it is disabled. Any clues what's so different?

I think that Darktable has a lot more OpenCL accelerated code paths, which means that the pixel data doesn't have to go back and forth between CPU and GPU memory so much.

Øyvind Kolås
2019-01-21 14:39:22 UTC (4 months ago)

OpenCL platform

On Mon, Jan 21, 2019 at 3:10 PM Debarshi Ray wrote:

On Mon, Jan 21, 2019 at 09:54:01AM +0100, Richard B. Kreckel wrote:

Note that the OpenCL code in GEGL works but multi-core CPU code most often will be faster (in particular in GIMP with lower OpenCL coverage of operations than in the GEGL provided set), thus the opencl / GPU acceleration is most often best left off. I however think OpenCL still is a good fit for GPU accelerating GEGL and hope for future improvements to both GEGL operations and OpenCL platforms.

I noticed that, too. And it made me wonder, because on the same hardware Darktable seems to work much faster when OpenCL is enabled than when it is disabled. Any clues what's so different?

I think that Darktable has a lot more OpenCL accelerated code paths, which means that the pixel data doesn't have to go back and forth between CPU and GPU memory so much.

Yes, not all GEGL nodes are OpenCL accelerated (though most of the core set is, however no GIMP GEGL operations are OpenCL accelerated which includes layer blending modes ). In a chain of CPU only operations inserting a single OpenCL capable operation, that operation needs to be faster than cpu_time - (gpu_upload_time + gpu_download_time). If a majority of operations are OpenCL operations, it will start being the cpu implementations that seem to carry the penalty of the data migration cost. For now it is better left disabled for most users due to both performance and stability, during periods of development before GIMP-2.10 was released opencl support was enabled in by default to get wider testing at the penalty of running slower.

The OpenCL operations are also bitrotting lately, they are unaware of non-sRGB based spaces, and do not do grayscale/CMYK generalized processing, the OpenCL code paths
are also not part of mipmap preview rendering, which I think is likely to give the next significant performance boost for GIMP, both for simple layer stacks of point-operations like in GIMP now, as well as with layer effects and adjustment layers. mipmap preview rendering cuts down the number of pixels being processed to the nearest 1/2 1/4 /8 /16 mipmap zoom scale factor and is implemented in base classes of many operations, thus making also the GIMP blend/layer modes have this capability already.