Introduce Context semantics to GPU resource locking

Resources on the GPU can be fairly convoluted and involve overlaps which can lead to the same GPU resources being utilized with different views, we previously utilized fences to lock resources to prevent concurrent access but this was overly harsh as it would block usage of resources till GPU completion of the commands associated with a resource.

Fences have now been replaced with locks but locks run into the issue of being per-view and therefore to add a common object for tracking usage the concept of "tags" was introduced to track a single context so locks can be skipped if they're from the same context. This is important to prevent a deadlock when locking a resource which has been already locked from the current context with a different view.
This commit is contained in:
PixelyIon
2022-06-26 14:32:34 +05:30
parent d913f29662
commit 6b9269b88e
13 changed files with 336 additions and 111 deletions

View File

@ -42,16 +42,16 @@ namespace skyline::gpu {
BufferManager(GPU &gpu);
/**
* @return A pre-existing or newly created Buffer object which covers the supplied mappings
*/
BufferView FindOrCreate(GuestBuffer guestMapping, ContextTag tag = {});
/**
* @return A dynamically allocated megabuffer which can be used to store buffer modifications allowing them to be replayed in-sequence on the GPU
* @note This object **must** be destroyed to be reclaimed by the manager and prevent a memory leak
*/
MegaBuffer AcquireMegaBuffer(const std::shared_ptr<FenceCycle> &cycle);
/**
* @return A pre-existing or newly created Buffer object which covers the supplied mappings
*/
BufferView FindOrCreate(GuestBuffer guestMapping, const std::shared_ptr<FenceCycle> &cycle = nullptr);
};
/**