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

[Andreas Neumann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Thanks all for your answers.

My idea was that one could speed up rendering by rendering layers in
parallel (in cores and or cpus). Often, QGIS projects consist of 25 to
100 layers.

As I understand - QGIS, until recently (until Martins new patch) - would
render one layer after the other in the order they appear in the
project. At the end it would do the label placement. Is parallel
rendering already part of your multithreading patch, Martin? Would it be
possible to render individual layers in parallel and then do the
compositing at the end?

Automatic labeling is obviously something that could use more speed -
but I am not sure if this could be done in parallel. I think it is
more a serial process. One needs the previous candidates for new
candidates to test against. But maybe it could be done in parallel with
other rendering and maybe it would run faster on a GPU? Just mere
speculation.

Obviously, raster processing would be a candidate for segmentation and
parallelization and maybe certain interpolation methods that work with a
smaller window of local points and not on the whole dataset at once.

Andreas

On 08/12/2011 01:50 PM, Martin Dobias wrote:
> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJORSQAAAoJELiCsGDopvBCG5YH/iBkRB2eWCH9WDNouSsJMPYX
iI30O6+Ox20v74j9ElDxEta3OdLlvkUMyPd3fqFRl/iDICIdg1ZOv9adOFAxjs54
rlvgJuLhJ/JMv2hWyQuCDyQ+bfdsExkslGUR/IcjOBqv2k9Nluy3/gGU+nxRK8M1
0F5YAbfqIoUKMozjb2sjO8UR02Uoj6EYuP3RJfKJYb4/g+NMXboQfqC7kJzOf8o2
b5ApkPUUR3Qwm0WT4FcrLNEcy8nhe5Ro6OBmhyOj5UEFTpTQFQA9T5gNQeu/iYfK
lKMTwe7VmB88bTozrbypecg/vh3YFLlu/Pt2W2qJbGM69P+HowbCbhIYNw2hps8=
=l7bl
-----END PGP SIGNATURE-----