Hi Ajit, According to the tests you’ve mentioned it’s not a big difference. Looks like we’ve faced with completely different scenario. I’ll try to figure out the main reason of the failure.
Best Regards, Alexey > On Dec 8, 2022, at 12:38 PM, Ajit Ghaisas <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." > >> >> 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 >>>> >>> >> >
