Problems with D3D12 state tracking

Todo.md

@@ -28,6 +28,11 @@
 - Add support for sRGB swapchain views (VK_KHR_image_format_list).
 - Add tests for validation of view format compatibility (RTV, SRV, UAV,
   DSV).
+- D3D12 resource state tracking doesn't map very well to Vulkan
+  - D3D12 creates its resource directly in its initial state, while Vulkan requires a GPU operation for the first transition, which therefore has to be postponed to when a GPU queue is available (i.e., the first time the resource is used); see e.g. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/838
+  - In D3D12 depth and stencil are independent subresources, so their state can be managed independently; in Vulkan there is just one layout that specifies what happens on both aspects; therefore when the state of only one subresource is changed in D3D12 we don't know what to do in Vulkan, unless we track the state of the other aspect (and we currently don't do that)
+  - D3D12 has [implicit state promotion and decay](https://learn.microsoft.com/en-us/windows/win32/direct3d12/using-resource-barriers-to-synchronize-resource-states-in-direct3d-12#common-state-promotion-and-decay-sample) so when a command is recorded we don't know for sure which (explicit) state that resource is supposed to be in; for example, the destination of a copy operation might be in the COPY_DEST state or in the GENERAL state implicitly promoted to COPY_DEST. But since promotion is implicit we don't know which actual layout the Vulkan image is in, and Vulkan copy commands want to know it.
+  - Correctly tracking D3D12 resource state cannot be done at D3D12 command list recording time, because it depends on the initial states of the resources, which depends on which order the command lists are submitted to a queue (and potentially even to many queues); in other words, we have to serialize command list submission and only at that point we have all the information to write Vulkan command buffers.
 
 ## libvkd3d-shader