[OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

[Sergey Bylokhov]

Hi, Laurent.
On 05/03/2018 14:19, Laurent Bourgès wrote:
> First Marlin 0.9.1 patch works well: no crash or bug with larger tiles 
> 128x64 even if d3d / opengl uses internally 32x32 texture caches.
> Moreover xrender pipeline is the fastest compared to D3D (40% slower) or 
> opengl (>250% slower) !

What types of GraphicsPrimitives were tested(in terms of java2d)? I 
guess that d3d/ogl may outperform other pipelines only in case of 
"native" blits, which are used in case of draw of cashed 
bufferedImage(OGL texture) or VolatileImage(FBO) to the window/volatile 
image(this also depends from the composite type and alpha).
In other cases it will be slower since it use an additional layer - 
RenderQueue, it would be good to compare xrender and gdi/X11.

Some unrelated question: it is interesting how xrender will work in Wayland.


Note 1. OGL is not officially supported on linux. We need to check ogl 
performance on macOS where it is used as a default pipeline.

Note 2. there are some other blit's related tiles like:
#define OGLC_BLIT_TILE_SIZE 128

Also please be care about different vendors:
OGLC_VENDOR_INTEL/OGLC_VENDOR_ATI/OGLC_VENDOR_NVIDIA because their 
native blits are implemented differently. The reason was in a 
performance of some OGL API(maybe this code is outdated).

I suggest to use some common testcases from J2DBench and SwingMark, so 
at some point later it will be possible to check other changes for 
possible regression, for example see:
https://bugs.openjdk.java.net/browse/JDK-8059944
Note that this fix in some cases decreased a performance by half but in 
other cases improved it by 25422.21%. You can see we can improve 
performance in one case but lose much more in another. This is why 
J2DBench is better because it can check all combinations of 
src/dst/composite/clip/size/etc..

> Soory to insist but who could advice me and give me explanations on the 
> RenderQueue & d3d / opengl backends.
> 
> I read JBS for RenderQueue buffering as I have several questions 
> (asynchronous queue ?)
> How to auto-tune such buffer capacity ?
> It seems tricky as too small or too large buffers impacts performance as 
> it depends on the GPU speed (drain the buffer).
> Is there any design document ?

As far as I know there are no documents about tile tuning, most of 
decisions were made according to j2dbench results. But this code still 
uses ogl_2 and d3d_9 so it can be possible that the new versions of 
these API have a better alternative.

> PS: I will once again look into java2d pipelines for tile constants (32) 
> to see if other parts should be updated (TexturePaint ?)...
> I also need help on testing such patches on many hw platforms to detect 
> regressions (j2dBench, MapBench...)

I guess we can run these tests on at least supported configurations.

-- 
Best regards, Sergey.