[OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

[Clemens Eisserer]

Hi Sergey,

It is quite interesting! But it would be good to check what code was
> affected by this parallelization. I meant we cannot draw much-much faster
> than OGL draw its primitives, so even w/o parallelization if we will call
> flush after each fillRect/etc(mimics the in-place rendering on the current
> thread), we can speed up something but at the end, we will call OGL on one
> thread.
> So executing some code in parallel to the actual OGL rendering we speed up
> the whole benchmark so much! looks like something(code executed in
> parallel) works ineffective.
>

Basically, all the pipeline-code on the java-side can now be executed in
parallel with the actual GL calls:
- rasterization of antialiased geometry
- span/scanline generation of non-antialiased geometry
- queue protocol generation
- pipe validation
- actual RenderQueue protocol generation
- all the locking for each & every primitive

So sure, for GPU limited cases this won't help a lot - however, typical
java2d is usually CPU limited with tons of very small primitives and many
state changes in between.

Laurent has done a few benchmarks with mapbench where a ~30% improvement
was achieved. Not mindblowing, but also not that bad:
https://github.com/bourgesl/jdk/wiki/OpenGL-fix-benchmarks

Best regards, Clemens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210118/dd28e5a6/attachment.htm>