Fwd: hg: lanai/lanai: 8234506: implement cleaning logic for textures pool

[Artem Bochkarev]

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
MTLCommandBuffer.completedHandler).

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
MTLCommandBufferWrapper.onComplete).

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>
wrote:

> 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.
>
> Thanks,
> Jay
>
> On 22-Nov-2019, at 3:06 PM, Jayathirth Rao <jayathirth.d.v at oracle.com>
> wrote:
>
> 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
> Appkit.
>
> 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 <
> https://bugs.openjdk.java.net/browse/JDK-8233190>.
>
> Please let me know your thoughts about whether we can move back to old
> method of command buffer and texture management.
>
> Thanks,
> Jay
>
>
>
> 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
>
>
>
>