[Kstars-devel] RFC: KStars GSOC: data pipelining and OpenCL.

[Aleksey Khudyakov]

On 14 April 2013 00:21, Henry de Valence <hdevalence at gmail.com> wrote:
> Hi all,
>
> I'd like to propose some architectural changes to the KStars data
> processing pipeline. Generally speaking, this would involve rewriting
> the portions of the code between the data storage (in catalogs) and the
> painting interface so that the functions involved are OpenCL kernels
> that can be executed in parallel on the CPU or with massive parallelism
> (hundreds of "cores") on the GPU.
>
> The steps that KStars must perform on the sky objects before they can be
> displayed on the screen are roughly as follows:
>
> 1.  Precession/Nutation;
> 2.  Equatorial -> Horizontal conversion;
> 3.  Projection to screen coordinates.
>
> Currently, both 1 and 2 are done on the CPU with code that is neither
> thread- nor SIMD-parallel. 3 is also done on the CPU, even in the case
> of the GL backend I implemented three years ago, due to the decision to
> use the legacy direct-mode instead of using OpenGL vertex shaders (as I
> recall, this was motivated by compatibility concerns, but in retrospect
> it looks like a rather poor choice).
>
AFAIR conversions of coordinates is not worst bottleneck. Last time I checked (1
or 2 years ago) drawing of constellation lines and borders and coordinates grid
very much to my surprise. Any proposals to improve performance must be backed up
with profiling/benchmarks. Otherwise it's too easy to fall into trap of
optimizing wrong thing.

Furthermore we can get ~10x performance boost (uneducated guess) by changing
representation of sky point. Currently it's represented by two angles and
conversions between different coordinate systems are quite costly: 5 or 6 calls
to trigonometry functions.

Much more convenient scheme is to store points as 3D vectors with unit norm and
some flag to distinguish between coordinate systems. In this case
transformations between different coordinate systems could be done using
quaternions and are cheap (15 multiplications). So there are no reason to cache
horizontal coordinates, they could be recalculated on the fly if desired.  Most
of the projections also become cheaper since they don't involve trigonometry in
this representation.


This has been discussed on mail list before. You can search using "quaternion"
keyword