[meta] Vulkan problems

[kvark]

Here is a list of problems that we need to solve in order to have a viable Vulkan backend:

1. Resource states. When recording commands, we need to know the initial state of each resource. This can't be automatically tracked, since, when recording, we don't know the order of submission.
   • Solution A: define a "default" state, which a resource is expected to be between command buffer executions, and enforce the relevant transitions at the end of recording.
2. Command pools. A pool is externally synchronized, so we can't allow two command buffers being recorded in parallel if they share the same pool.
3. Command buffer fences. Any CPU-accessible resource can't be modified while GPU is working on it. Command buffers are there too. We should keep extra command buffers somewhere and re-cycle the ones that finished execution.
   • Solution A: when an encoder is submitted, we can have a special flag saying that it should be reset, in which case the inner command buffer is replaced with another one from the pool.
4. Initial resource data. A typical user task is to load a texture and use it as an SRV, never modifying it. Out model was built to allow that resource to be loaded asynchronously from multiple threads, on the backends that support it at least. However, in Vulkan we'd have to create a staging resource first, fill it up, and then use a transfer queue operation to copy the contents into the target (DEVICE_LOCAL) resource. Hence, we'd need an execution context for such operation.
   • Solution A: remove the corresponding API, encourage to use Usage::Upload directly by the user
   • Solution B: keep the API but return an error on the backends that don't support it. Apparently, only Metal and D3D11 support it natively. We can have a capability flag to indicate that.

[Bastacyclop]

What if explicitly creating a memory::Usage::Upload resource and submitting a copy command was the 'official' way to upload data into a memory::Usage::Data resource ? It does complicates things a bit for the user but still feels intuitive. It makes the user aware of previously implicit copies (at least I think there are ?) and makes him want to directly load data into the upload resource to avoid an additionnal copy, which is good ? I don't know if all the backends would be able to efficiently support this workflow though.

[kvark]

@Bastacyclop yes, that would be a valid course of action. All the backends would support it just fine. The only downside is - user inconvenience, and it's not like we can do anything about it on Vulkan...

[msiglreith]

Superseeded by our low level API #1102 and vulkan portability issue #1354