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

[Laurent Bourgès]

Hi Phil,

Thank you a lot for your review and your time on this long & complex review.

2018-03-26 22:50 GMT+02:00 Philip Race :

> Hi Laurent,
>
> It took me I at least 5 tries to get all the way through this.
>
>
I agree it was a complex patch (clipping) with many other small
improvements, sorry.


> I don't have any substantial comments, just a few clean up questions.
>
>
> What is this in Curve.java + DCurve.java ?
>
> Even if derivatives are totally useless for lines, I removed the condition
to reset these values anyway.

> +if (false) {+dax = 0.0d;+day = 0.0d;+
> dbx = 0.0d;+dby = 0.0d;+}
>
> In Renderer.java, should the commented line be removed ?
>
> +&& ((Math.abs(ddx) + Math.abs(ddy) * _SCALE_DY) <= 
> _INC_BND+// && (Math.abs(ddx + dddx) + Math.abs(ddy + 
> dddy) * _SCALE_DY) <= _INC_BND
>
> A similar pattern occurs a little later in the same file.
>
> +//|| (Math.abs(ddx + dddx) + Math.abs(ddy + dddy) * 
> _SCALE_DY) >= _DEC_BND
>
> Fixed (removed lines)


> +static final float LEN_TH = 
> MarlinProperties.getSubdividerMinLength();
>
> You really meant to name it LEN_TH and not LENGTH ?
>
> That was deliberate, I wanted to shorten LENGTH_THRESHOLD => LEN_TH, not
LENGTH.

There are a few TODO's I see but they seem to be more about later
clean up or optimisation
> so are probably all OK.
>
> I added few new TODO that I hope to fix later (nothing critical).

> So I am OK to push, and if you clean up any of the above first I don't need 
> to see a new webrev.
>
> Thank you again,

Laurent


>
> On 3/23/18, 2:03 PM, Laurent Bourgès wrote:
>
> Hi,
>
> Sorry to insist but I would like to get feedback on this Marlin patch soon
> before going forward on tile-size tuning in java2d accelerated pipelines.
>
> Laurent
>
> 2018-03-21 22:56 GMT+01:00 Laurent Bourgès :
>
>> Hi,
>>
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.1/
>>
>> Changes in MarlinProperties only:
>> - getTileSize_Log2() & getTileWidth_Log2(); 32x32 tiles ie default = 5
>> (log2)
>>
>> I hope it is good for now as tile settings are the same as in jdk9/10.
>>
>> Regards,
>> Laurent
>>
>>
>> 2018-03-21 21:44 GMT+01:00 Laurent Bourgès :
>>
>>> Sergey,
>>>
>>> Le mer. 14 mars 2018 à 17:14, Sergey Bylokhov <
>>> sergey.bylok...@oracle.com> a écrit :
>>>
 On 13/03/2018 17:04, Sergey Bylokhov wrote:

> I have started to look to this review, will run some closed tests and
> send a feedback soon.
>

 No issues found so far, +1.
>>>
>>>
>>> Thanks for your vote.
>>> I need another approval I suppose ?
>>>
>>> I will prepare another review asap reverting only tile size changes as
>>> using large tiles has performance drop on d3d & ogl that needs more work.
>>> It can be done later in follow-up issues.
>>>
>>> Phil do you agree the proposed plan ?
>>>
>>> Laurent
>>>
>>
>>
>

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

[Philip Race]

Hi Laurent,

It took me I at least 5 tries to get all the way through this.
I don't have any substantial comments, just a few clean up questions.


What is this in Curve.java + DCurve.java ?

+if (false) {
+dax = 0.0d;
+day = 0.0d;
+dbx = 0.0d;
+dby = 0.0d;
+}

In Renderer.java, should the commented line be removed ?

+&&  ((Math.abs(ddx) + Math.abs(ddy) * _SCALE_DY)<= _INC_BND
+//&&  (Math.abs(ddx + dddx) + Math.abs(ddy + dddy) * _SCALE_DY)<= _INC_BND

A similar pattern occurs a little later in the same file.

+//|| (Math.abs(ddx + dddx) + Math.abs(ddy + dddy) * 
_SCALE_DY)>= _DEC_BND


