Vulkan: Feedback and testing

Feature & Design Feedback
1

Hi all,

The Vulkan project is getting to a state where we need to validate if it can become an official supported backend (not experimental). Last month effort was spent to make the viewport performance comparable to OpenGL. Vulkan is used to draw the user interface and EEVEE.

[!NOTE]
Using Vulkan as a Cycles backend is NOT a target. It will have too many limitations concerning maintainability and features.

We would like feedback on stability, features not working and troublesome platforms. Just try it out for some hours/days and provide feedback.

When checking, make sure you always run the latest Blender 4.5 Alpha build . The Vulkan backend can be enabled in the preferences (System->Display Graphics->Backend) and requires a restart of Blender. Or start blender from the command line blender --gpu-backend vulkan to enable the backend for a single session.

Supported platforms

This next table shows the platforms that would work. Platforms that are unsupported don’t have Vulkan 1.2 support or have issues in the drivers that require a lot of work to work around.

Devices Windows Linux
NVIDIA
GTX 700 - GTX 800 NVIDIA 500+ Unsupported
GTX 900 - GTX 1000 NVIDIA 500+ NVIDIA 550+
RTX 2000 - RTX 5000 NVIDIA 500+ NVIDIA 550+
AMD
HD 7000 - HD 8000 Unsupported Mesa
R 200, R 300 Unsupported Mesa
RX 400 - RX 600 AMD Official/latest AMD Official/latest, Mesa
RX Vega AMD Official/latest AMD Official/latest, Mesa
RX 5000 - RX 9000 AMD Official/latest AMD Official/latest, Mesa
Intel
Intel 6-10th gen iGPU Unsupported Mesa
Intel 11th gen iGPU and above Intel Official/latest Mesa
Intel Arc Intel Official/latest Mesa
Qualcomm
Adreno X1-85 GPU Qualcomm Official Not tested

Known issues

  • Cycles GPU rendering (NVIDIA) might be slower compared to OpenGL. This is due to that Vulkan doesn’t have direct access to the Optix/Cuda memory (yet).
  • Some add-ons rely on OpenGL specific API calls. They are not supported and can crash when used. These add-ons needs to remove the usage of bgl and related API calls.
  • Some gaming/recording overlays using vulkan layers are known to be incorrectly implemented and might crash when Blender starts. Blender has no influence on this and these overlays needs to be disabled/uninstalled before Blender starts.

Still in development

Rendering performance (Cycles and EEVEE), stability, bug fixes.

Not working

USD/Hydra is not working. We have done some initial tests using a Vulkan enabled USD/Hydra build, but the device capabilities are incorrectly loaded, resulting in incorrect vulkan commands and eventually system wide crashes due to memory corruption. The way forward would be to compile a debug mode build of USD/Hydra to follow exactly what is (not) happening. We would target USD/Hydra support for Blender 5.0

Follow the project

The project writes a detailed status report every other week. Checkout gpu-vulkan-status-report to follow the status of the project.

Happy Blending!
:vulcan_salute:

Edits:

  • OpenXR has been implemented
  • Wayland crash has been solved
52 Likes
2

Initial feedback: the known issues alone are reason enough to not pull out of experimental - or to at least make it an opt out or in user preference.

Congrats on the milestone!

1 Like
3

Hi thanks!

There is a difference between out of experimental and default. With “out of experimental” it will still be the second option behind OpenGL. Similar to Blender 4.3 and 4.4 we just remove the words “Experimental” from the preference. The first release where it might become the default (not decided yet) would be Blender 5.0. Even in Blender 5.0 OpenGL will still be an option (there is no final date when OpenGL will be removed).

Looking at the known issues. Most of them are not in our control.

  • Add-on developers have been asked to migrate since Blender 3.4 (December 2022). Their add-ons will not work in Blender 5.0 due to changes in the API. Most add-ons have been updated. But rarely we come across a community add-on that calls OpenGL directly.
  • Gaming/recording overlays is not software that we control. At most we can provide a list of known overlays that are not respecting the spec. Feedback is needed to collect these overlays.
  • The might be slower part of cycles we need to have more feedback on. If this is a bigger regression we can prioritize it.

Hope this clarifies a bit more and explains why postponing might not improve the situation that much. Happy testing and providing feedback, so we can steer the decision making!

10 Likes
4

I’ve already used with EEVEE in 4.4. Very fast and I enjoyed a lot. I’ll do some tests with 4.5 alpha for sure. Thanks.

5

Exciting stuff!
Right away I’m noticing strange 3D viewport mouse behavior in Vulkan that doesn’t seem to be present on OpenGL. Simply panning and orbiting has a chance to jump the mouse into a different location, as if some kind of cursor re-centering math is over compensating.

