Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multithreaded GPU Submission #847

Open
bjornbytes opened this issue Feb 24, 2025 · 0 comments
Open

Multithreaded GPU Submission #847

bjornbytes opened this issue Feb 24, 2025 · 0 comments

Comments

@bjornbytes
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant