> 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.
https://www.vulkan.org/user/pages/09.events/vulkanised-2025/...
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.
- 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:
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.
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'd recommend Blended to not close the door on OpenGL and instead keeping it as a compatibility fallback.
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.
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.)
> VRAM requirements
2 GB [1].
The OpenGL 3.x hardware itself is capable of OpenCL 1.x including CL/GL interop.
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.
