Hi, I have pushed a minor correction to the metal-prototype-branch of jdk-sandbox (http://hg.openjdk.java.net/jdk/sandbox <http://hg.openjdk.java.net/jdk/sandbox>) Now, we can build and launch J2DDemo, J2DBenchmark and SwingSet2 with Metal pipeline. Of course, rendering performance is slow and still a lot of functionality needs to be implemented.
Regards, Ajit > On 20-Jun-2019, at 3:50 AM, Alexey Ushakov <alexey.usha...@jetbrains.com> > wrote: > > 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 >> <mailto: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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
