What’s the current expectations for VR performance in Vulkan?
That really depends on the platform. I don’t have access to many devices and rely mostly on using simulators. So I would expect that they should be working. But actual performance isn’t tested.
There are some issues inside OpenXR (specifically related to Vulkan) that currently only allow us to update a single eye at a time without chaining rendering on the GPU of the second eye.
Technical details: We are not able to start OpenXR inside our Vulkan context and need to transfer the render result to another context. This process cannot be chained on the GPU and requires CPU synchronization. Games do not have this issue as they can start OpenXR before the Vulkan context and make sure their context can handle both. The CPU synchronization can be improved but would require reworking a larger part of OpenXR integration. Starting OpenXR before Vulkan isn’t really user friendly as the VR headset would already be active when Blender starts.
I would say if there are performance regressions, report them so we can collect the need of scheduling a refactor project on OpenXR. In the short term I would consider them as known (expected) issue.
4 Likes
Thanks for the explainer. I noticed some subpar VR performance in some quick tests. I will do further testing and create bug reports for it later today.
Edit: A report is up here: #138977 - Vulkan VR performance is significantly worse than OpenGL - blender - Blender Projects
1 Like
I made a post about the problem with navigation, please pay attention to it!
Hi Jeroen,
Thank you so much for all of your efforts for this implementation. I figured I can provide user feedback on my experience so far with Vulkan.
I ran into an issue which I am not able to reliably reproduce… so I’m a bit hesitant to create a bug report?
I played around with my old production files and at random got a system crash, two times for now
but I can’t reproduce them reliably and don’t know how I can file a bug report with nothing to report, since I am not able to reproduce the same crash in the same file.
I tried replicating what I had done before the crash, but it did not result in another crash, and I haven’t encountered another one so far.
Any guidance?
These are always tricky.
As Vulkan is low level it can be tricky to reproduce. Do you have a crash report? Perhaps that already provides some information. Otherwise keep a close eye on system monitors and try to keep up to date with the daily builds. The stability improves almost every day.
You can always try to report, and see if one of the triagers can reproduce/see anything strange.
Hope we can narrow it down!
4 Likes
I really do hope Vulkan can allow EEVEE to utilize multiple GPU. Helps when you have groups of characters with a ton of rigging/poly/texture going on.
Will Vulkan truly improve viewport/rig speed/ or anything other than rendering? I’m not really informed of it’s potential entirely, but really do hope it evolves for use with cheaper Nvidia GPUs. Hard to find new ones available, but if stacking old ones help everything, then that could expand the market to make Blender even more accessible for those who want to link older GPU or even newer GPU for gigantic scenes and fx.
Would this be the right course of understanding, or there’s more to it than just Vulkan implementation to achieve a boost in quality & quantity experience optimized enough for large scenes to not lag.
(Not related to Vulkan) Multi GPU EEVEE rendering isn’t possible/realistic. The algorithms are specific for single GPU rendering. Scaling them to multiple GPUs will be (much) slower then running on a single GPU.
Vulkan improves compatibility and stability. It should still render the same as OpenGL. Future developments can be made, that will improve many facets, but that doesn’t change the market availability and pricing of GPUs, or that GPU features will become available on older GPUs
Best is to test and give feedback on the current project.
3 Likes
Inexplicably collapsing
daoju.crash523.txt (49.6 KB)
room01.crash.txt (51.9 KB)