Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
elpaso opened this issue Apr 11, 2018 · 14 comments
Open

Comments

@elpaso
Copy link

@elpaso elpaso commented Apr 11, 2018

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

This comment has been minimized.

Copy link

@nirvn nirvn commented Apr 11, 2018

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

Could this potentially benefit our hillshade renderer too?

@luipir

This comment has been minimized.

Copy link

@luipir luipir commented Apr 11, 2018

@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

This comment has been minimized.

Copy link
Author

@elpaso elpaso commented Apr 11, 2018

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

@sbrunner

This comment has been minimized.

Copy link

@sbrunner sbrunner commented Apr 11, 2018

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

@elpaso

This comment has been minimized.

Copy link
Author

@elpaso elpaso commented Apr 11, 2018

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

@giohappy

This comment has been minimized.

Copy link

@giohappy giohappy commented Apr 11, 2018

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

This comment has been minimized.

Copy link

@nirvn nirvn commented Apr 11, 2018

@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

This comment has been minimized.

Copy link

@sbrunner sbrunner commented Apr 11, 2018

@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

This comment has been minimized.

Copy link

@nyalldawson nyalldawson commented Apr 11, 2018

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

@vmora

This comment has been minimized.

Copy link

@vmora vmora commented Apr 11, 2018

👍

@NathanW2

This comment has been minimized.

Copy link
Member

@NathanW2 NathanW2 commented Apr 12, 2018

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

@rouault

This comment has been minimized.

Copy link

@rouault rouault commented Jun 14, 2018

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

This comment has been minimized.

Copy link

@nyalldawson nyalldawson commented Jun 14, 2018

@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

This comment has been minimized.

Copy link
Author

@elpaso elpaso commented Jun 15, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.