+static final float LEN_TH = MarlinProperties.getSubdividerMinLength();

You really meant to name it LEN_TH and not LENGTH ?


There are a few TODO's I see but they seem to be more about later clean up or 
optimisation
so are probably all OK.

So I am OK to push, and if you clean up any of the above first I don't need to 
see a new webrev.

-phil.



On 3/23/18, 2:03 PM, Laurent Bourgès wrote:

Hi,

Sorry to insist but I would like to get feedback on this Marlin patch 
soon before going forward on tile-size tuning in java2d accelerated 
pipelines.


Laurent

2018-03-21 22:56 GMT+01:00 Laurent Bourgès >:


Hi,

Here is the updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.1/


Changes in MarlinProperties only:
- getTileSize_Log2() & getTileWidth_Log2(); 32x32 tiles ie default
= 5 (log2)

I hope it is good for now as tile settings are the same as in jdk9/10.

Regards,
Laurent


2018-03-21 21:44 GMT+01:00 Laurent Bourgès
>:

Sergey,

Le mer. 14 mars 2018 à 17:14, Sergey Bylokhov
> a écrit :

On 13/03/2018 17:04, Sergey Bylokhov wrote:

I have started to look to this review, will run some
closed tests and send a feedback soon.


No issues found so far, +1.


Thanks for your vote.
I need another approval I suppose ?

I will prepare another review asap reverting only tile size
changes as using large tiles has performance drop on d3d & ogl
that needs more work. It can be done later in follow-up issues.

Phil do you agree the proposed plan ?

Laurent

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

[Laurent Bourgès]

Hi,

Sorry to insist but I would like to get feedback on this Marlin patch soon
before going forward on tile-size tuning in java2d accelerated pipelines.

Laurent

2018-03-21 22:56 GMT+01:00 Laurent Bourgès :

> Hi,
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.1/
>
> Changes in MarlinProperties only:
> - getTileSize_Log2() & getTileWidth_Log2(); 32x32 tiles ie default = 5
> (log2)
>
> I hope it is good for now as tile settings are the same as in jdk9/10.
>
> Regards,
> Laurent
>
>
> 2018-03-21 21:44 GMT+01:00 Laurent Bourgès :
>
>> Sergey,
>>
>> Le mer. 14 mars 2018 à 17:14, Sergey Bylokhov 
>> a écrit :
>>
>>> On 13/03/2018 17:04, Sergey Bylokhov wrote:
>>>
 I have started to look to this review, will run some closed tests and
 send a feedback soon.

>>>
>>> No issues found so far, +1.
>>
>>
>> Thanks for your vote.
>> I need another approval I suppose ?
>>
>> I will prepare another review asap reverting only tile size changes as
>> using large tiles has performance drop on d3d & ogl that needs more work.
>> It can be done later in follow-up issues.
>>
>> Phil do you agree the proposed plan ?
>>
>> Laurent
>>
>
>

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

[Laurent Bourgès]

Hi,

Here is the updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.1/

Changes in MarlinProperties only:
- getTileSize_Log2() & getTileWidth_Log2(); 32x32 tiles ie default = 5
(log2)

I hope it is good for now as tile settings are the same as in jdk9/10.

Regards,
Laurent

2018-03-21 21:44 GMT+01:00 Laurent Bourgès :

> Sergey,
>
> Le mer. 14 mars 2018 à 17:14, Sergey Bylokhov 
> a écrit :
>
>> On 13/03/2018 17:04, Sergey Bylokhov wrote:
>>
>>> I have started to look to this review, will run some closed tests and
>>> send a feedback soon.
>>>
>>
>> No issues found so far, +1.
>
>
> Thanks for your vote.
> I need another approval I suppose ?
>
> I will prepare another review asap reverting only tile size changes as
> using large tiles has performance drop on d3d & ogl that needs more work.
> It can be done later in follow-up issues.
>
> Phil do you agree the proposed plan ?
>
> Laurent
>

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

[Laurent Bourgès]

Sergey,

Le mer. 14 mars 2018 à 17:14, Sergey Bylokhov 
a écrit :

