Hi Ajit, > Thanks for suggesting how to run basic perf test. > I did run it with and without Metal. The test run with Metal takes ~2X > time to run as compared with OpenGL. > What is your observation?
Yes, in some cases we have similar performance drop at the moment (testFlatBubbles, testFlatOvalRotBubbles, testWiredBubbles, testFlatQuad, testWiredQuad) Here is the results from Mac mini 2018, macOS 10.14.4 metalEnabled=0 testFlatBubbles 70 testFlatBoxBubbles 78 testImgBubbles 73 testFlatBoxRotBubbles 78 testFlatOvalRotBubbles 74 testLinGradOvalRotBubbles 46 testWiredBubbles 54 testWiredBoxBubbles 82 testLines 84 testFlatQuad 62 testWiredQuad 58 metalEnabled=1 testFlatBubbles 31 testFlatBoxBubbles 91 testImgBubbles 88 testFlatBoxRotBubbles 92 testFlatOvalRotBubbles 36 testLinGradOvalRotBubbles 37 testWiredBubbles 17 testWiredBoxBubbles - testLines 89 testFlatQuad 21 testWiredQuad 19 > Although, the java side code changes are good, I see an issue with native > Metal renderer implementation. > For rendering primitives, I see that the metal commands are being encoded > for each drawXXX call in MTLRenderer.m > > Why is MetalContext.createRenderEncoderForDest is being created for each > draw call? I think, it is an overhead. > Have you considered managing a VertexBuffer and encoding ’N’ set of draw > calls in a render pass? Yes, I thought about such optimizations. They definetely should help with this performance drop. Best Regards, Alexey > On 11 Jun 2019, at 12:01, Ajit Ghaisas <ajit.ghai...@oracle.com> wrote: > > Hi Alexey, > > Thanks for suggesting how to run basic perf test. > I did run it with and without Metal. The test run with Metal takes ~2X > time to run as compared with OpenGL. > What is your observation? > > Although, the java side code changes are good, I see an issue with native > Metal renderer implementation. > For rendering primitives, I see that the metal commands are being encoded > for each drawXXX call in MTLRenderer.m > > Why is MetalContext.createRenderEncoderForDest is being created for each > draw call? I think, it is an overhead. > Have you considered managing a VertexBuffer and encoding ’N’ set of draw > calls in a render pass? > > Regards, > Ajit > > >> On 17-May-2019, at 12:20 PM, Jayathirth Rao <jayathirth....@oracle.com >> <mailto:jayathirth....@oracle.com>> wrote: >> >> Hi Alexey, >> >> Thanks for the clarifications. >> Build failures we are getting are mainly because of tighter compiler >> restrictions, I have attached error log for the same. >> Basically we have 2 log errors and one conditional error. >> >> Yes in the latest build there is refactoring of LWComponentPeer.java but I >> have taken care of it and build error was not because of that. >> >> And thanks for sharing test and Graphics2D supported method details. >> >> Regards, >> Jay >> <Build_failure.txt> >> >> >>> On 16-May-2019, at 10:39 PM, Alexey Ushakov <alexey.usha...@jetbrains.com >>> <mailto:alexey.usha...@jetbrains.com>> wrote: >>> >>> Hi Jay, >>> >>>>> I can see that now you have added the MTLTexturePool.m file. It only >>>>> partially solves the build failures. >>>>> Jay & myself tried building it separately and we do still see the build >>>>> failures. >>> >>> It’s strange. There wasn’t any copy/paste errors. The only reason that I >>> can imagine that some chunks of the patch were rejected (as I actually >>> experienced recently because of some refactoring of LWComponentPeer.java >>> happened couple of days ago). >>> Anyway, I regenerated webrev once more >>> (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 >>> <http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01>) and verified it >>> with the openjdk workspace hg.openjdk.java.net/jdk/client >>> <http://hg.openjdk.java.net/jdk/client> . >>> >>> >>>> So with current JB changes what parts of primitive and image drawing are >>>> expected to work? >>>> Please provide your inputs. >>> >>> I’ve included junit4 performance test that you can try to see what is >>> currently supported. >>> Here is some steps to run the test provided with the webrev >>> >>> #cd openjdk_ws >>> #mkdir -p test/jdk/jbu/testdata/perf/metal/ >>> #cp webrev/raw_files/new/test/jdk/jbu/testdata/perf/metal/duke.png >>> test/jdk/jbu/testdata/perf/metal/ >>> >>> #./build/macosx-x86_64-server-release/images/jdk-bundle/jdk-13.jdk/Contents/Home/bin/javac >>> -cp .:/Users/avu/tools/junit-4.10.jar -d . >>> test/jdk/jbu/perf/metal/MetalPerfTest.java >>> >>> #./build/macosx-x86_64-server-release/images/jdk-bundle/jdk-13.jdk/Contents/Home/bin/java >>> -cp .:/Users/avu/tools/junit-4.10.jar >>> -Dtestdata=/Users/avu/ws/openjdk/test/jdk/jbu/testdata >>> -Djb.java2d.metal=true org.junit.runner.JUnitCore perf.metal.MetalPerfTest >>> >>> Here is the list of supported methods from Graphics2D: >>> setColor >>> fillOval >>> translate >>> setTransform >>> rotate >>> setPaint(new LinearGradientPaint()) >>> drawImage >>> fillRect >>> draw/fill (Shape) >>> >>> Best Regards, >>> Alexey >>> >>>> On 16 May 2019, at 15:08, Jayathirth Rao <jayathirth....@oracle.com >>>> <mailto:jayathirth....@oracle.com>> wrote: >>>> >>>> Hi Alexey, >>>> >>>> We are trying to test basic calls of Graphics2D as mentioned in >>>> https://docs.oracle.com/javase/tutorial/2d/TOC.html >>>> <https://docs.oracle.com/javase/tutorial/2d/TOC.html> >>>> >>>> I see that Graphics2D.drawImage() with BufferedImage as input works. Also >>>> I tried other operations like fillRect() and fillOval() and they work. I >>>> am testing with simple JFrame and adding draw calls inside overriden >>>> paint() method of a panel. >>>> >>>> So with current JB changes what parts of primitive and image drawing are >>>> expected to work? >>>> Please provide your inputs. >>>> >>>> Thanks, >>>> Jay >>>> >>>>> On 16-May-2019, at 12:47 PM, Ajit Ghaisas <ajit.ghai...@oracle.com >>>>> <mailto:ajit.ghai...@oracle.com>> wrote: >>>>> >>>>> Thanks Alexey. >>>>> >>>>> I can see that now you have added the MTLTexturePool.m file. It only >>>>> partially solves the build failures. >>>>> Jay & myself tried building it separately and we do still see the build >>>>> failures. >>>>> >>>>> Some statements need bracketing & some copy-paste errors need correction. >>>>> We could fix these errors and have got a build. We will continue our test >>>>> experiments with it. >>>>> >>>>> Meanwhile, you may want to update the patch to fix the build errors. >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> >>>>>> On 08-May-2019, at 8:56 PM, Alexey Ushakov <alexey.usha...@jetbrains.com >>>>>> <mailto:alexey.usha...@jetbrains.com>> wrote: >>>>>> >>>>>> FYI, I’ve rebased our work on top of the latest state of >>>>>> http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk> >>>>>> (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 >>>>>> <http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01>) >>>>>> >>>>>> Best Regards, >>>>>> Alexey >>>>>> >>>>>>> On 8 May 2019, at 16:19, Alexey Ushakov <alexey.usha...@jetbrains.com >>>>>>> <mailto:alexey.usha...@jetbrains.com>> wrote: >>>>>>> >>>>>>> Thanks for catching it, Ajit! >>>>>>> >>>>>>> Looks like it was a problem with webrev script applied to multiple git >>>>>>> commits. I’ve updated the webrev. >>>>>>> Also, we didn’t rebase yet on the latest state of >>>>>>> http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk> >>>>>>> (this work is in progress). >>>>>>> I’ll let you know when the rebase is ready. >>>>>>> >>>>>>> Best Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> On 7 May 2019, at 21:02, Ajit Ghaisas <ajit.ghai...@oracle.com >>>>>>>> <mailto:ajit.ghai...@oracle.com>> wrote: >>>>>>>> >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> I tried building this patch with latest >>>>>>>> http://hg.openjdk.java.net/jdk/jdk/ >>>>>>>> <http://hg.openjdk.java.net/jdk/jdk/> >>>>>>>> >>>>>>>> 1. Some basic copy paste errors are resulting in build failures >>>>>>>> 2. MTLTexturePool.m file is missing from the patch >>>>>>>> >>>>>>>> Can you please check & update? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ajit >>>>>>>> >>>>>>>>> On 30-Apr-2019, at 2:52 PM, Alexey Ushakov >>>>>>>>> <alexey.usha...@jetbrains.com <mailto:alexey.usha...@jetbrains.com>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Here is an update on our effort to use Metal framework for java2d >>>>>>>>> rendering. >>>>>>>>> >>>>>>>>> We’ve added image rendering support and some support for >>>>>>>>> LinearGradient. Also, the code has been refactored. >>>>>>>>> >>>>>>>>> Please have a look: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 >>>>>>>>> <http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01> >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> As far as we know Apple has deprecated OpenGL on MacOS platform >>>>>>>>>> (https://developer.apple.com/macos/whats-new/ >>>>>>>>>> <https://developer.apple.com/macos/whats-new/>). >>>>>>>>>> >>>>>>>>>> Unfortunately, this decision greatly affects our products that based >>>>>>>>>> on Java Client technologies. So, we (here at JetBrains) decided to >>>>>>>>>> start a project to replace OpenGL rendering on MacOS platform with a >>>>>>>>>> new one based on Metal. This is a huge task, so we decided to >>>>>>>>>> leverage current rendering architecture that is used in OpenGL >>>>>>>>>> rendering pipeline on Mac. >>>>>>>>>> >>>>>>>>>> That’s why we didn’t use MTKView for representing AWT windows (that >>>>>>>>>> probably would be a better approach in the long term). Currently >>>>>>>>>> we're using CAMetalLayer within AWTView. We’ve implemented flat >>>>>>>>>> color shape/curve rendering so far and there is a lot of work to do. >>>>>>>>>> So, we’re looking forward to any collaboration. >>>>>>>>>> >>>>>>>>>> In the mean time I’d like to share our current work to discuss metal >>>>>>>>>> pipeline architecture at the early stage of work. >>>>>>>>>> >>>>>>>>>> Here is the webrev with our on going development: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.00 >>>>>>>>>> <http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.00> >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Alexey >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
