[OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework
Ajit Ghaisas
ajit.ghaisas at oracle.com
Mon Jul 8 12:25:32 UTC 2019
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.ushakov at 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.ghaisas at oracle.com <mailto:ajit.ghaisas at 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.d.v at oracle.com <mailto:jayathirth.d.v at 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.ushakov at jetbrains.com <mailto:alexey.ushakov at 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.d.v at oracle.com <mailto:jayathirth.d.v at 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.ghaisas at oracle.com <mailto:ajit.ghaisas at 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.ushakov at jetbrains.com <mailto:alexey.ushakov at 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.Ushakov at jetbrains.com <mailto:Alexey.Ushakov at 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.ghaisas at oracle.com <mailto:ajit.ghaisas at 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.ushakov at jetbrains.com <mailto:alexey.ushakov at 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20190708/320c5931/attachment-0001.html>
More information about the 2d-dev
mailing list