> On 13/03/2018 17:04, Sergey Bylokhov wrote:
>
>> I have started to look to this review, will run some closed tests and
>> send a feedback soon.
>>
>
> No issues found so far, +1.


Thanks for your vote.
I need another approval I suppose ?

I will prepare another review asap reverting only tile size changes as
using large tiles has performance drop on d3d & ogl that needs more work.
It can be done later in follow-up issues.

Phil do you agree the proposed plan ?

Laurent

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

[Sergey Bylokhov]

On 13/03/2018 17:04, Sergey Bylokhov wrote:
I have started to look to this review, will run some closed tests and 
send a feedback soon.


No issues found so far, +1.


--
Best regards, Sergey.

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

[Sergey Bylokhov]

Hi, Laurent.
On 09/03/2018 00:28, Laurent Bourgès wrote:

Hi Sergey & Phil,

Could you review the submitted marlin webrev soon ?


I have started to look to this review, will run some closed tests and 
send a feedback soon.



--
Best regards, Sergey.

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

[Laurent Bourgès]

Hi Sergey & Phil,

Could you review the submitted marlin webrev soon ?

I will revert the tile size change in MarlinProperties (6,7 => 5,5) to
avoid any problem for now: 2 lines fix.

As proposed before, supporting larger tiles in 2d pipelines needs many
small tuning and can be done in follow-up issues (d3d, ogl, gdi...) as it
requires lots of testing.

I prefer having Marlin 0.9.1 patch accepted asap.

Laurent

Le 8 mars 2018 23:57, "Sergey Bylokhov"  a
écrit :

> On 08/03/2018 14:02, Laurent Bourgès wrote:
>
>> I suppose the queue is drained too quickly on my fast gpu and is too
>> small to feed the gpu... maybe I am wron
>>
> Profiling will help here. on macOS you can user Instruments which can
> profile cpu and gpu.
>
> Definitely it is more related to awt... and propose to postpone using
>> large tiles on other platforms than linux for the moment.
>>
>> How is it enabled ? Using sun.java2d.d3d=false ?
>>
>
> Yes "sun.java2d.d3d=false" or it can be selected automatically if d3d
> pipeline is unsupported (or video card is blacklisted).
>
>
> --
> Best regards, Sergey.
>

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

[Sergey Bylokhov]

On 08/03/2018 14:02, Laurent Bourgès wrote:
I suppose the queue is drained too quickly on my fast gpu and is too 
small to feed the gpu... maybe I am wron
Profiling will help here. on macOS you can user Instruments which can 
profile cpu and gpu.


Definitely it is more related to awt... and propose to postpone using 
large tiles on other platforms than linux for the moment.


How is it enabled ? Using sun.java2d.d3d=false ?


Yes "sun.java2d.d3d=false" or it can be selected automatically if d3d 
pipeline is unsupported (or video card is blacklisted).



--
Best regards, Sergey.

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

[Laurent Bourgès]

Sergey,

Le 8 mars 2018 21:21, "Sergey Bylokhov"  a
écrit :

On 06/03/2018 00:38, Laurent Bourgès wrote:

> Yes d3d/ogl are defered rendering so using RenderQueue buffering has costs
> (1 extra mask copy + command arguments). I wonder how to improve such
> buffer queue to have less synchronization overhead induced by flushNow(),
> and why increasing the buffer improved so much the performance (less JNI
> overhead, more threads ?)
>

It is unclear the reason of speedup, it can be possible that you just fill
the render queue and then calculate some performance numbers before
something was drawn to the destination.

I suppose the queue is drained too quickly on my fast gpu and is too small
to feed the gpu... maybe I am wrong.

I could try adding Toolkit.synch() to ensure rendering ops are finished. I
will have a look to j2dbench source code to better understand. Finally I
have to run j2dbench on windows to have other certified numbers...

Definitely it is more related to awt... and propose to postpone using large
tiles on other platforms than linux for the moment.


I will not test gdi nor x11 as nowadays the officially supported pipelines
> are xrender (linux), opengl (mac) & d3d (windows).
>

If I not missed then by default gdi is used on the Intel HD(which is quite
common).


