[OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework
Alexey Ushakov
alexey.ushakov at jetbrains.com
Wed Jun 19 22:20:16 UTC 2019
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> 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/20190620/46b83f3d/attachment-0001.html>
More information about the 2d-dev
mailing list