Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add OpenCL support for processing core algs (and possibly other parts of the core) #121
QGIS Enhancement: Add OpenCL support for processing core algs (and possibly other parts of the core)
Author Alessandro Pasotti (@elpaso)
Contact elpaso at itopen dot it
Version QGIS 3.4
OpenCL  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
This proposal is all about performances and it will consist in two steps:
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.
I propose to add a new core class
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:
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.
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
@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.
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
@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.
@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.