How is it enabled ? Using sun.java2d.d3d=false ?

Thanks for your help,
Laurent

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

[Sergey Bylokhov]

On 06/03/2018 00:38, Laurent Bourgès wrote:
Yes d3d/ogl are defered rendering so using RenderQueue buffering has 
costs (1 extra mask copy + command arguments). I wonder how to improve 
such buffer queue to have less synchronization overhead induced by 
flushNow(), and why increasing the buffer improved so much the 
performance (less JNI overhead, more threads ?)


It is unclear the reason of speedup, it can be possible that you just 
fill the render queue and then calculate some performance numbers before 
something was drawn to the destination.


I will not test gdi nor x11 as nowadays the officially supported 
pipelines are xrender (linux), opengl (mac) & d3d (windows).


If I not missed then by default gdi is used on the Intel HD(which is 
quite common).


--
Best regards, Sergey.

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

[Laurent Bourgès]

Hi Sergey,

Good to get feedback from java2d team !

I am investing a lot of my own time on improving java2d with the Marlin
renderer & other optimizations (like these ones) so I expect more
involvement from the openjdk 2d community ... to help me testing,
commenting, reviewing patches and I suffer from discussion lags & being
alone pushing the limits !
I know the java2d team is very small but the community is larger and java
(swing) desktop application like IDE (netbeans, eclipse or idea) are widely
used and necessary for any java development (critical).

Who would join my efforts to run tests, benchmarks ... ?


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).
>


I just ran my own MapBench tool (1 thread) that performs GeneralPath draw /
fill operations (+ image clear). This tool (source code + binary releases)
is available on my github:
https://github.com/bourgesl/mapbench

MapBench either uses ARGB BufferedImages (sw loops) or VolatileImages
(d3d/ogl/xr accelerated) = maskfill only as I mainly focused on Marlin
performance (AA) as I think AA is generally used in 2018.

(J2DBench does not have proper path tests even if I worked with Jim in 2015
to add specific test cases for GeneralPath + multi-threading).

Finally, I was surprised to see that performance differs so much on the
same hardware (dual boot) between pipelines. Moreover, windows is a major
platform and I supposed java2d d3d pipelines was highly tuned for such
major use case. Of couse, that means there are still many things to improve
in 2018 (fast GPU) for the overall java community benefit.



> In other cases it will be slower since it use an additional layer -
> RenderQueue, it would be good to compare xrender and gdi/X11.
>

Yes d3d/ogl are defered rendering so using RenderQueue buffering has costs
(1 extra mask copy + command arguments). I wonder how to improve such
buffer queue to have less synchronization overhead induced by flushNow(),
and why increasing the buffer improved so much the performance (less JNI
overhead, more threads ?)

I will not test gdi nor x11 as nowadays the officially supported pipelines
are xrender (linux), opengl (mac) & d3d (windows).



>
> 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.
>

1. Yes I know but I wanted to evaluate if my RenderQueue buffer change
impacted positively the opengl pipeline. It improved performance on both
windows & linux by the same order.

2. It takes me a lot of my time to run benchmarks on many platforms (my own
personal machines) so I did not have time yet to test on macOS.

I would really appreciate if I or any Q people could run benchmarks on a
shared testing platform (win, linux, mac, sparc) having all sort of CPU &
GPU.
Would Oracle or adoptopenjdk allow such external access to such a platform
(to be built) ?



>
> 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).
>

Thanks for the pointer, I will have a look. As said, I want to improve
Marlin performance first.


>
> 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..
>

Ok, I will take time to run J2DBench on my machines (with/without patch)
and share the results.


>
> 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 ?
>>

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

[Clemens Eisserer]

HI,

> As previously mentioned, I increased the RenderQueue buffer (see patchs at
> the end) to 4M (instead of 32K) and d3d & opengl get boosted.

It is great to see the tile-size improvements reach the other backends too :)