System Information
Operating system: Linux-6.13.9-200.fc41.x86_64-x86_64-with-glibc2.40 64 Bits, WAYLAND UI
Graphics card: NVIDIA GeForce RTX 3080 NVIDIA Corporation NVIDIA 570.133.07 Vulkan Backend

Blender Version
Broken: version: 4.5.0 Alpha, branch: main, commit date: 2025-04-09 00:26, hash: e94068e8d2bf

6

@Xury46 would you mind reporting a bug, it is not obvious what exactly causes this.

7

Dumb question: I’ve been using Vulkan in Blender 4.4. Viewport performance is great, especially on an old GPU with limited VRAM. If I understand correctly, for the time being, in order to optimize performance in Cycles GPU rendering, is it necessary to switch back to OpenGL before rendering out a scene? Thanks

8

There is no dump question. Final image rendering should not be effected. If there is a slow down it would be related to Cycles viewport rendering and very limited to image editor updates. Just test and provide feedback.

5 Likes
9

Done :slight_smile:

1 Like
10

I get a crash with one of my projects


# backtrace
Exception Record:

ExceptionCode         : EXCEPTION_ACCESS_VIOLATION
Exception Address     : 0x00007FF6E9979435
Exception Module      : blender.exe
Exception Flags       : 0x00000000
Exception Parameters  : 0x2
	Parameters[0] : 0x0000000000000000
	Parameters[1] : 0x0000000000000020


Stack trace:
blender.exe         :0x00007FF6E99793A0  blender::gpu::render_graph::VKCommandBuilder::add_buffer_barriers
blender.exe         :0x00007FF6E997AAB0  blender::gpu::render_graph::VKCommandBuilder::groups_extract_barriers
blender.exe         :0x00007FF6E997A330  blender::gpu::render_graph::VKCommandBuilder::build_nodes
blender.exe         :0x00007FF6E9956160  blender::gpu::VKDevice::submission_runner
blender.exe         :0x00007FF6E96AC320  TaskPool::background_task_run
blender.exe         :0x00007FF6E9A30980  _ptw32_threadStart
ucrtbase.dll        :0x00007FFA089C3660  wcsrchr
KERNEL32.DLL        :0x00007FFA0A4BE8C0  BaseThreadInitThunk
ntdll.dll           :0x00007FFA0B59BF00  RtlUserThreadStart


Threads:
Thread : 00055814
ntdll.dll           :0x00007FFA0B643410  NtWaitForAlertByThreadId
ntdll.dll           :0x00007FFA0B51F060  AlpcGetMessageFromCompletionList
ntdll.dll           :0x00007FFA0B554EA0  RtlAcquireSRWLockExclusive
MSVCP140.dll        :0x00007FF9CCC12F70  Thrd_yield
blender.exe         :0x00007FF6E9952F90  blender::gpu::render_graph::VKResourceStateTracker::remove_buffer
blender.exe         :0x00007FF6E9954AC0  blender::gpu::VKDiscardPool::destroy_discarded_resources
blender.exe         :0x00007FF6E9A12CC0  wm_draw_update
blender.exe         :0x00007FF6E99D3D20  WM_main
blender.exe         :0x00007FF6E9059890  main
blender.exe         :0x00007FF6EC047A54  __scrt_common_main_seh
KERNEL32.DLL        :0x00007FFA0A4BE8C0  BaseThreadInitThunk
ntdll.dll           :0x00007FFA0B59BF00  RtlUserThreadStart


Thread : 0005597c
ntdll.dll           :0x00007FFA0B63F840  ZwWaitForSingleObject
KERNELBASE.dll      :0x00007FFA08F9CD70  WaitForSingleObjectEx
IlmThread.dll       :0x00007FF9F31549C0  IlmThread_3_3::Semaphore::wait
IlmThread.dll       :0x00007FF9F31537A0  IlmThread_3_3::ThreadPool::setThreadProvider
IlmThread.dll       :0x00007FF9F3151290  IlmThread_3_3::supportsThreads
ucrtbase.dll        :0x00007FFA089C3660  wcsrchr
KERNEL32.DLL        :0x00007FFA0A4BE8C0  BaseThreadInitThunk
ntdll.dll           :0x00007FFA0B59BF00  RtlUserThreadStart


Thread : 00055950
ntdll.dll           :0x00007FFA0B63F840  ZwWaitForSingleObject
KERNELBASE.dll      :0x00007FFA08F9CD70  WaitForSingleObjectEx
IlmThread.dll       :0x00007FF9F31549C0  IlmThread_3_3::Semaphore::wait
IlmThread.dll       :0x00007FF9F31537A0  IlmThread_3_3::ThreadPool::setThreadProvider
IlmThread.dll       :0x00007FF9F3151290  IlmThread_3_3::supportsThreads
ucrtbase.dll        :0x00007FFA089C3660  wcsrchr
KERNEL32.DLL        :0x00007FFA0A4BE8C0  BaseThreadInitThunk
ntdll.dll           :0x00007FFA0B59BF00  RtlUserThreadStart


