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

[Clemens Eisserer]

Hi,

With solid OpenGL support on Linux being ubiquitous these days and the
XRender pipeline being a bit of a dead-end (works quite well except
MaskBlit/MaskFill/BufferedImageOps), I was looking a bit into the
state/performance of the OpenGL pipeline.
Specifically why it performs sometimes worse compared to XRender, despite
almost all XRender implementations are running on top of OpenGL these days
anyway (except proprietary nvidia).

1. One area where XRender is having an advantage is implicit parallelism.
While Java is producing X11 protocol, the XServer can concurrently perform
the drawing operations running on a different core.
Therefore when running some Swing benchmarks with xrender enabled I see
java consuming 100% of one core, while the XServer consumes ~50% of another
one.
With the OpenGL pipeline on the other hand, just one core is fully loaded -
despite a similar design (one flusher thread calling into OpenGL, and one
or more independent threads queuing drawing operations into a buffer).

The reason seems to be the OGLRenderQueue has just one buffer, so either
the flusher thread is active or a queuing thread but not both.
I wonder, have there been attempts made to introduce double-buffering here
and have producers (awt threads) and consumer (queue flusher thread)
running concurrently here?

2. Especially MaskFill did perform quite poor in my tests, because drivers
are typically not optimized for tiny texture uploads (32x32 coverage masks).
Just stubbing out the subTex2D call improved framerate of one benchmark
from 100fps to 300fps.
I have done some prototyping uploading coverage masks via
Shader_Storage_Buffer_Object, but that requires
ARB_shader_storage_buffer_object (GL 4.3) as well glBufferStorage (4.4), so
effectivly OpenGL-4.4.
On the pro side of this approach composition peaked at about 10GB/s with
64x64 mask tiles.

Which leads me to the next question:
The pipeline currently is written in rather ancient OpenGL-2.x style.
Once the need to support old OSX versions is gone, the OpenGL pipeline
would not be enabled be default on any platform.
Once this is the case, would it be feasable to clean up the code by making
use of modern GL and by leaving legacy platforms behind?
Modern GL has many improvements in areas where the current pipeline is
suffering a bit (overhead of state changes for small drawing operations,
etc).

Thanks and best regards, Clemens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210115/e2c3266e/attachment.htm>