Hi Alexey, FYI. We are also trying to merge the latest webrev shared into Open sandbox we have under https://bugs.openjdk.java.net/browse/JDK-8225160 <https://bugs.openjdk.java.net/browse/JDK-8225160>. It is in initial phase of merge, we will be updating the JBS bug with more details as we continue merge process.
Thanks, Jay > On 11-Jun-2019, at 2:31 PM, 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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