Thread : 00054d3c
ntdll.dll           :0x00007FFA0B63F840  ZwWaitForSingleObject
KERNELBASE.dll      :0x00007FFA08F9CD70  WaitForSingleObjectEx
IlmThread.dll       :0x00007FF9F31549C0  IlmThread_3_3::Semaphore::wait
IlmThread.dll       :0x00007FF9F31537A0  IlmThread_3_3::ThreadPool::setThreadProvider
IlmThread.dll       :0x00007FF9F3151290  IlmThread_3_3::supportsThreads
ucrtbase.dll        :0x00007FFA089C3660  wcsrchr
KERNEL32.DLL        :0x00007FFA0A4BE8C0  BaseThreadInitThunk
ntdll.dll           :0x00007FFA0B59BF00  RtlUserThreadStart
1 Like
11

Please report. I need to be able to reproduce this issue in order to know what’s going on

12

Just an update as time doesn’t seem to be standing still.

  • OpenXR/Vulkan support has been completed.
  • Wayland crash has been partially solved. Previous fix (done by @ideasman42 did) works. Due to technical reasons and me not seeing a git error, resulted in an incorrect review. MESA 25 + AMD seems to crash later on.
19 Likes
13

I see there’s work being done on MoltenVK.

What is the plan for MoltenVK? Is it a tool primarily for developers on Mac that need to investigate Vulkan issues? Or are there plans to make this an officially supported platform?

14

There no plans to make MoltenVK official supported. MoltenVK has many internal issues and development is at a low pace. I primary do this on my own time in case MoltenVK gets more advanced. LunarG extended goal for this year also includes MoltenVK. Hopefully they will have time to add some time for it.

Current state is that if you disable Retina (change display resolution so 1 screen pixel is 1 display pixel) you are able to start Blender, but the viewport isn’t depth aware and actions will fail in a shader compilation issue.

3 Likes
15

This is definitely not ready for the prime time (13th gen intel Xe gpu running wayland). It crashes/freezes/strobes/etc when I turned on shadows for Eevee. I filed a bug report already #137509 - Vulkan backend freezes when I turn on shadows in eevee - blender - Blender Projects

16

Thanks! Reporting is the only way to improve the support. More people should do that!

We still have 3 months before Blender 4.5 is released and a lot of improvements will happen along the way. I don’t have access to all the platforms out there, hence we ask for community to report bugs. This allows me to focus on platforms that are not working as expected.

Wayland is still troublesome, other software packages have issues as well. I haven’t tested Intel in some time; will install one in my system today.

15 Likes
17

I did not find any noteworthy issues in tonight’s build, assuming the commandline switch for enabling the vulkan backend was itself not broken. The build was stable, the rendered image looked correct with no obvious corruption or artifacting, and steady state performance felt more or less at parity with the OpenGL backend. I did not check memory usage.

I opened up a variety of files I had on hand, and everything was solid for what I think represents fairly basic use of eevee and grease pencil.

I suspect that if you did a blind taste test I would not have been able to tell you which backend was coke and which one was pepsi.

Excellent work.

8 Likes
18

Based on personal experience, I think the most important part is somehow detecting that a crash occurred due to that.
Since a broken overlay will crash Blender just by being installed on the system without its application even being on, there is no communication or even anything hinting that this is what’s causing the crash, especially since Blender is the only Vulkan app I know that crashes in this situation. I could only fix this after installing the Vulkan SDK out of desperation, which threw at me several warnings of corrupted overlays, and everything worked fine after uninstalling those. During that I almost thought the Vulkan backend was gonna “just not work” on my PC.

19

The challenge is that Blender doesn’t load any layers, the configuration of your system forces vulkan to load them. Blender isn’t aware if an layer is faulty or has a way to detect which one are loaded, making it hard to communication to the user about it. I am aware of other applications to also have this issue. Blender might be more sensitive due to our wide user group and platform support.

Using blender_debug_gpu.cmd would log all enabled layers and which part of your configuration is forcing them to be loaded and in which order. I would recommend to send in a bug report with the log so we are aware of them and can take appropriate actions.

An application can only disable loading of specific layers by setting up environment variables, before Vulkan is initiated. eg:

SetEnvironmentVariable("DISABLE_VK_LAYER_VALVE_steam_overlay_1", "1");
20

Was working gizmos with geometry nodes, then my GPU slowed to a crawl then green screen of death. Reverting to OpenGL.

Windows 11
Nvidia RTX4090

20250416_185424
20250416_1854241920Ă—1081 141 KB

1 Like