[Marble-devel] Review Request: Multi-threaded texture mapping in Marble

[Bernhard Beschow]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101378/
-----------------------------------------------------------

Review request for Marble.


Summary
-------

This patch changes the scanline texture mappers to render textures with multiple threads.
The number of threads is determined using QThread::idealThreadCount().
The patch consists of two commits [1], where the first one refactors and cleans up the texture mappers, whereas the second one introduces the threading.

In the first commit, a class named ScanlineTextureMapperContext is introduced, which holds the state for performing scanline texture mapping. It was factored out of the AbstractScanlineTextureMapper class, which is now named "TextureMapperInterface". Fresh ScanlineTextureMapperContexts are created upon every rendering action, which is cleaner than the former approach of reinitializing all rendering attributes in AbstractScanlineTextureMapper::setRadius(). Finally, the patch constifies many variables in the texture mappers and removes some unneeded code.

In the second commit, threads are used for texture rendering. Almost all rendering logic has been moved into QRunnable implementations, which are recreated for every frame. Since each QRunnable instantiates its own ScanlineTextureMapperContext, the contexts are recreated for every frame as well.

Due to synchronization overhead for tile acces, the patch may cause a small performance regression. I couldn't measure any big difference on a single-core machine, though.

[1] https://github.com/shentok/marble/tree/threaded-rendering


Diffs
-----

  src/lib/AbstractScanlineTextureMapper.h 1998db0 
  src/lib/AbstractScanlineTextureMapper.cpp 8acf57c 
  src/lib/CMakeLists.txt f5d49c0 
  src/lib/EquirectScanlineTextureMapper.h 05e6639 
  src/lib/EquirectScanlineTextureMapper.cpp 8f697cc 
  src/lib/MarbleMap.cpp 6f5f54f 
  src/lib/MercatorScanlineTextureMapper.h a79d1c8 
  src/lib/MercatorScanlineTextureMapper.cpp bdf9b0c 
  src/lib/ScanlineTextureMapperContext.h PRE-CREATION 
  src/lib/ScanlineTextureMapperContext.cpp PRE-CREATION 
  src/lib/SphericalScanlineTextureMapper.h f336282 
  src/lib/SphericalScanlineTextureMapper.cpp 583630a 
  src/lib/StackedTileLoader.cpp b67cb98 
  src/lib/TextureLayer.cpp d98f712 
  src/lib/TextureMapperInterface.h PRE-CREATION 
  src/lib/TextureMapperInterface.cpp PRE-CREATION 
  src/lib/TileLoader.cpp 1b85dda 
  src/lib/TileScalingTextureMapper.h 2c70dad 
  src/lib/TileScalingTextureMapper.cpp 2ec719f 
  src/lib/global.h a5c25fb 

Diff: http://git.reviewboard.kde.org/r/101378/diff


Testing
-------

Here are some numbers of a benchmark using OSM:

I get the following speedups on an Atom N270 (two Hyperthreads):
o globe projection:
  low quality:     ~29 -> ~32 fps
  outline quality: ~20 -> ~25 fps
  high quality:     ~5 ->  ~7 fps
o flat projection:
  low quality:     ~33 -> ~36 fps
  outline quality: ~23 -> ~26 fps
  high quality:     ~7 ->  ~9 fps
o mercator projection:
  low quality:     ~32 -> ~35 fps
  outline quality: ~22 -> ~26 fps
  high quality:     ~7 ->  ~9 fps

Earthwings gets the following speedups for globe projection on an Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz (four "real" threads):
low quality:     ~57 -> ~66 fps
outline quality: ~37 -> ~48 fps
high quality:    ~14 -> ~30 fps

I get about the same results before and after the patch is applied on a single-core machine.


Thanks,

Bernhard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/marble-devel/attachments/20110517/0f2d7488/attachment.htm