You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vulkan is all about using multiple threads to record graphics commands, but we currently don't do it! Over time, a few things have been happening behind the scenes to make multithreaded graphics possible in lovr:
Error handling was changed to use error returns instead of longjmp.
A job system has been added, allowing background tasks to be launched and waited on.
core/gpu got support for recording commands from multiple threads.
So now, I feel like LÖVR is at a point where it could start to record GPU commands on multiple threads. To start, basically if you do lovr.graphics.submit(pass1, pass2, pass3), we would launch a job for each of those passes. They would record all their commands in parallel, and then, after waiting on all the jobs, we would submit the 3 command streams. So unfortunately it won't speed up the case where you only have 1 pass, but it will be pretty significant for something like shadow passes, where all the objects are rendered twice. This also doesn't allow Pass objects to be recorded from multiple threads at a time, that will be tackled separately.
A few things in the graphics module will need to be changed to be thread safe so that recordRenderPass and recordComputePass can run on multiple threads simultaneously:
Buffer allocation (getBuffer)
Bundle allocation (getBundle)
Scratch textures (getScratchTexture)
Pipeline hash
There are various ways to make them thread safe. They could be moved out of recordRenderPass and into the single threaded part of lovrGraphicsSubmit, they could use a mutex, or they could use atomics. I lean towards using a lock, at least to start with, because writing lock free code is very difficult and would take a long time. Using a lock means we could get this working much faster and see how it performs, see how bad contention is, etc. And it is always possible to refactor it to be lock free later, if needed.
The text was updated successfully, but these errors were encountered:
Vulkan is all about using multiple threads to record graphics commands, but we currently don't do it! Over time, a few things have been happening behind the scenes to make multithreaded graphics possible in lovr:
So now, I feel like LÖVR is at a point where it could start to record GPU commands on multiple threads. To start, basically if you do
lovr.graphics.submit(pass1, pass2, pass3)
, we would launch a job for each of those passes. They would record all their commands in parallel, and then, after waiting on all the jobs, we would submit the 3 command streams. So unfortunately it won't speed up the case where you only have 1 pass, but it will be pretty significant for something like shadow passes, where all the objects are rendered twice. This also doesn't allowPass
objects to be recorded from multiple threads at a time, that will be tackled separately.A few things in the graphics module will need to be changed to be thread safe so that
recordRenderPass
andrecordComputePass
can run on multiple threads simultaneously:getBuffer
)getBundle
)getScratchTexture
)There are various ways to make them thread safe. They could be moved out of
recordRenderPass
and into the single threaded part oflovrGraphicsSubmit
, they could use a mutex, or they could use atomics. I lean towards using a lock, at least to start with, because writing lock free code is very difficult and would take a long time. Using a lock means we could get this working much faster and see how it performs, see how bad contention is, etc. And it is always possible to refactor it to be lock free later, if needed.The text was updated successfully, but these errors were encountered: