Why Blender Changing to Vulkan Is Groundbreaking [video](youtube.com)
youtube.com
Why Blender Changing to Vulkan Is Groundbreaking [video]
https://www.youtube.com/watch?v=7cta91Y53gs
47 comments
I don't get how cold start time would be affected, to this degree, by the API used to render the UI.
It isn’t.
I have never had Blender take 1:52 to open... ill open it now cold. 5 seconds.
If you're wondering about the source of the benchmark, refer to the following, page 36:
https://www.vulkan.org/user/pages/09.events/vulkanised-2025/...
https://www.vulkan.org/user/pages/09.events/vulkanised-2025/...
Perhaps he means opening a large scene with lots of textures or shaders or something.
That's exactly what it is. From the presentation link posted in another comment:
Test: Start Blender, open scene, final viewport 3000 objects, 550 materials, 200 images
Test: Start Blender, open scene, final viewport 3000 objects, 550 materials, 200 images
In that case, I’d seriously question the 6 sec vulkan startup time. Since the bottlenecks would be IO speed and memory availability, not processor speed. Certainly not GPU speed. Assuming assets with, say, 8k textures and millions of verts per mesh. All compounded by the scene containing, say thousands of said meshes.
Time in Vulkan or OGL would barely register against IO and memory when loading such scenes.
Time in Vulkan or OGL would barely register against IO and memory when loading such scenes.
[deleted]
But isn't one advantage of Vulkan over OpenGL that it's more standard to upload data such as large meshes and textures from multiple threads ?
But you do that in OGL in any case. Most software dealing with that large an asset base does so using the old fashioned shared context style threading.
It’s all gonna come down to how fast is your IO and how fast is your memory. 6 secs to load all that data, be it via vulkan style threaded submissions or OGL style threading via shared context and syncing, is not likely to happen on most laptops. Even workstations may struggle to read in and generate the necessary data. Most of the reading and generation stage is usually happening entirely outside of the gpu. All of the reading. And most of the generation. Both are going into main memory first.
Again, generation will be way faster than read in assets, but most of the assets would be getting read in. That’s IO before you even make a single vulkan or OGL call. No way around it.
It’s all gonna come down to how fast is your IO and how fast is your memory. 6 secs to load all that data, be it via vulkan style threaded submissions or OGL style threading via shared context and syncing, is not likely to happen on most laptops. Even workstations may struggle to read in and generate the necessary data. Most of the reading and generation stage is usually happening entirely outside of the gpu. All of the reading. And most of the generation. Both are going into main memory first.
Again, generation will be way faster than read in assets, but most of the assets would be getting read in. That’s IO before you even make a single vulkan or OGL call. No way around it.
Blender 4.2.0 opens to splash screen in about 500ms on my laptop. I have no idea what that number could mean.
Wonder if they pulled that from some biased telemetry.
It's probably a random text generator. Blender opens for me instantly, as it always did, since the first time I ran it on a 75 mhz Pentium.
This is a rather bad intro to a great topic, the comments point out a trove of errors and false parallels in the video.
Ouch, that video was painful. But the comments are great. I'm glad there are humans that try to make others aware of the issues there.
Vulkan is probably better than OpenGL. But don’t confuse that with Vulkan being good. It’s not. Vulkan is bloody terrible. Khronos design by committee is incapable of designing an API that doesn’t suck. It’s a shame we have such few choices.
Mind expanding what sucks about it? It's been a number of years since I did any serious OGL work, but at the time Vulkan looked like it was going to be a major step in the right direction.
Perhaps that is the problem, for any new general GPU API to get industry traction, driver, and os + tool support -takes a lot of time, and it feels obsolete by the time it is put to practical use.
Perhaps that is the problem, for any new general GPU API to get industry traction, driver, and os + tool support -takes a lot of time, and it feels obsolete by the time it is put to practical use.
IMHO Vulkan has two main problems:
- it inherited the 'vendor extension mess' of GL, e.g. the development process of Vulkan is to let GPU vendors write extensions which are eventually declared as 'core', this sort of 'design by committee^H^H^Hvendor' approach will ineviatably result in a hot mess of an API after a couple of years
- it tried to cover the whole range between low-end mobile and high-end desktop GPUs with the same API, pretty much all design warts of Vulkan exists because it had to cover mobile GPU architectures that were already outdated with Vulkan 1.0
At least Khronos is aware now about the issues, question is whether it will result in any actual improvements, and how long that will take:
https://www.youtube.com/watch?v=NM-SzTHAKGo
- it inherited the 'vendor extension mess' of GL, e.g. the development process of Vulkan is to let GPU vendors write extensions which are eventually declared as 'core', this sort of 'design by committee^H^H^Hvendor' approach will ineviatably result in a hot mess of an API after a couple of years
- it tried to cover the whole range between low-end mobile and high-end desktop GPUs with the same API, pretty much all design warts of Vulkan exists because it had to cover mobile GPU architectures that were already outdated with Vulkan 1.0
At least Khronos is aware now about the issues, question is whether it will result in any actual improvements, and how long that will take:
https://www.youtube.com/watch?v=NM-SzTHAKGo
Here's some deep context from someone who understands the situation. https://github.com/cmuratori/misc/blob/main/vulkan_dynamic_s...
Additionally yes, traction has been pretty weak too. It's still a wrapper on iOS/Mac and slower than DX12 on Windows. When you want something easy and crossplatform use OpenGL, and if you're really going to max out perf, then you use DX12 and Metal(which tbh might be easier than Vulkan too), so Vulkan's in a kinda awkward place.
Additionally yes, traction has been pretty weak too. It's still a wrapper on iOS/Mac and slower than DX12 on Windows. When you want something easy and crossplatform use OpenGL, and if you're really going to max out perf, then you use DX12 and Metal(which tbh might be easier than Vulkan too), so Vulkan's in a kinda awkward place.
Back in the day, when Blender still had an openGL python module[0], I made a pie menu prototype without too much fuss.
With Vulcan, with what I've seen, this would have been a major endeavor just to get to the point where you can get a canvas so you can put some pixels on the screen as you have to do a whole lot of state setup and bookkeeping. Not really something you can wrap as a relatively simple python API for someone to do quick experiments with.
I did some other completely random, definitely not recommended, stuff in Blender like this camera motion tracking thing which would rotate the viewport as the camera moved and have the camera video as the background (also using the python GL module) to reproduce this paper I found on the interwebs. I also found the Clippy sprite sheet but decided that was probably a bridge too far even though it wouldn't have been too hard.
So, yeah, if you want your program to be crazy extensible a simple API is probably the best. Might not matter too much these days as you can just get the robots to do the hard work.
[0] I heard they were going to rip it out but haven't checked if they ever did
With Vulcan, with what I've seen, this would have been a major endeavor just to get to the point where you can get a canvas so you can put some pixels on the screen as you have to do a whole lot of state setup and bookkeeping. Not really something you can wrap as a relatively simple python API for someone to do quick experiments with.
I did some other completely random, definitely not recommended, stuff in Blender like this camera motion tracking thing which would rotate the viewport as the camera moved and have the camera video as the background (also using the python GL module) to reproduce this paper I found on the interwebs. I also found the Clippy sprite sheet but decided that was probably a bridge too far even though it wouldn't have been too hard.
So, yeah, if you want your program to be crazy extensible a simple API is probably the best. Might not matter too much these days as you can just get the robots to do the hard work.
[0] I heard they were going to rip it out but haven't checked if they ever did
I am a fairly novice 3D programmer (but experience programmer) and Vulkan is much more complicated compared to OpenGL to even get the basic triangle working.
The basic idea was that you trade more upfront work against a much leaner and efficient render loop, which on its own isn't a bad idea (all modern 3D APIs do that). In Vulkan this idea is just badly executed (e.g. look at Metal for a much better - and much more programmer-friendly - implementation of that same idea).
I understand that. As someone that is doing this stuff for fun and wants something cross platform (Windows/Linux/BSD, I don't care about macs) with native code (C/C++) it just raises the bar a bit too high. I am sure I could figure it out, but it easily doubles the time needed to get going.
Perhaps because you should be using some kind of low/mid-level graphics engine. That's part of the difference between OpenGL and Vulcan: that ogl did more for you, even in immediate mode. Vk came about because getting more performance out of ogl was becoming difficult because it didn't directly expose enough of modern hardware, or only exposed it in a specific less-performant way.
Yes, it takes way more code to start from scratch on vulkan, but that's a trade-off against being able to better optimize exactly to your use case, if you need to.
Yes, it takes way more code to start from scratch on vulkan, but that's a trade-off against being able to better optimize exactly to your use case, if you need to.
I am burned out by frameworks in my day job which is basically working in full stack web land and I want to get away from that. So using anything other than libraries is out of the question as far I am concerned. I could have use Unity / Unreal and been further along, but it isn't going to be enjoyable.
I understand there are situations where more performance is desirable and that vulkan fills that niche. However if you are building simpler games, are you really going to need it? If I am building say a puzzle game, do I really need maximum 3D graphics fidelity and performance? I would argue probably not.
I am using OpenGL in my projects for now and if I feel the need to learn Vulkan I will. Almost all the materials online for OpenGL 3.3 are still relevant and unlike web world (where things are depreciated every 6 months) the code still works fine. The C++ linter / analysis tools I am using with CLion throw up warnings but these are normally fairly easily to fix.
I understand there are situations where more performance is desirable and that vulkan fills that niche. However if you are building simpler games, are you really going to need it? If I am building say a puzzle game, do I really need maximum 3D graphics fidelity and performance? I would argue probably not.
I am using OpenGL in my projects for now and if I feel the need to learn Vulkan I will. Almost all the materials online for OpenGL 3.3 are still relevant and unlike web world (where things are depreciated every 6 months) the code still works fine. The C++ linter / analysis tools I am using with CLion throw up warnings but these are normally fairly easily to fix.
Recent Blender versions have OpenGL version dependencies and VRAM requirements that aren't supported on a lot of older or lower-end PCs.
For fans of, say, older laptops that have "mechanical" keyboards, or people who only have access to less-powerful hardware, I wonder whether Vulkan will re-enable support for the latest Blender.
(Though the VRAM might still be a problem. As will local rendering of expensive animations.)
For fans of, say, older laptops that have "mechanical" keyboards, or people who only have access to less-powerful hardware, I wonder whether Vulkan will re-enable support for the latest Blender.
(Though the VRAM might still be a problem. As will local rendering of expensive animations.)
Blender is the 1st software (not a game) I'm dealing with, which refuses to start with OpenGL 3.3 available. Nowadays Blender requires 4.3 [1].
> VRAM requirements
2 GB [1].
[1] https://www.blender.org/download/requirements/
> VRAM requirements
2 GB [1].
[1] https://www.blender.org/download/requirements/
GL 4.3 as minimal version most likely means that they are using compute shaders. The GL 4.3 standard is 13 years old though, so it's not exactly bleeding edge any more ;)
I've been thinking Blender uses OpenGL only for previews not for the actual rendering. Could not compute shaders be optionally enabled?
The OpenGL 3.x hardware itself is capable of OpenCL 1.x including CL/GL interop.
The OpenGL 3.x hardware itself is capable of OpenCL 1.x including CL/GL interop.
AFAIK the entire Blender UI (not just 3D preview) runs on top OpenGL.
I don't know if compute shaders were the reason for the GL 4.3 requirement, but from own experience, having to support different GL versions in the same code base isn't exactly trivial without resulting in a granular #ifdef-mess.
The cleanest solution is to have different backends for different GL versions, but that means a lot of duplicate maintenance effort and code.
But tbh, any cheap laptop made in the last decade should be able to run GL 4.3.
The only exceptions I've seen so far are VMs and the Raspberry Pi.
I don't know if compute shaders were the reason for the GL 4.3 requirement, but from own experience, having to support different GL versions in the same code base isn't exactly trivial without resulting in a granular #ifdef-mess.
The cleanest solution is to have different backends for different GL versions, but that means a lot of duplicate maintenance effort and code.
But tbh, any cheap laptop made in the last decade should be able to run GL 4.3.
The only exceptions I've seen so far are VMs and the Raspberry Pi.
What’s really groundbreaking is the amount of ignorance displayed in this video. Also, I’m curious how long will it take for blender to reach performance parity with OpenGL. Houdini has been taking a few years now and VK is still 2x slower then opengl apparently.
> Houdini has been taking a few years now and VK is still 2x slower then opengl apparently
Ouch, since OpenGL isn't exactly known for being performant to begin with.
This sounds a lot like Houdini has its core rendering code designed around the granular 'state-soup model' of OpenGL and is now trying to emulate that same behaviour on top of an API which expects that all state combinations are baked upfront into immutable objects (which in some situations - especially in DCC tools - may turn out to be impossible, because they may not be able to predict all required state combinations - or the number of required state combinations is simply to large too create upfront).
There's quite recent extensions for Vulkan (VK_KHR_dynamic_rendering, VK_EXT_ extended_dynamic_state and VK_shader_object) which try to break the extreme rigidity of the Vulkan 1.0 API and go back to a more OpenGL like dynamic state soup (which IMHO is going too far, because GL's granular state soup is also its biggest problem - the best compromise is somewhere in the middle, see D3D11 or Metal) - but it might help moving code from GL to Vulkan without having to discard and create pipeline objects all the time.
Ouch, since OpenGL isn't exactly known for being performant to begin with.
This sounds a lot like Houdini has its core rendering code designed around the granular 'state-soup model' of OpenGL and is now trying to emulate that same behaviour on top of an API which expects that all state combinations are baked upfront into immutable objects (which in some situations - especially in DCC tools - may turn out to be impossible, because they may not be able to predict all required state combinations - or the number of required state combinations is simply to large too create upfront).
There's quite recent extensions for Vulkan (VK_KHR_dynamic_rendering, VK_EXT_ extended_dynamic_state and VK_shader_object) which try to break the extreme rigidity of the Vulkan 1.0 API and go back to a more OpenGL like dynamic state soup (which IMHO is going too far, because GL's granular state soup is also its biggest problem - the best compromise is somewhere in the middle, see D3D11 or Metal) - but it might help moving code from GL to Vulkan without having to discard and create pipeline objects all the time.
I hate seeing how awesome Blender...free software is..in comparison to roughly $5k a seat program like Revit who's graphics rendering looks like it comes from a 90s shareware floppy disk.
Nice to see Autodesk downvoting.
THIS! I'm working at a large construction project now, and am continually amazed at what "state-of-the-art" realtime 3D in Revit looks like. Yes, all these corporate laptops have shitty GPUs, but come on, I got better fidelity in Quake 3 Arena 25 years ago on machines with 1/10th of the spec.
Did anyone order graphics with a side of tearing?
Shipping Vulkan in production on Linux is a challenge. Chrome was dealing with it for a while. Recently, with Zed ported to Vulkan, we saw the variety of half-broken platforms and user configurations.
I'd recommend Blended to not close the door on OpenGL and instead keeping it as a compatibility fallback.
I'd recommend Blended to not close the door on OpenGL and instead keeping it as a compatibility fallback.
> Recently, with Zed ported to Vulkan, we saw the variety of half-broken platforms and user configurations.
Thank you for sharing this! It'll be good to prevent others from following down the same path (my team included).
How is life at Zed? Have y'all raised capital in line with Windsurf / Cursor? Are you bootstrapping instead?
It's phenomenal that y'all are working natively in Rust rather than building on kludgy web tech.
Thank you for sharing this! It'll be good to prevent others from following down the same path (my team included).
How is life at Zed? Have y'all raised capital in line with Windsurf / Cursor? Are you bootstrapping instead?
It's phenomenal that y'all are working natively in Rust rather than building on kludgy web tech.
I'm not employed by Zed, so I can't answer these questions. But the product itself is great!
Another option might be to write a D3D render backend for Blender and run that on top of DXVK on Linux (which is probably the most robust and most tested 3D rendering path on Linux thanks to Proton - with the assumption that DXVK contains tons of workarounds for various Vulkan driver problems that had been encountered in the wild by Proton).
on Linux it seems the direction is to drop the OpenGL drivers and run a compatibility layer on top of Vulkan.
Sure. Maybe that's the forcing function for them to nail down all the kinks. Example: https://github.com/kvark/blade/issues/205
[deleted]
I just tested a cold start of blender 4.4.3 on my system (10th gen i7, 32gb ram, 4070 ti S 16gb, Fedora Linux)
it was about 8 seconds, and that was through steam...
Warm start was about 3 seconds.
> This year, Blender is transitioning to Vulkan, which marks one of the biggest performance boosts in its history: weʼre talking about a leap from a cold start time of a minute 52 to opening Blender in 6 seconds. // Vulkan ... simply put, itʼs the industry standard API. [...] Blenderʼs current API is OpenGL, which has some major flaws. OpenGL ... really struggles using multi-core CPUs. // OpenGL ... automatically sets up most low-level features like memory management, synchronization, and hardware interactions. ... But high-level APIs come with a huge trade-off: theyʼre slow. // Writing code that performs better in Vulkan is a difficult task ... OpenGL is like infinitely easier than Vulkan. Vulkan ... is a low-level API. [...] Vulkan can perform up to 18 times better on certain tasks. [...] For tasks that heavily rely on the UI, we will see a much more performant system. [...] Essentially, interactions between the user and the program will be much faster, but the underlying automatic system will not see a direct speed increase from Vulkan. ... While I would love for my final render to be faster, I would much prefer to have a performant viewport thatʼs more stable and faster, which is what weʼll have with Vulkan. But this is not the only thing it brings to the table. Many corporate sponsors have granted money to Blender primarily for a Vulkan integration. AMD is donating $120,000 per year to help fund Blenderʼs transition to Vulkan.