video_core: Add constant buffer support #147
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Next step after previous PR was to add constant buffers to shader recompiler. The goal of the design is to hopefully be able to handle more advanced cases like bindless or when sharps are nested behind many constant load operations. So in general, cases where sharp location is difficult to know upfront. When emitting IR we the recompiler is not aware of the sharp location. The emitted instruction will have a handle that is the SGPR of the loaded sharp and some additional arguments that we can derive without needing to read the sharp.
Then once IR has been emitted we run a resource tracking pass whose job is to follow constant loads and figure out where the sharp is located in memory. After it's loaded we patch the buffer instruction, replacing the handle with the binding index in the buffer resource array and compute the full address. Also it will check if the sharp address is aligned to UBO requirement of the host and fallback to SSBO if not. On SPIR-V side for simplicity buffers are arrays of floats (will also be uint in the future), so it can handle any provided address it has been given (not all loads can be expressed as a single composite array load, especially 3 dword loads whose offset is not 3 dword aligned). In the future I would like to experiment with attempting to reconstruct the struct layout of the UBO/SSBO.
For vulkan side, resources use push descriptors for the simplicity. I think some AMD drivers have broken push descriptors though so a fallback back with normal descriptor writes can be implemented as well without too much hassle.