Add OpenCL support for processing core algs (and possibly other parts of the core)

[elpaso]

QGIS Enhancement: Add OpenCL support for processing core algs (and possibly other parts of the core)

Date 2018/04/11

Author Alessandro Pasotti (@elpaso)

Contact elpaso at itopen dot it

maintainer @elpaso

Version QGIS 3.4

Summary

OpenCL [1] is a framework for running programs on heterogeneous platforms (in this case we are looking at the GPU in our graphic cards).

The GPU is usually several orders of magnitude faster than a CPU when coming to certain kind of (floating point, vector/matrix math) parallel computations and it is of course specialized in processing raster images and triangles networks (meshes).

The speed boost that is achievable can vary a lot but it can easily reach several orders of magnitude depending ony your GPU.

In my initial proof of concept I just simply ported the 9-cell slope algorithm with a couple of dozens of floating point sqrt atan operations on a 3x3 matrix to OpenCL with no further optimizations and I've got approximately 4x speed gain (which is not bad at all considering that the CPU I compare with is a fast Ryzen and my GPU is a cheap ATI model).

This proposal is all about performances and it will consist in two steps:

• adding the code infrastructure inside QGIS core to (optionally) support OpenCL
• implement OpenCL algorithms for some selected raster core algs (for example slope & C)

It is important to note that OpenCL support will be totally optional (opt-in) through a global option and only available when enabled at build time.

Proposed Solution

I propose to add a new core class QgsOpenClUtils to handle common operations like:

• check for OpenCL device availability
• check for OpenCL usability (support is ok and user opted-in)
• select OpenCL device (for now, multiple devices will not be supported)
• load and build OpenCL programs
• handle errors/exceptions when building OpenCL programs
• read/write from/to OpenCL buffers

The general approach here is that when a class wants to use OpenCL for a particular computation it will need to check if OpenCL is available and enabled and then branch to particular method (or part of it) that will delegate the task to OpenCL.

I would not enforce any particular pattern here: every algorithm (or family of) will decide if and how implement OpenCL routines for some or all of its steps.

I recommend to store OpenCL programs in separate files, the advantages are:

• you do not need to rebuild QGIS if you want to change an OpenCL program
• your IDE will be happy to handle an external file instead of an inline raw string embedded in C++ code

Affected Files

• new QgsOpenClUtils in core
• a few selected processing algs will initially benefit

Performance Implications

This is all about increasing performances: if not enabled at build time or if not enabled in options the algs will behave exactly like the do now without OpenCL.

Further Considerations/Improvements

Python bindings are not a priority for now mainly because you can use the wonderful pyopencl package to handle this in a very pythonic way, but I don't see why in the future we cannot expose the QgsOpenClUtils to Python to make it easier to push/pull data from the internal QGIS storage classes to/from the OpenCL buffers.

Backwards Compatibility

No issues

Votes

(required)

[1] https://en.wikipedia.org/wiki/OpenCL

[nirvn]

Nice to see this QEP popping up so quickly after your exciting tweet.

Could this potentially benefit our hillshade renderer too?

[luipir]

@elpaso Please be patient, I'm not a parallel computing expert... Common operations you listed for the QgsOpenClUtils class can be a generic API for Processing Toolbox to integrate other parallel processing frameworks?

[elpaso]

@luipir I don't understand what you mean with "other parallel processing frameworks", this is only about using OpenCL

[sbrunner]

OpenCL is not a parallel processing frameworks it's the standard way to use the graphical card...

[elpaso]

@nirvn QgsHillshadeFilter: asolutely yes, I didn't consider QgsHillshadeRenderer but the computational part looks like an ideal candidate for an OpenCL program.

[giohappy]

very intersting QEP @elpaso!
@sbrunner, maybe you're confused with OpenGL? OpenCL is not a parallel processing framework, but it offers an API that can leaverage on parallelization (mapping kernels, etc.). Isn'it?

[nirvn]

@elpaso , it'd be great to take that as a primary beneficiary candidate for OpenCL. That'd expand its use beyond processing straight away.

[sbrunner]

@giohappy I don't confused with OpenGL, we almost say the same, I just add that the goal of this API is to use the graphical card. When I say that's not a framework I want to say that we don't have other choice (except CUDA on Nvidia) because it should be implemented by the card drivers.

[nyalldawson]

Some other potential beneficiaries would be the methods in QgsImageOperation (speeding up layer effects) and the distance transform done by the shapeburst fill.

[vmora]

👍

[NathanW2]

Massive +1 for anything that can get us better speed and results.

[rouault]

I've seen on Phoronix a news item about Apple deprecating OpenCL on Mac for their own proprietary thing, and possibly removing it entirely in future releases : https://www.phoronix.com/scan.php?page=news_item&px=Apple-Deprecates-OpenGL-OpenCL

[nyalldawson]

@rouaulti saw that too. It also would affect the qgis 3d (at least until qt upstream use Vulkan and the metal/Vulkan wrapper or some alternative).

But, to be absolutely blunt: OSX is the WORST platform to run qgis on. There's an abundance of qt bugs, the dependency and library system is a mess, and the lack of OSX developers means there's plenty qgis OSX specific bugs. Basically, I don't think we should let our worst platform dictate performance or feature set on our other platforms.

[elpaso]

@rouault @nyalldawson that is bad news (not that I expected any good one from Apple), when I started investigating this topic OpenCL seemed the only technology really cross platform (by design) and stable/old enough to be a candidate for a relatively broad audience, I don't like the idea of adopting a vendor technology like Cuda, and Vulkan seems a bit too much down the road.

BTW I'm open to consider alternatives.