In case of the buffer size - I wonder is 4M really needed or was it an
arbitrary number (128x increase)?
The reason I ask is the overhead of a smaller RenderQueue (the Queue
flushes are process-local (actually a thread-switch & wait) and I am a
bit concerned about memory consumption of non-graphically intensive
applications (+4mb for e.g. a small swing app would be a big deal).

Best regards, Clemens

Re: [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.

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

[Laurent Bourgès]

Phil,

As promised, I made Marlin 0.9.1 benchmarks on windows & linux to compare
d3d, opengl & xrender backends on the same machine: I5 + nvidia 1070.
(I will test on mac OS X soon, if needed)

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) !

I will share later detailed results (plots) but raw data files are
available (see linux & win files):
https://github.com/bourgesl/bourgesl.github.io/commit/84133d54692affd1d96938a88ac4a041ec0f5e36


As previously mentioned, I increased the RenderQueue buffer (see patchs at
the end) to 4M (instead of 32K) and d3d & opengl get boosted.

Finally, I increased the cached tile sizes in OGLVertexCache.h and opengl
performance achieved xrender performance on linux:

--- /tmp/meld-tmpdLFq6S
+++
/home/graphics-rasterizer/jdk/client/src/java.desktop/share/native/common/java2d/opengl/OGLVertexCache.h
@@ -38,13 +38,13 @@
  * Constants that control the size of the texture tile cache used for
  * mask operations.
  */
-#define OGLVC_MASK_CACHE_TILE_WIDTH   32
-#define OGLVC_MASK_CACHE_TILE_HEIGHT  32
+#define OGLVC_MASK_CACHE_TILE_WIDTH   128   /* 32 */
+#define OGLVC_MASK_CACHE_TILE_HEIGHT  64/* 32 */
 #define OGLVC_MASK_CACHE_TILE_SIZE \
(OGLVC_MASK_CACHE_TILE_WIDTH * OGLVC_MASK_CACHE_TILE_HEIGHT)

-#define OGLVC_MASK_CACHE_WIDTH_IN_TILES   8
-#define OGLVC_MASK_CACHE_HEIGHT_IN_TILES  4
+#define OGLVC_MASK_CACHE_WIDTH_IN_TILES   16
+#define OGLVC_MASK_CACHE_HEIGHT_IN_TILES  8

 #define OGLVC_MASK_CACHE_WIDTH_IN_TEXELS \
(OGLVC_MASK_CACHE_TILE_WIDTH * OGLVC_MASK_CACHE_WIDTH_IN_TILES)


Thanks to Clemens, that explained me its xrender new approach and it
convinced me to tune java2d pipelines.

In conclusion, using larger tiles in Marlin 0.9.1 will allow large gains
either in d3d & opengl pipelines so I plan to propose these new fixes for
jdk11 soon.

News:
> - I modified opengl queue buffer capacity recently and got 30% better
> performance (mapbench) on linux. That could be worth for macOS: will create
> another jbs bug
> - I will work on upgrading MarlinFX to 0.9.1 soon to provide you a patch
> for openjfx 11.
>
> Who can review such patches & help me on improving java2d pipelines
> (discussion, skills) ?
>

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 ?

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...)

Cheers,
Laurent


--- /tmp/meld-tmpFaCMrF
+++
/home/graphics-rasterizer/jdk/client/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights
reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,9 +25,12 @@

 package sun.java2d.pipe;

+import java.security.AccessController;
 import java.util.HashSet;
 import java.util.Set;
+
 import sun.awt.SunToolkit;
+import sun.security.action.GetPropertyAction;

 /**
  * The RenderQueue class encapsulates a RenderBuffer on which rendering
@@ -72,20 +75,34 @@
 public abstract class RenderQueue {

 /** The size of the underlying buffer, in bytes. */
