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

[Laurent Bourgès]

Hi Clemens,

I read again the source code and wanted to add metrics like wait_ratio and
make some new heuristics to auto tune the buffer capacity.

I was also tempted to rewrite the buffer overflow strategy: swap buffer or
use a larger one...

Apparently you made another approach (double buffer) to reduce the wait
latency in awt threads... and allow gl thread to run concurently: excellent
!

Le dim. 17 janv. 2021 à 13:11, Clemens Eisserer <linuxhippy at gmail.com> a
écrit :

> Hi Sergey,
>
> > The design is a little bit different, the XRender pipeline:
> >   - Many threads which call draw operations and sends them to the XServer
> >   - The XSerever decode the the draw operation and push the commands to
> the "opengl buffer"
> >   - Some video driver code which decode the ogl buffer and actually draw
> something
> > The OGL pipeline
> >   - Many threads call draw operations, and save them in the internal
> RenderQueue buffer
> >   - One RenderQueue thread decode the the draw operation and push the
> commands to the "opengl buffer"
> >   - Some video driver code which decode the ogl buffer and actually draw
> something
>
> So in both cases producers (application threads) and the consumer are
> decoupled via some kind of queue (unix domain socket for x11, in-memory
> queue for the renderqueue) and in theory could operate concurrently.
>
> > I am not sure that it work that way, the only way to block the queuing
> thread is to call "flushNow()", for other cases it should not be blocked.
> > The OGLRenderQueue thread however could became blocked every 100ms.
>
> Since there is only one RenderQueue+Buffer, the entire queue has to be
> locked while the commands are processed by the RenderQueue-Thread (via the
> AWT lock held by the thread which is implicitly calling flushNow triggered
> by a full buffer).
> This serverly limits parallelism - you can either process commands
> (RenderQueue thread) or queue new commands (AWT threads) but not both at
> the same time.
> This lead me to the original question - whether this was a necessity
> caused by structural requirements/limitations or whether it simply hasn't
> been thought through / implemented.
>
> I did some prototyping of a double-buffered renderqueue (no other changes)
> over the weekend and results are really promising (1x1 fillRect to measure
> pipeline-overhead, 20x20 aa oval to get an impression data-heavy buffer
> interaction):
>
> Test(graphics.render.tests.fillRect) averaged 1.4837645794468326E7
> pixels/sec
>    with !antialias, to VolatileImg(), ident, SrcOver, single, width1, 1x1,
> !clip, bounce, Default, !xormode, !alphacolor, !extraalpha
> Test(graphics.render.tests.fillOval) averaged 3.896264839428713E7
> pixels/sec
>    with !alphacolor, SrcOver, 20x20, Default, antialias, bounce, !xormode,
> to VolatileImg(), !clip, width1, !extraalpha, single, ident
>
> whereas the original JDK with OGL yielded:
>
> Test(graphics.render.tests.fillRect) averaged 5061909.644344761 pixels/sec
>    with single, 1x1, SrcOver, !extraalpha, bounce, Default, !xormode, to
> VolatileImg(), ident, !alphacolor, width1, !antialias, !clip
> Test(graphics.render.tests.fillOval) averaged 1.0837940280832347E7
> pixels/sec
>    with single, 20x20, SrcOver, !extraalpha, bounce, Default, !xormode, to
> VolatileImg(), ident, !alphacolor, width1, antialias, !clip
>
> and with XRender:
> Test(graphics.render.tests.fillRect) averaged 2.5252814688096754E7
> pixels/sec
>    with ident, to VolatileImg(), 1x1, !clip, !extraalpha, width1,
> !alphacolor, Default, single, bounce, !antialias, !xormode, SrcOver
> All test results:
> Test(graphics.render.tests.fillOval) averaged 2.53725229244114E7 pixels/sec
>    with ident, to VolatileImg(), 20x20, !clip, !extraalpha, width1,
> !alphacolor, Default, single, bounce, antialias, !xormode, SrcOver
>

Could you share your patch to let me study it and try improving it ?

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210117/7b3b45d6/attachment.htm>