hg: lanai/lanai: 8234506: implement cleaning logic for textures pool
jayathirth.d.v at oracle.com
Tue Nov 26 10:53:34 UTC 2019
Thanks for the clarifications.
I had similar patch working on my side and found out root cause for the issue which I was facing over your change.
Root cause is not related to your change, so there is no need to make any changes to wrapper code that we have right now.
I will soon refine and push things for JDK-8233190.
> On 25-Nov-2019, at 9:28 PM, Artem Bochkarev <artem.bochkarev at jetbrains.com> wrote:
> Hi, Jay!
> 1. Sorry, but I didn't understand the problem. From my point of view we can
> consider this wrapper as commandBuffer (with list of associated textures),
> it's created and owned by MTLContext as usual.
> FYI: some of blit operations (sw -> surface with transform) can't be
> performed directly and we use temporary texture (obtained from pool) that
> must be released when commitBuffer completed. So it's convenient to store
> such list of textures with the corresponding instance of
> commandBuffer (they have the same lifetime, we release textures in
> 2. I've replaced MTLContext.releaseCommandBuffer
> with pullCommandBufferWrapper just to simplify code a little bit (were
> removed some lines, this can be reverted if you need). I've removed
> markAllTexturesFree (this logic was moved into
> 3. I've resolved conflicts with your patch but jdk with this change doesn't
> work now. There wasn't enough time to debug the problem. Patch with
> resolved conflicts is attached.
> 4. you wrote:
>> move back to old method of command buffer and texture management.
> Please, explain in more detail what is the problem with command buffer and
> texture management?
> On Fri, Nov 22, 2019 at 12:56 PM Jayathirth Rao <jayathirth.d.v at oracle.com>
>> Looks like attachment is not visible in mail.
>> I have added JDK-8233190
>> <https://bugs.openjdk.java.net/browse/JDK-8233190> patch before
>> JDK-8234506 in JBS itself.
>> On 22-Nov-2019, at 3:06 PM, Jayathirth Rao <jayathirth.d.v at oracle.com>
>> Hi Artem,
>> I was working on JDK-8233190 <
>> https://bugs.openjdk.java.net/browse/JDK-8233190> to move main draw logic
>> to QueueFlusher as we dont want to hold Appkit thread for longer durations.
>> To achieve that I made changes to create more than one command buffer per
>> frame so that I can draw back buffer independent of final blit operation in
>> But the change made in JDK-8234506 couples command buffer creation and
>> release with texture creation and release. And I am not able to create
>> commandbuffers as required and release textures when drawing is completed.
>> I have attached the patch for JDK-8233190 <
>> https://bugs.openjdk.java.net/browse/JDK-8233190> which can be applied
>> without JDK-8234506 change and we see significant performance improvement.
>> Performance numbers are captured in JDK-8233190 <
>> Please let me know your thoughts about whether we can move back to old
>> method of command buffer and texture management.
>> On 20-Nov-2019, at 5:23 PM, artem.bochkarev at jetbrains.com wrote:
>> Changeset: b4f3e13ea1a0
>> Author: abochkarev
>> Date: 2019-11-20 14:41 +0300
>> URL: https://hg.openjdk.java.net/lanai/lanai/rev/b4f3e13ea1a0
>> 8234506: implement cleaning logic for textures pool
>> * use Last-Recent-Used strategy
>> * also optimized search of item
>> * also add command buffer wrapper (that manages binded per-frame resources)
>> ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m
>> ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLContext.h
>> ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLContext.m
>> ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m
>> ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexturePool.h
>> ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m
More information about the lanai-dev