Blender Vulkan - Status report

Quick question: Is it expected that blender 3D viewport will run faster (More FPS, less lag, etc.), when Vulkan is fully implemented?

That depends on other stuff. GPU drawing isn’t the main bottleneck in animation playback. So there might not be a noticeable speed increase there. Improved performance isn’t the reason why we switch to Vulkan, but there might (and are) areas where we could make our drawing code more Vulkan compliant and it might improve the performance a bit. Although that will be done by regular development, and not part of this project.

The goal of the Vulkan backend is to be at least on par with OpenGL performance. Which would already by a huge achievement.


Hi @Jeroen-Bakker, where can I read about what the benefits of Vulkan are over OpenGL. I’d like to know why this change is being made, and what its usefulness will be in the future.

See first message in this post for the initial reasoning. As for future developments. OpenGL standard isn’t developed anymore so there is no future there :slight_smile: modern GPU features like Hardware ray tracing, mesh shaders and others would therefore not be accessible when using OpenGL, but would on Vulkan. This list of GPU features are growing with each driver update.

And yes perhaps those features will enable additional performance. But requires a different project.

The vulkan project builds the road, but other projects would be building the cars and trucks that drive over the road.



In Eevee until a few versions of Blender ago, there was a limit of (Unique) textures of 24, beyond which the material became Pink, I knew this limit, now it seems to no longer exist, or at least not at 24.

The same happened in Macintosh, where the maximum number of textures was even lower (But I don’t remember the exact number)

Can you understand the new limit? I suppose that even on the Macintosh this limit was raised with the introduction of Vulkan.

It would be great to get clarification if you can.

Thank you very much for the work you do :blush:

As I remember this patch (found the patch) for the Mac versions of Blender the increase in textures number happened a little after the Apple devs came on board. The change happened with a patch to Blender and a patch to MacOS itself (11.1 and newer). I’m pretty sure users had to upgrade to the latest version of MacOS at the time along with the latest version of Blender to notice the changes.
But yes it was solved for Mac devices.

Edit: Found the older patch. Blender Archive -

vulkan is much much better with stuff like threading, and resource management.

in openGL you could not cache a shader so there is no ‘pop’ the first time its seen,
this happens by default in vulkan,

Hi, I have a question with vulkan backend how you can permit to blender give large scene or huge amount
(complex scene) of gemetry ? i want understand the process

  • Stock the geometry directly in a temps folder ?
  • Accelerate the viewport by GPU ?
  • many other things ?

Because actually when you are close to 15 - 20 millions of tris blender crash of the perf are divided by 5 - 6x and before that the performance are closely degraded more geometry you have. So i’m curious to understand this beautiful things ! i know Meshlets Vulkan can be take a part of the cake !

Vulkan backend are for entirely blender software not for only one render engine ? Because as i can understand at the beginning is only for eevee-next and later he come entirely everywhere in blender ?

Vulkan does NOT cache shaders it has the option to cache pipelines, but don’t expect to much from that. Many games precompile shaders to an intermediate format in order to reduce loading times. Backend compilation is often done when installing a game. Blender isn’t a game, users and add-ons can actually change the GLSL code. We also want to keep the flexibility of debugging shaders and other aspects that you don’t expect to do in games.

It is still to early to discuss how the actual backend will evolve. Our first goal is to make sure we are feature complete, before we start with getting the performance on the same level as OpenGL. When that is completed and the backend is mature enough the plan is to remove OpenGL. When that is done new development projects need to start in order to find out how to actually handle large geometry. There are millions ways to do that, which one we will chose depends on many factors.

In Blender it is not possible to mix and mingle OpenGL calls with Vulkan calls. When you you start blender the full UI is drawn using one or the other.

In the short term Vulkan backend development is in a lower pace. The reason is that we need more development effort stabilizing EEVEE. Community patches will be reviewed and developments that would directly benefit EEVEE stabilization will still be done.


Thank you Jeroen ! It’s ok for me i understand completly in long terms when vulkan gonna be stabilized, blender run only on vulkan backend ! Exited to see this “Many things” for have a real complex and huge geometry inside the viewport ! Good luck ! :slight_smile:

1 Like

Will the switch to vulkan allow AMD linux users to use cycles with the gpu without having to deal with AMD ROCm drivers ?


