Dzmitry Malyshau

[In Metal](https://developer.apple.com/documentation/metal/mtlblitcommandencoder/3075383-copyfromtexture?language=objc): > The source and destination textures must have the same pixel format and sample count. However, one can create a texture view of a different format, and use...

Observation: the discussion seems to concentrate around synchronization rather than queues. @Kangz > Fences (GPU->CPU synchronization) work differently in the native APIs but they can all be emulated on top...

Pinging @RafaelCintron and @litherum for whether it's even a good idea in Metal to have no targets/attachments in a render pass.

Moving to V1.0 to quickly mention in a discussion time slot. It may fall under the category of "allowed by all the native APIs", in which case we need to...

Thanks @Kangz ! That is a good argument to postponing this.

Thank you for writing this! Here is the first batch of high-ish level feedback: **Explicit**. I agree that being explicit about the ownership transfer, and more importantly - queue synchronization,...

> Otherwise if the transfer is immediate, any future submit on B will wait on A. It doesn't have to be immediate. All we'd spec in this case is that...

I guess I'm totally confused about the queue classes in D3D12 then. Looking at this piece - https://docs.microsoft.com/en-us/windows/win32/direct3d12/user-mode-heap-synchronization#multi-queue-resource-access I assume this section describes the resources that can be simultaneously accessed...

Jesse Natalie kindly clarified my confusion on D3D12 discord. Basically, the [doc section](https://docs.microsoft.com/en-us/windows/win32/direct3d12/user-mode-heap-synchronization#multi-queue-resource-access) implies the "simultaneous use" for the last paragraph (only!). As a consequence, the queue class separation totally...

Next steps for a future champion of this task: 1. Gather more information about the possible drawbacks of the recommendation of the original post by @litherum (thank you!): - extra...