On 08-Dec-2022, at 5:08 PM, Ajit Ghaisas <ajit.ghai...@oracle.com<mailto:ajit.ghai...@oracle.com>> wrote:
On 08-Dec-2022, at 1:50 PM, Alexey Ushakov <alexey.usha...@jetbrains.com<mailto:alexey.usha...@jetbrains.com>> wrote: FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes time for these things to be discovered. Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (https://youtrack.jetbrains.com/issue/JBR-4849 ). It was caused by https://bugs.openjdk.org/browse/JDK-8288948 (that we back ported into OpenJDK17 based runtime). The details can be found at - https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772<https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14504772> Look at the last 3 lines of that comment & attached test results to https://bugs.openjdk.org/browse/JDK-8288948. In the screenshots for RenderPerf and SwingMark results - the rightmost column header should read “Integrated graphics card." The reported bug is - https://bugs.openjdk.org/browse/JDK-8298217 Best Regards, Alexey On Dec 7, 2022, at 7:22 PM, Philip Race <philip.r...@oracle.com<mailto:philip.r...@oracle.com>> wrote: This is clearly too late for JDK 20 and JDK 21 will be just 6 months later so it is a better time for that. FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes time for these things to be discovered. Also I had a bug / rfe for this a while back : https://bugs.openjdk.org/browse/JDK-8233037 I closed it as WNF because I wasn't able to see a performance boost. So the right way to do this is to provide some solid evidence of what gets faster and what gets slower with a range of different values (not just the JBR one) and re-open that bug and resolve early in 21. -phil. On 12/7/22 7:36 AM, Alexey Ushakov wrote: Yes, I confirm that we’ve been using such enlarged buffer for a long time in production. It helped us with scrolling performance on 4K monitors. The suggested property could help to adjust the buffer for the needs of particular application. Best Regards, Alexey On 7 Dec 2022, at 11:37, Laurent Bourgès <bourges.laur...@gmail.com<mailto:bourges.laur...@gmail.com>> wrote: Hi, For years, JetBrains Runtime uses a larger render queue buffer size (32kb to 6,400,000 bytes) in production, as it boosted many accelerated pipelines: d3d, ogl, metal : ~ 10 to 20% on large fills... JBR RenderQueue: https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75 JDK RenderQueue: https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75 I want to propose such quick fix in openjdk20 today, as a 1-line fix. /** The size of the underlying buffer, in bytes. */ private static final int BUFFER_SIZE = 6400000; To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity: See in marlin: https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78 So here is my current proposal: [[[ /** The size of the underlying buffer, in bytes. */ private static final int BUFFER_SIZE; static { // Default 32K is too small for high-end GPU: BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024); // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE); } // system property utilities public static int getInteger(final String key, final int def, final int min, final int max) { final String property = AccessController.doPrivileged( new GetPropertyAction(key)); int value = def; if (property != null) { try { value = Integer.decode(property); } catch (NumberFormatException e) { System.out.println("Invalid integer value for " + key + " = " + property); } } // check for invalid values if ((value < min) || (value > max)) { System.out.println("Invalid value for " + key + " = " + value + "; expected value in range[" + min + ", " + max + "] !"); value = def; } return value; } protected static int align(final int val, final int norm) { final int ceil = (int)Math.ceil( ((float) val) / norm); return ceil * norm; } ]]] Would you accept such late change for openjdk20 ? Cheers, Laurent Bourgès