No, this is unrelated.

1 Like

From the current update in Oct, the team wants to know about user experiences. Is this the place to report my experience?


Will the Vulkan backend break the current viewport drawing API (the gpu) module calls?

The gpu module is the platform agnostic successor to the bgl module (which is of course opengl specific). So as long as you only use the gpu module you should be fine.


My only wish for Blender since always, was to have good performance with high poly objects. I often work with Houdini, and export geometry to use inside Blender. The behavior is kinda random, like sculpting a 2 million poly rock is simple, but once every 30 seconds I get a major freeze and such. Trying to delete a polygon in such mesh takes 20 minutes. Don’t even get me started on using undo. If I have to undo I just have 10 auto saves in background to load, because it’s faster than undo.

Would Vulkan improve the general performance in those cases? I’m in no means a developer, but I would adress those issues in priority. I love every new blender release, but I always read patch notes to see anything relevant to undo / lots of geometry performance :smile:


@Spiotrx758 would you mind sharing a file that takes 20 minutes to delete a single polygon, wouldn’t mind analyzing it and see what is actually happening during those 20 minutes. Can be via DM here or at Blender chat. and share the steps you do. It might also be platform dependent as sculpting 2m meshes and removing a single face is what is done often. Which would also be good to known.

I doubt they are GPU related bottlenecks, but who knows and I can poke the right people if it is really an issue.

Vulkan would not improve in this sense as modelling, sculpting and undo are CPU based operations.


That sounds a lot like autosave ?

1 Like

I think he is just talking about the edit mode which has dismal performance with dense meshes, things get worse if the mesh is also part of a larger dependency graph. I have these issues myself too but I doubt that they are display or GPU related.


I decided to spend the day analyzing and comparing performance between Blender, Houdini, and Maya.
Actually, I’m very impressed by blender’s performance with huge geometry objects.

My goal was to make a super realistic snow simulations and rocks, with as much geometry as possible without “faking” it visually. To look for the problem, I decided to create a clean .blend project, and import just the rock with 20.000.000 polygons from Houdini.

With Blender 4.0.2, my hardware is :
GPU : RTX 4090
CPU : Ryzen 9 7900x
RAM : DDR5 4x16Gb (Stable at 3600mhz)
M.2 NVMe with 7000mb/s speeds
Windows 11

When importing the 5gb .obj rock, my blender uses around 11Gb of ram. When I open edit mode, it goes up to 36Gb of ram (I’m not a dev but I assume that’s normal), but my cpu usage moves between 5% to 70% and from multi-threading to single-threading randomly, for around 20-30 seconds until I can edit the geometry.

Now here comes the selection part. I can navigate freely, I can select a piece of geometry with a short delay, and I can even delete it without more than 15-20 second delay. But If I keep selecting other parts and deleting them, it gets longer and longer. Third try, and I see on ryzen master software 2 cpu cores running, and ram being the same at around 37Gb. Now it can take from 2 minutes to 5 minutes, and sometimes much, much longer.

I don’t understand what’s causing it, but I think I might have not enough ram maybe, and it’s hardware related? Or I’m just overkilling it with the polycount and I should in the end find better ways make snow and rocks :smiley: When sculpting though, it’s very smooth until I add shapekeys, but even without, at a random time blender can just hang for a few seconds at very random times. Also, when I use texture painting, it seems to behave similarly. I paint or clone, and it works smooth, but with each stroke it becomes slower and slower until one click maneuver can cost me 51 years :smile: With larger scenes it’s also faster to load a previous save, rather than undo a few times.

Also, I’m not sure which information is correct, because task manager for example, shows 22gb ram used, but blender says 30gb memory usage. So maybe It is simply not enough ram, but I’m confused because the real usage is not displayed correctly.

Edit: I just checked real quick after a few days during production, and windows Task Manager shows me currently that Blender uses around 550mb ram, but ram usage is at 53%, and in blender it shows 23gb used. Every few clicks on the interface, blender will just freeze for a few seconds. I assume it’s because I have a huge 10gb .blend file, but I don’t understand why the behaviour is so unconsistent.

I didn’t find much about it online, until I found the Blender Vulkan blog post, and I noticed that it would benefit the performance of large scenes and texture painting. I’m very excited about the development of this :slight_smile: