anonymous/yuzu - yuzu is the world's most popular, open-source, Nintendo Switch emulator — started by the creators of Citra. It is written in C++ with portability in mind,

	Commit message (Collapse)	Author	Files	Lines
2020-09-19	renderer_vulkan: Make unconditional use of VK_KHR_timeline_semaphore	ReinUsesLisp	1	-42/+28
	This reworks how host<->device synchronization works on the Vulkan backend. Instead of "protecting" resources with a fence and signalling these as free when the fence is known to be signalled by the host GPU, use timeline semaphores. Vulkan timeline semaphores allow use to work on a subset of D3D12 fences. As far as we are concerned, timeline semaphores are a value set by the host or the device that can be waited by either of them. Taking advantange of this, we can have a monolithically increasing atomic value for each submission to the graphics queue. Instead of protecting resources with a fence, we simply store the current logical tick (the atomic value stored in CPU memory). When we want to know if a resource is free, it can be compared to the current GPU tick. This greatly simplifies resource management code and the free status of resources should have less false negatives. To workaround bugs in validation layers, when these are attached there's a thread waiting for timeline semaphores.
2020-04-29	vulkan: Remove unnecessary includes	Lioncash	1	-1/+0
	Reduces some header churn and reduces rebuilds when some header internals change. While we're at it we can also resolve a missing include in buffer_cache.
2020-04-11	renderer_vulkan: Drop Vulkan-Hpp	ReinUsesLisp	1	-14/+15

2020-02-28	vk_state_tracker: Initial implementation	ReinUsesLisp	1	-37/+5
	Add support for render targets and viewports.
2020-02-14	vk_query_cache: Implement generic query cache on Vulkan	ReinUsesLisp	1	-0/+15

2019-12-13	vk_scheduler: Delegate commands to a worker thread and state track	ReinUsesLisp	1	-25/+173
	Introduce a worker thread approach for delegating Vulkan work derived from dxvk's approach. https://github.com/doitsujin/dxvk Now that the scheduler is what handles all Vulkan work related to command streaming, store state tracking in itself. This way we can know when to reupload Vulkan dynamic state to the queue (since this one is invalidated between command buffers unlike NVN). We can also store the renderpass state and graphics pipeline bound to avoid redundant binds and renderpass begins/ends.
2019-07-07	vk_scheduler: Drop execution context in favor of views	ReinUsesLisp	1	-31/+47
	Instead of passing by copy an execution context through out the whole Vulkan call hierarchy, use a command buffer view and fence view approach. This internally dereferences the command buffer or fence forcing the user to be unable to use an outdated version of it on normal usage. It is still possible to keep store an outdated if it is casted to VKFence& or vk::CommandBuffer. While changing this file, add an extra parameter for Flush and Finish to allow releasing the fence from this calls.
2019-02-22	vk_scheduler: Implement a scheduler	ReinUsesLisp	1	-0/+69
	The scheduler abstracts command buffer and fence management with an interface that's able to do OpenGL-like operations on Vulkan command buffers. It returns by value a command buffer and fence that have to be used for subsequent operations until Flush or Finish is executed, after that the current execution context (the pair of command buffers and fences) gets invalidated a new one must be fetched. Thankfully validation layers will quickly detect if this is skipped throwing an error due to modifications to a sent command buffer.