It’s an embarrassingly simple question but I’ve not been able to track down a definitive answer for this in the docs.
I understand that the Unity renderer itself can be multithreaded, and also how CommandBuffers let you hook into the various points during camera rendering. However this question is specifically about whether you can call methods like CommandBuffer.DrawMeshInstanced from a thread that is not the Unity main thread.
I don’t think there will be any performance benefits from doing CommandBuffers.DrawMeshInstaced from non-main thread though.
CommandBuffer is used to supply commands which are render events.
They’re not executed immediately, but only at certain points in render pipeline.
Its possible to do something like a main thread dispatcher to queue up whatever render events to do from the separate thread, and then add those commands to the CommandBuffer on the main thread.
hehe no worries @Antypodish , I usually lurk there too but this one was about Graphics.CommandBuffers
@VergilUa I’ve seen similar answers to this from different places but no official information on whether it’s actually thread-safe etc to do. Testing also doesn’t give a true answer in the way the manual or a specification would and that’s what I’m after unfortunately. To find out if it’s even a valid/legal thing to do (regardless of efficacy or best practice)
Is Rendering.CommandBuffer thread safe? Is it alright to entirely construct a command buffer off of the main thread, and then use the main thread to dispatch drawing with it?
It doesn’t appear to be. We mark up thread safe API with an attribute, and this API doesn’t have the attribute, so I expect it will throw errors if used on a thread.
Is there a particular reason, or is it just because it hasn’t been tested for that? Would be highly beneficial for our game on consoles, due to the high CPU overhead of doing a lot of setup in a command buffer, in our case. Would be especially ideal if it could be jobified, so we could hook it into an existing system.