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 > <[email protected]> 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 [email protected] > 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. _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
