There’s been a ton of hype lately about Vulkan being implemented into Blender, but it’s actually starting to concern me a bit. Not only are people claiming that it’s better than OpenGL but I heard somewhere (although I don’t know if it’s true) that Blender will default to Vulkan in Blender 5.0. This concerns me as, from my tests, Vulkan is not only highly unstable but also often slower than OpenGL. In fact the only case that I’ve seen Vulkan surpass OpenGL is the initial load of the Eevee viewport. Everything else is either the same speed or slower using Vulkan. I was just now rendering a pretty basic animation and wondering why it was freezing my entire PC (despite using a 4070 SUPER), turns out, Vulkan was using 100% of my GPU and a large portion of my CPU. I switched back to OpenGL, restarted, and tried rendering the animation and not only is it rendering like 5-10x faster but it’s only using about 6% of the GPU and around the same amount of CPU (it’s also using less RAM than Vulkan was). This animation is in Cycles which Vulkan was supposedly not supposed to affect (at least not to an extent that extreme) but I’ve also had similar issues with Eevee.
I don’t know if it’s just that the current state of Vulkan in Blender is poorly implemented or if Vulkan is just that much worse than OpenGL. I’m curious if anyone understands this stuff and knows whether Vulkan will actually ever be better than OpenGL or if we’re getting ready to default to a terrible backend API.
(FYI I looked for another thread about this but the only one was from 2019, if I missed one that’s already been made recently feel free to combine this thread with the other)
The devs. are focused on making sure that everything is working well before they begin work on performance.
The model that Blender development has always used is “get it working first, make it pretty later”. Optimization goes in the latter category, the only potential hazard is that sometimes the ‘make it pretty’ part can be forgotten and therefore omitted until an unknown date, but for something as critical as the viewport I would be surprised if they knowingly repeat some of the bad regressions that hid behind Eevee’s shininess in 2.8.
Vulkan’s nature of being closer to the metal may indeed give it the potential to make graphics run a lot faster, but it is not something that happens automatically, you still have to put a lot of work into it to actually get something that could not happen using OpenGL.
Yeah depending on the scene you can get different performances, I did a few tests if that might shed some light :
TLDR : It’s more efficient in lighter scenes and heavier scenes performs better in OGL…
OpenGl isn’t developed anymore, Vulkan is the future and will allow interesting stuff, however as Ace said it’s the initial implementation, the first step is making it stable and eventually optimization will come.
Making it default is also a way to make sure it’s widely tested, they might not remove OGL yet…
Probably the hype comes from the fact that it’s a lot of work to get it done and it will allows a lot of stuff. Then nowadays everything on internet is explained like if everything is going to change for the best without necessarily understand all the details !
The UI will especially in material preview, maybe reserving some GPU resources, would be interesting for some one to test if being in material preview while rendering is different than being in cycles render preview (with the render done in view-port).
My projects are not too complex and I do not find a noticeably difference.
I have not done any benchmarks, but am using Vulkan for the shader compilation times in material preview.
I’ve been testing Vulkan both at work and for Clash On Little Pond, and right now it’s just impossible to make the switch on either.
Sure, it starts faster and even renders faster… but the problem is, it doesn’t always render… quite often, it simply doesn’t.
They’re working on offloading VRAM to system RAM on Vulkan, which might improve stability, but even in OpenGL, Blender grinds to a halt when it has to offload VRAM. A 30-second render can easily jump to 3 minutes if Blender needs to offload VRAM… and this is on an RTX 5080.
I’ve got plenty of system RAM, but scenes are always bound to the GPU VRAM limits
I’ve tried everything, even converting textures to .dds. But what’s the point of PCI Express 5.0 if transferring textures from VRAM to system RAM is still painfully slow? Even worse, if you monitor the transfers, Nvidia’s drivers show PCI Express 5.0 as completely idle… so where’s the bottleneck!?
Well, not totally true, a modern CPU could crunch through GB of data in almost a blink of an eye, but there’s everything else around it to consider.
I mean you have the system RAM, PCIe slot bandwidth, VRAM bandwidth, along with the actual code to tell it what to do.
Combine that with the fact that if one is say GPU rendering, then some VRAM needs to be freed up (the code has to work out what it can remove from VRAM that isn’t needed for the area of the image that it is rendering at that exact moment), it then needs to tell the CPU what new data to load into the VRAM, which in turns needs to be pulled from system RAM, go over the memory bus, likely ‘through’ the CPU, out to the PCIe bus and loaded into the GPU VRAM.
Then the GPU needs to process that (which could just be for say an internal 128x128 pixel tile), only to discover that for the next tile, it needs some of the previous data it just purged out of VRAM to be loaded back in. So repeat the process all over again.
To make matters worse, my understanding is that Vulkan at the moment either doesn’t handle all that very well or at all (compared to OpenGL). So now on top of what would be a general slowdown if having to do that with OpenGL, turns into largely a no go with Vulkan.
This describes exactly what I’ve been experiencing… Thanks for the detailed explanation! Makes perfect sense now.
I have the Ryzen 7 9800 X3D with 128Gb of DDR-5 at 3600Mhz (the maximum I could get using the 4x32Gb configuration.) It was my best shot to solve the problem… but it didn’t made much if any difference.
This solution was mentioned on the last Eevee meeting:
It looks like the devs. do not want to change the default backend to Vulkan until they are really confident that there are no regressions from OpenGL, which should be an assurance for those concerned that Blender’s realtime rendering is heading in the wrong direction.
But, they have not exhausted the potential ways to resolve things yet, so hopefully they can succeed in making Vulkan an overall improvement for Eevee and Workbench.
Well that’s painful, especially if the CL is pretty high.
I know using 4 sticks puts extra strain on the memory controller and hence lower frequency, reason why using just 2 sticks is way preferred (outside of a Threadripper, etc CPU), but that still seems really low.
On a plus side and assuming that those RAM sticks are rated for like 6000MHz, rumors are that the next gen Ryzen CPU’s are getting an I/O update with maybe two memory controllers.
If true and since you already on AM5, you’d be able to drop in a new CPU and be laughing.
I’m Ok
I only use this machine for work and I had it at 3200Mhz on my old PC, so it still improved a bit. And anyway seems to make no noticeable difference in Blender.
Yeah I think they were originally rated at 5600Mhz using that AMD EXPO thing.
I didn’t knew about those rumors, Indeed perhaps someday will get something out of it.
I’m not much informed on the actual experience in use, except having seen videos presenting the features of 4.5.
But yesterday I updated to 4.5.1 from 4.4. and when Vulkan is active, I get Blender to hang, in eevee, with a ~10M poly scene with lineart modifier, fiddling with it, or changing to and from Cycles. No problem with OpenGL, while the scene is still slow (because of the lineart modifier).
And in both Vulkan and OpenGL I have not seen a difference in loading times: both can take ~15 seconds.
Knowing the implementation is not yet 100%, I would like to ask if those areas: eevee, lineart, grease pencil are ones that have yet to be optimized in Vulkan, or if I have to check elsewhere, thanks.
(Also, for context, my RTX 2060S is on the oldish side).
When I tested I got much worse perfs with Vulkan on complex scenes. Just like you over 10 millions poly.
On simpler scenes Vulkan is faster but it quickly loose over OGL.
I’m sure this is going to be improved , I’m not sure if we should report those as regression and make test scenes or it’s something the developers are already aware. I suspect they already tested with blender studio production files so , all in all I’m sure it’s going to be optimized given some time !
Thanks for the detailed explanation! Makes perfect sense now.