[Cuis-dev] VectorEngine performance. Re: Please pull all repos! Re: StrikeFont cleanup

[Phil B]

Juan,

It's been a while since I looked at the VectorEngine code but did you look
into pipes / kernel chaining to see if that would help?  The issue of not
enough compute work to make it worth it is pretty well understood on GPUs
and there are various mechanisms to maximize work that can be done on the
GPU before the CPU needs to get involved again.  Not sure if the latency
issues you were running into were per-frame or per-pixel so this might or
might not help.

While it's great to have the option to run on the CPU, getting something
that can at least optionally run on the GPU would seem to be rather
important given where computing power is these days.  Having an image
running single-threaded on a multi-core CPU and not at least taking
advantage of the GPU where possible doesn't seem very future proof.

Thanks,
Phil

On Tue, Jun 16, 2020 at 11:15 AM Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> On 6/15/2020 6:01 PM, Hilaire Fernandes via Cuis-dev wrote:
>
> Hi Juan,
>
> I noted (not measured I may be biased) an important speed up in the vector
> graphics rendering when I resize the circular toolbar. Do you made some
> optimization?
>
> Hilaire
> Le 12/06/2020 à 17:15, Juan Vuletich a écrit :
>
> I updated many packages due to this change. Please pull all your packages,
> and tell if you experience any problems.
>
> --
> GNU Dr. Geohttp://drgeo.eu
>
>
> Yes. It seems I forgot to tell, I'm sorry for that.
>
> After some weeks, I got a prototype OpenCL version of the VectorEngine
> working correctly. But performance was surprisingly bad, especially when
> comparing to my previous experience with OpenCL in heavy Image Processing @
> Satellogic. I learnt that the task scheduling and kernel startup overhead
> for OpenCL can be rather high, and only payed off if the OpenCL kernel has
> enough work to do to compensate for that. VectorGraphics routines run very
> quick, but there are a lot of calls. So the OpenCL overhead dominates, even
> if running on CPU. This means essentially that OpenCL is not suitable for
> this task. The VectorEngine hierarchy included VectorEngineParallelizable,
> that was a rewrite of the algoritms to best match OpenCL parallelization.
> Given that I will need to rewrite that part in C with SIMD intrinsics,
> these new algorithms I spent months on, are useless. The simpler algorithm,
> with assistance from CPU caches, sould be ok. So I just removed them.
>
> When I originally wrote VectorGraphics, the "default" PC display was 24"
> HD. MacBook Retina didn't exist yet. So, VectorGraphics treats each R, G, B
> subpixel as a different pixel, with a unique position in the screen. This
> allows for maximum image quality on that class of displays. The difference
> in a 24" HD display is quite noticeable. But today, displays with higher
> pixel density are common. On these, subpixel rasterization is no longer
> needed, and, the expense of additional data structures is not worth it.
>
> So, I reorganized the VectorEngine hierarchy. Now there are just two
> classes: One does SubPixel rasterization and the other does WholePixel
> rasterization, both with the simpler algorithm. When using a VM plugin for
> real time Morphic updates, the choice will depend on display resolution or
> user preference. Right now, for TrueType rasterization the SubPixel one is
> used, but for default VectorCanvas, the WholePixel is used. WholePixel is
> about twice as fast, and quality is still quite good for general graphics.
> This is the difference you are seeing. I hope all this is good news for you!
>
> Thanks,
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200616/b123047c/attachment-0001.htm>