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

[Aleksey Khudyakov]

On 14 April 2013 02:04, Akarsh Simha <akarshsimha at gmail.com> wrote:
>> 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.
>
> Even with the USNO NOMAD catalog? That is a bit hard to believe,
> although it might be the case. With the USNO NOMAD catalog, KStars
> crawls when zoomed in on Sagittarius.
>
Without. That's valid point. Also how frequently do we need to update horizontal
coordinates? For every star in memory on each time step? If so it's
huge time sink
too.

Another advantage of quaternion approach is immutability. We do not
need to modify
coordinates of star except possibly to account for proper motion. Code
shall become
simpler too


>> 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
>
> Yeah, quaternions are certainly a good idea. Not sure Henry can fit it
> into his time-line?
>
In my opinition it absolutely must be fitted there. If there isn't enough time
drop OpenCL part. Reasons are simple:

 1. We are going to change representation of stars/deep-skyes/whatever
    anyway. Then we should change it to the most efficient one.

 2. It's possible to render sky on CPU with LOT of start. Other people did
    just that. So we should try to get good CPU performance first in order
    to avoid penalizing people which couldn't use GPU for whatever
    reason.

 3. It's not clear that processing on GPU is clear win. Sure even low end
    GPUs are order of magnitude faster. But... if workload maps on execution
    scheme of GPU nicely if we won't saturate bus if any other unforeseen
    problem won't surface.

 4. We could probably hope for 10-20x speedup in ideal case. If we can
    get similar speedup by using right algorithms we should do this. If
    this isn't enough then we need to get big hammer (GPU in this case)