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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>>>> <mailto:[email protected]>> 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
>>>>>>>> <[email protected] <mailto:[email protected]>>
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
