kvark
commented
4 years ago It looks like we are at the stage where specific image layouts map OK to D3D12 resource states. There are some subtle complexities with copies and resolves, but they seem to be under control.
There is a big difference between the image::Layout::General layout and D3D12_RESOURCE_STATE_COMMON, which can be considered to be the corresponding state in DX12:
VK_IMAGE_LAYOUT_GENERAL supports all types of device access.
In contrast, DX12 requires a resource to be in a specific state for each usage.
Rough Proposal
Always map General to COMMON. When recording command buffers, always transition the state to a specific state, do operation, and then transition back to COMMON. This is unfortunate, but well within the expected bahavior. It's good that many functions accept a list of jobs (i.e. multiple blits, multiple flushes, etc), so that we can combine the transitions together between multiple resources.
For exclusive resource we require to issue pipeline barriers for transfer the ownership onto different queues. In dx12 only the queue type is relevant (Graphics/Compute vs Copy), in between no resource state transition is required.
As first implementation step we should relax the current implementation to treat the cases of transition between the same queue type. Requires a bit of logic regarding the queue family id but nothing too fancy.
The next step would be to analyze the requirements on vulkan side and see how it interacts with dx12. In the ideal case it would fit within our current dx12 barrier bounds and we basically have 'free' resource transitions. Otherwise we require additional resource state transitions to deal with the Copy <-> Graphics/Compute transitions.