-private static final int BUFFER_SIZE = 32000;
+private static final int BUFFER_SIZE;
+
+static {
+BUFFER_SIZE = align(getInteger("sun.java2d.opengl.bufferSize",
4*1024 * 1024, 32 * 1024, 64 * 1024 * 1024), 1024);
+System.out.println("RenderQueue: sun.java2d.opengl.bufferSize =
"+BUFFER_SIZE);
+}

 /** The underlying buffer for this queue. */
-protected RenderBuffer buf;
+protected final RenderBuffer buf;

 /**
  * A Set containing hard references to Objects that must stay alive
until
  * the queue has been completely flushed.
  */
-protected Set refSet;
+protected final Set refSet;

 protected RenderQueue() {
-refSet = new HashSet<>();
+refSet = new HashSet(64); // large enough (LBO) ?
 buf = RenderBuffer.allocate(BUFFER_SIZE);
+}
+
+protected final void clear() {
+// reset the buffer position
+buf.clear();
+// clear the set of references, since we no longer need them
+refSet.clear();
 }

 /**
@@ -220,4 +237,35 @@
 buf.position(position);

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

[Laurent Bourgès]

Hi,
I have created the corresponding JBS rfe/bug:
https://bugs.openjdk.java.net/browse/JDK-8198885

Jtreg: ok
Tested on linux 64 with both xrender & opengl pipelines.

I will make tests on macOS & windows soon to ensure larger tiles are well
supported.

News:
- I modified opengl queue buffer capacity recently and got 30% better
performance (mapbench) on linux. That could be worth for macOS: will create
another jbs bug
- I will work on upgrading MarlinFX to 0.9.1 soon to provide you a patch
for openjfx 11.

Who can review such patches & help me on improving java2d pipelines
(discussion, skills) ?

Laurent

Le 15 févr. 2018 6:30 PM, "Laurent Bourgès"  a
écrit :

> Hi,
>
> Please review this large patch providing Marlin 0.9.1 for JDK 11:
>
> JBS: to be created asap
> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.0/
>
> Changes:
> - *ArrayCache: removed clean flag and usage of
> jdk.internal.UNSAFE.allocateUninitializedArray()
> - (D)Curve: added support for lines (curve type 4) + new methods x/y
> Points to compute intersections on clip edges
> - (D)Dasher: use new CurveBasicMonotonizer & CurveClipSplitter to perform
> clipping in Dasher that uses skipLen() to compute properly the dash phase &
> state
> - (D)Helpers: refined precision in cubicRootsInAB (float variant) + add
> fastXXXLen() to quickly estimate curve length from control points
>   moved findSubdivPoints() from (D)Stroker + added findClipPoints() to
> determine t values corresponding to curve intersections with the clip edges
> + added subdivideLineAt() to subdivide line segments
> - (D)MarlinRenderingEngine: disable stroker clipping if dasher clipping
> enabled (2nd clipping is counter-productive) + initialize new path
> simplifier if enabled (disabled by default) + log new settings
> - (D)Renderer: refined [quad/cubic]BreakIntoLinesAndAdd loops to enhance
> accuracy (smaller error related to 2nd ddx/y) with asymetric supixel counts
> - (D)Stroker: use new CurveBasicMonotonizer & CurveClipSplitter (code
> refactoring)
> - (D)TransformingPathConsumer2D: use CurveClipSplitter in PathClipFilter
> to clip filled shapes overlapping clipping edges
> added CurveClipSplitter that subdivides curves (line, quad,
> cubic) at clip intersections (+ small padding to avoid precision issues)
> added CurveBasicMonotonizer to monotonize curves (before in
> Stroker) to make it on initial curve in Dasher (more efficient than for all
> dashes)
> - (D)PathSimplifier: new basic path clipper (disabled by default) ignoring
> too small segments (radial distance threshold)
> - ClipShapeTest: improved test to use a small tolerance as clipped curves
> (at clip edges) has minor impact on computed offsets for stroked shapes and
> on dash positions: overall quality is improved as previously larger curves
> had more accumulated error on either dashes or stroke offsets
>
> Build & jtreg tests: OK
>
> Cheers,
> Laurent
>

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

[Laurent Bourgès]

Phil,
Will you have some time soon to have a look ?

It fixes dashing performance definitively and dash error accumulation too.

Laurent

Le 15 févr. 2018 6:30 PM, "Laurent Bourgès"  a
écrit :

> Hi,
>
> Please review this large patch providing Marlin 0.9.1 for JDK 11:
>
> JBS: to be created asap
> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.0/
>
> Changes:
> - *ArrayCache: removed clean flag and usage of
> jdk.internal.UNSAFE.allocateUninitializedArray()
> - (D)Curve: added support for lines (curve type 4) + new methods x/y
> Points to compute intersections on clip edges
> - (D)Dasher: use new CurveBasicMonotonizer & CurveClipSplitter to perform
> clipping in Dasher that uses skipLen() to compute properly the dash phase &
> state
> - (D)Helpers: refined precision in cubicRootsInAB (float variant) + add
> fastXXXLen() to quickly estimate curve length from control points
>   moved findSubdivPoints() from (D)Stroker + added findClipPoints() to
> determine t values corresponding to curve intersections with the clip edges
> + added subdivideLineAt() to subdivide line segments
> - (D)MarlinRenderingEngine: disable stroker clipping if dasher clipping
> enabled (2nd clipping is counter-productive) + initialize new path
> simplifier if enabled (disabled by default) + log new settings
> - (D)Renderer: refined [quad/cubic]BreakIntoLinesAndAdd loops to enhance
> accuracy (smaller error related to 2nd ddx/y) with asymetric supixel counts
> - (D)Stroker: use new CurveBasicMonotonizer & CurveClipSplitter (code
> refactoring)
> - (D)TransformingPathConsumer2D: use CurveClipSplitter in PathClipFilter
> to clip filled shapes overlapping clipping edges
> added CurveClipSplitter that subdivides curves (line, quad,
> cubic) at clip intersections (+ small padding to avoid precision issues)
> added CurveBasicMonotonizer to monotonize curves (before in
> Stroker) to make it on initial curve in Dasher (more efficient than for all
> dashes)
> - (D)PathSimplifier: new basic path clipper (disabled by default) ignoring
> too small segments (radial distance threshold)
> - ClipShapeTest: improved test to use a small tolerance as clipped curves
> (at clip edges) has minor impact on computed offsets for stroked shapes and
> on dash positions: overall quality is improved as previously larger curves
> had more accumulated error on either dashes or stroke offsets
>
> Build & jtreg tests: OK
>
> Cheers,
> Laurent
>

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

[Laurent Bourgès]

Hi,

Please review this large patch providing Marlin 0.9.1 for JDK 11:

JBS: to be created asap
webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.0/

Changes:
- *ArrayCache: removed clean flag and usage of jdk.internal.UNSAFE.
allocateUninitializedArray()
- (D)Curve: added support for lines (curve type 4) + new methods x/y Points
to compute intersections on clip edges
- (D)Dasher: use new CurveBasicMonotonizer & CurveClipSplitter to perform
clipping in Dasher that uses skipLen() to compute properly the dash phase &
state
- (D)Helpers: refined precision in cubicRootsInAB (float variant) + add
fastXXXLen() to quickly estimate curve length from control points
  moved findSubdivPoints() from (D)Stroker + added findClipPoints() to
determine t values corresponding to curve intersections with the clip edges
+ added subdivideLineAt() to subdivide line segments
- (D)MarlinRenderingEngine: disable stroker clipping if dasher clipping
enabled (2nd clipping is counter-productive) + initialize new path
simplifier if enabled (disabled by default) + log new settings
- (D)Renderer: refined [quad/cubic]BreakIntoLinesAndAdd loops to enhance
accuracy (smaller error related to 2nd ddx/y) with asymetric supixel counts
- (D)Stroker: use new CurveBasicMonotonizer & CurveClipSplitter (code
refactoring)
- (D)TransformingPathConsumer2D: use CurveClipSplitter in PathClipFilter to
clip filled shapes overlapping clipping edges
added CurveClipSplitter that subdivides curves (line, quad,
cubic) at clip intersections (+ small padding to avoid precision issues)
added CurveBasicMonotonizer to monotonize curves (before in
Stroker) to make it on initial curve in Dasher (more efficient than for all
dashes)
- (D)PathSimplifier: new basic path clipper (disabled by default) ignoring
too small segments (radial distance threshold)
- ClipShapeTest: improved test to use a small tolerance as clipped curves
(at clip edges) has minor impact on computed offsets for stroked shapes and
on dash positions: overall quality is improved as previously larger curves
had more accumulated error on either dashes or stroke offsets

Build & jtreg tests: OK

Cheers,
Laurent