[Qgis-developer] Using the power of GPU/OpenCL

[Benjamin Ducke]

Hi All,

As was stated before,
the real art about making use of OpenCL is not so
much learning the API, but understanding how
to parallelize your algorithms. One of the big
challenges therefore is that you need to learn
OpenCL and parallel programming in -- well --
parallel!

Essentially, whenever you see a chance to process
data in segments, and don't have to process all of
it in one go, there is a good chance that you
can get major speed-ups out of OpenCL. I would think
that this applies to a lot of raster processing.

Luckily, there is (finally) a thorough
and very understandable text book coming up:

http://www.manning.com/scarpino2/

This has all the information on the topic 
in one place. It's been written with C/C++
coders in mind. I have been part of the review
process for this book, so don't take my recommendation
as unbiased!

OpenCL, btw., is not just for GPUs. It is a parallel
programming framework that also covers (multi-core)
CPUs, so it can fallback on those boring things if
no GPUs are available. In that case your code
might suffer from (minor) API overhead, but it should 
not be necessary to have separate versions of the code.

Cheers,

Ben

----- Original Message -----
> Hi Andreas
> 
> On Fri, Aug 12, 2011 at 11:28 AM, Andreas Neumann
> <a.neumann at carto.net> wrote:
> > Hi,
> >
> > Now that Martin is including Multithreading Support, I am also
> > wondering if
> > it would be feasible to also profit from the computing power of GPUs
> > and libraries, such as OPENCL. Seems like mobile devices, servers
> > and regular
> > desktops would benefit. Would the Qgis architecture allow the usage
> > of OpenCL?
> >
> > I am not a dev, but am reading about these new technical options ...
> 
> Given that more and more computers come with powerful GPUs it really
> makes sense to explore what are the possibilities for speed
> improvements. In general you can either use a library that implements
> some algorithms on GPU or you can start writing your own GPU code for
> the algorithm (or some parts of it).
> 
> The speedup will vary greatly depending on the algorithm. Things like
> 3D rendering, image processing, video compression etc. are perfectly
> suited for GPU implementation because one computationally intensive
> routine is used in parallel for millions of independent pixels.
> However many other algorithms will not perform better on GPU. These
> are typically the ones that are not parallel or their bottleneck is
> not in computation - many algorithms have bottlenecks in I/O or they
> need to wait for some resources.
> 
> First we would have to identify what is slow and should be optimized.
> Then do some profiling to find out in what parts most of the time is
> spent. If those parts are computationally intensive and parallelizable
> then it is a candidate for GPU implementation. My impression is that
> there are very few places in QGIS where we would gain performance with
> GPU because typically we delegate computation to underlying libraries
> and/or the slowness is caused by I/O. And various pieces of
> functionality are slow just because inefficient or naive algorithms
> are used.
> 
> When implementing an algorithm on GPU we still would need to provide
> original implementation if no OpenCL-capable device is found. So this
> adds additional burden on maintainance to ensure that both CPU and GPU
> implementations give equivalent results.
> 
> To summarize: yes, it would be possible to use GPU for some tasks, but
> GPU is not a magic wand. Computationally intensive tasks really can be
> improved (even by factors of 100), but many other tasks would not get
> faster.
> 
> What are the areas where you think QGIS should be faster?
> 
> Martin
> _______________________________________________ Qgis-developer mailing
> list Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.