griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
4e629a6cb1b02cd2c568d1c8bccbc6f00df5dfd2
test2/source/blender/gpu/vulkan/vk_context.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

565 lines
19 KiB
C++
Raw Normal View History

License Headers: Set copyright to "Blender Authors", add AUTHORS Listing the "Blender Foundation" as copyright holder implied the Blender Foundation holds copyright to files which may include work from many developers. While keeping copyright on headers makes sense for isolated libraries, Blender's own code may be refactored or moved between files in a way that makes the per file copyright holders less meaningful. Copyright references to the "Blender Foundation" have been replaced with "Blender Authors", with the exception of `./extern/` since these this contains libraries which are more isolated, any changed to license headers there can be handled on a case-by-case basis. Some directories in `./intern/` have also been excluded: - `./intern/cycles/` it's own `AUTHORS` file is planned. - `./intern/opensubdiv/`. An "AUTHORS" file has been added, using the chromium projects authors file as a template. Design task: #110784 Ref !110783.
2023-08-16 00:20:26 +10:00
/* SPDX-FileCopyrightText: 2022 Blender Authors
Cleanup: Add a copyright notice to files and use SPDX format A lot of files were missing copyright field in the header and the Blender Foundation contributed to them in a sense of bug fixing and general maintenance. This change makes it explicit that those files are at least partially copyrighted by the Blender Foundation. Note that this does not make it so the Blender Foundation is the only holder of the copyright in those files, and developers who do not have a signed contract with the foundation still hold the copyright as well. Another aspect of this change is using SPDX format for the header. We already used it for the license specification, and now we state it for the copyright as well, following the FAQ: https://reuse.software/faq/
2023-05-31 16:19:06 +02:00
*
* SPDX-License-Identifier: GPL-2.0-or-later */
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
/** \file
* \ingroup gpu
*/
Vulkan: Add debug group for swapchain Improves debugging swapchains when using renderdoc. Pull Request: https://projects.blender.org/blender/blender/pulls/133190
2025-01-17 11:40:11 +01:00
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
#include "DNA_userdef_types.h"
Vulkan: Add debug group for swapchain Improves debugging swapchains when using renderdoc. Pull Request: https://projects.blender.org/blender/blender/pulls/133190
2025-01-17 11:40:11 +01:00
#include "GPU_debug.hh"
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
#include "gpu_capabilities_private.hh"
GPU: Compile vulkan shaders to Spir-V binaries. Compile each static shader using shaderc to Spir-V binaries. The main goal is to make sure that the GLSL created using ShaderCreateInfo and able to compile to Spir-V. For the second stage a correct pipeline needs to be created and some shader would need more adjustments (push constants size). With this patch future changes to GLSL sources can already be checked against vulkan, without the backend finished. Mechanism has been tested using MacOS and MoltenVK. For other OS, we should finetune CMake files to find the right location to shaderc. ``` ************************************************************ *** Build Mon 12 Dec 2022 11:08:07 CET ************************************************************ Shader Test compilation result: 463 / 463 passed (skipped 118 for compatibility reasons) OpenGL backend shader compilation succeeded. Shader Test compilation result: 529 / 529 passed (skipped 52 for compatibility reasons) Vulkan backend shader compilation succeeded. ``` Reviewed By: fclem Maniphest Tasks: T102760 Differential Revision: https://developer.blender.org/D16610
2022-12-12 12:22:38 +01:00
#include "vk_backend.hh"
Vulkan: Add debug group for swapchain Improves debugging swapchains when using renderdoc. Pull Request: https://projects.blender.org/blender/blender/pulls/133190
2025-01-17 11:40:11 +01:00
#include "vk_context.hh"
#include "vk_debug.hh"
Vulkan: Add Initial VKFrameBuffer. This was backported from tmp-vulkan. When disabling the fence check in ghost it is able to start blender. It will show a black screen so not usable for users.
2023-02-28 06:13:57 +01:00
#include "vk_framebuffer.hh"
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
#include "vk_immediate.hh"
#include "vk_shader.hh"
Vulkan: Use Point Shaders When Drawing Points In Vulkan (and Metal) it is not possible to use a global as point size. It needs to be set for each vertex when drawing points. Blender has specialized shaders for that, but not all code respect those shaders. This PR will add an assert inside the vulkan backend when incorrect usage of shaders are detected. Pull Request: https://projects.blender.org/blender/blender/pulls/112906
2023-09-26 16:04:08 +02:00
#include "vk_shader_interface.hh"
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
#include "vk_state_manager.hh"
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
#include "vk_texture.hh"
GPU: Compile vulkan shaders to Spir-V binaries. Compile each static shader using shaderc to Spir-V binaries. The main goal is to make sure that the GLSL created using ShaderCreateInfo and able to compile to Spir-V. For the second stage a correct pipeline needs to be created and some shader would need more adjustments (push constants size). With this patch future changes to GLSL sources can already be checked against vulkan, without the backend finished. Mechanism has been tested using MacOS and MoltenVK. For other OS, we should finetune CMake files to find the right location to shaderc. ``` ************************************************************ *** Build Mon 12 Dec 2022 11:08:07 CET ************************************************************ Shader Test compilation result: 463 / 463 passed (skipped 118 for compatibility reasons) OpenGL backend shader compilation succeeded. Shader Test compilation result: 529 / 529 passed (skipped 52 for compatibility reasons) Vulkan backend shader compilation succeeded. ``` Reviewed By: fclem Maniphest Tasks: T102760 Differential Revision: https://developer.blender.org/D16610
2022-12-12 12:22:38 +01:00
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
#include "GHOST_C-api.h"
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
namespace blender::gpu {
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
VKContext::VKContext(void *ghost_window, void *ghost_context)
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
{
ghost_window_ = ghost_window;
Vulkan: Initial Compute Shaders support This patch adds initial support for compute shaders to the vulkan backend. As the development is oriented to the test- cases we have the implementation is limited to what is used there. It has been validated that with this patch that the following test cases are running as expected - `GPUVulkanTest.gpu_shader_compute_vbo` - `GPUVulkanTest.gpu_shader_compute_ibo` - `GPUVulkanTest.gpu_shader_compute_ssbo` - `GPUVulkanTest.gpu_storage_buffer_create_update_read` - `GPUVulkanTest.gpu_shader_compute_2d` This patch includes: - Allocating VkBuffer on device. - Uploading data from CPU to VkBuffer. - Binding VkBuffer as SSBO to a compute shader. - Execute compute shader and altering VkBuffer. - Download the VkBuffer to CPU ram. - Validate that it worked. - Use device only vertex buffer as SSBO - Use device only index buffer as SSBO - Use device only image buffers GHOST API has been changed as the original design was created before we even had support for compute shaders in blender. The function `GHOST_getVulkanBackbuffer` has been separated to retrieve the command buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order to do correct command buffer processing we needed access to the queue owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles` function. Open topics (not considered part of this patch) - Memory barriers & command buffer encoding - Indirect compute dispatching - Rest of the test cases - Data conversions when requested data format is different than on device. - GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices. NVIDIA doesn't seem to support 1d textures. Pull-request: #104518
2023-02-21 15:03:12 +01:00
ghost_context_ = ghost_context;
state_manager = new VKStateManager();
Fix #142305: Vulkan: Memory leak immediate mode Resetting and recycling of immediate drawing buffers was never done and would leak memory as the buffers were only destroyed when Blender exited. This is solved by not recycling or resetting the buffers and rely on the discard pools. Additional cleanup of removing unused code-paths is also part of this change so it can be backported to 4.5. Pull Request: https://projects.blender.org/blender/blender/pulls/143995
2025-08-05 14:40:54 +02:00
imm = new VKImmediate();
GPU: Compile vulkan shaders to Spir-V binaries. Compile each static shader using shaderc to Spir-V binaries. The main goal is to make sure that the GLSL created using ShaderCreateInfo and able to compile to Spir-V. For the second stage a correct pipeline needs to be created and some shader would need more adjustments (push constants size). With this patch future changes to GLSL sources can already be checked against vulkan, without the backend finished. Mechanism has been tested using MacOS and MoltenVK. For other OS, we should finetune CMake files to find the right location to shaderc. ``` ************************************************************ *** Build Mon 12 Dec 2022 11:08:07 CET ************************************************************ Shader Test compilation result: 463 / 463 passed (skipped 118 for compatibility reasons) OpenGL backend shader compilation succeeded. Shader Test compilation result: 529 / 529 passed (skipped 52 for compatibility reasons) Vulkan backend shader compilation succeeded. ``` Reviewed By: fclem Maniphest Tasks: T102760 Differential Revision: https://developer.blender.org/D16610
2022-12-12 12:22:38 +01:00
Vulkan: Blendfile thumbnail generation Vulkan would crash when generating a thumbnail in case there is no 3D viewport in the active workspace. When this happens the front buffer is downscaled as thumbnail. We didn't create a front buffer as swap chains are handled differently. We work around this issue in the same way as Metal does. Create a dummy front framebuffer and share the surface texture. When the thumbnail generator reads from the front buffer it will read the data that was created by the back buffer. Pull Request: https://projects.blender.org/blender/blender/pulls/127393
2024-09-10 11:02:43 +02:00
back_left = new VKFrameBuffer("back_left");
front_left = new VKFrameBuffer("front_left");
active_fb = back_left;
Vulkan: Add VK memory allocator 3.0.1 to extern. Vulkan doesn't have a memory allocator builtin. The application should provide the memory allocator at runtime. Vulkan Memory Allocator is a widely used implementation. Vulkan Memory Allocator is a header only implementation, but the using application should compile a part in a CPP compile unit. The file `vk_mem_alloc_impl.cc` and `extern_vulkan_memory_allocator` library is therefore introduced. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16572
2022-11-23 14:42:11 +01:00
}
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
VKContext::~VKContext()
{
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
if (surface_texture_) {
Vulkan: Blendfile thumbnail generation Vulkan would crash when generating a thumbnail in case there is no 3D viewport in the active workspace. When this happens the front buffer is downscaled as thumbnail. We didn't create a front buffer as swap chains are handled differently. We work around this issue in the same way as Metal does. Create a dummy front framebuffer and share the surface texture. When the thumbnail generator reads from the front buffer it will read the data that was created by the back buffer. Pull Request: https://projects.blender.org/blender/blender/pulls/127393
2024-09-10 11:02:43 +02:00
back_left->attachment_remove(GPU_FB_COLOR_ATTACHMENT0);
front_left->attachment_remove(GPU_FB_COLOR_ATTACHMENT0);
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
GPU_texture_free(surface_texture_);
surface_texture_ = nullptr;
}
Fix: ASAN errors after addition of texture pool Same fix as #132504. Free the texture pool before the derived GPU context class, as that one is used as part of freeing the texture pool. Pull Request: https://projects.blender.org/blender/blender/pulls/135444
2025-03-04 16:54:05 +01:00
free_resources();
Fix #142305: Vulkan: Memory leak immediate mode Resetting and recycling of immediate drawing buffers was never done and would leak memory as the buffers were only destroyed when Blender exited. This is solved by not recycling or resetting the buffers and rely on the discard pools. Additional cleanup of removing unused code-paths is also part of this change so it can be backported to 4.5. Pull Request: https://projects.blender.org/blender/blender/pulls/143995
2025-08-05 14:40:54 +02:00
delete imm;
imm = nullptr;
Fix: Vulkan: Use after free when switching scenes Unreported issue introduced from recent changes. (memory leak in immediate mode) Pull Request: https://projects.blender.org/blender/blender/pulls/144116
2025-08-07 08:56:59 +02:00
VKDevice &device = VKBackend::get().device;
Fix #142305: Vulkan: Memory leak immediate mode Resetting and recycling of immediate drawing buffers was never done and would leak memory as the buffers were only destroyed when Blender exited. This is solved by not recycling or resetting the buffers and rely on the discard pools. Additional cleanup of removing unused code-paths is also part of this change so it can be backported to 4.5. Pull Request: https://projects.blender.org/blender/blender/pulls/143995
2025-08-05 14:40:54 +02:00
device.context_unregister(*this);
Vulkan: Device Context Resource Management The current Vulkan resource management has some issues as context that are not active can still use resources that are freed via another context. When this happens incorrect data can be read on the GPU and even crash Blender. When trying to bind something that now contains other memory pointers. This change introduces that contexts are tracked via the device. Context will be registered/unregistered with the device instance. Unbinding of resources must pass the device and the device will check all registered contexts. Binding of resources will happen via the active context only. On user perspective this now allowes: - Opening/switching files - Switching workspaces - Switching render engines Pull Request: https://projects.blender.org/blender/blender/pulls/108968
2023-06-15 08:14:37 +02:00
Vulkan: Add CPU profiling This has limited use cases since it doesn't profile the heavy part of the vulkan backend. Almost 1:1 port of the metal implementation from #139551. Doesn't cover rendergraph submission nor GPU timings. Pull Request: https://projects.blender.org/blender/blender/pulls/139899
2025-06-06 14:39:51 +02:00
this->process_frame_timings();
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
}
Vulkan: Get access to physical device limits. This patch will give access to the physical device limits of the device associated with the context. In vulkan each device has different limits and the application is responsible to match these limits as the vulkan driver just ignores calls that don't match these limits. Those limits are GPUBackend specific and therefore are not added to GPU_capabilities. Pull Request #105125
2023-02-23 13:47:29 +01:00
Vulkan: Remove resource pools Multiple previous changes made resource pools obsolete. Resource pools were used to keep track of resources when the frame is rendered. Multiple frames can be rendered at the same time and resources could overlap. This has been replaced (not this commit) to be part of the render graph and when an submission has completed the resources are recycled. Continuation of: https://projects.blender.org/blender/blender/pulls/145408 Pull Request: https://projects.blender.org/blender/blender/pulls/145511
2025-09-01 15:34:14 +02:00
void VKContext::sync_backbuffer()
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
{
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
if (ghost_window_) {
GHOST_VulkanSwapChainData swap_chain_data = {};
GHOST_GetVulkanSwapChainFormat((GHOST_WindowHandle)ghost_window_, &swap_chain_data);
Cleanup: Vulkan: Use full surface format GHOST_ContextVK used to pass only the surface texture format to the GPU backend, it didn't pass the color space. This PR also includes the color space. Pull Request: https://projects.blender.org/blender/blender/pulls/133185
2025-01-17 10:28:22 +01:00
const bool reset_framebuffer = swap_chain_format_.format !=
swap_chain_data.surface_format.format ||
swap_chain_format_.colorSpace !=
swap_chain_data.surface_format.colorSpace ||
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
vk_extent_.width != swap_chain_data.extent.width ||
vk_extent_.height != swap_chain_data.extent.height;
if (reset_framebuffer) {
if (has_active_framebuffer()) {
deactivate_framebuffer();
}
if (surface_texture_) {
GPU_texture_free(surface_texture_);
surface_texture_ = nullptr;
}
Fix #144048: Vulkan: Crash minimized windows Swapchain handling of minimized windows wasn't correct. On some platforms it still tried to create images with no surface. This PR will discard swapchains of minimized windows, but still being able to flush the render graph and free resources. Pull Request: https://projects.blender.org/blender/blender/pulls/144189
2025-08-08 11:03:02 +02:00
vk_extent_ = swap_chain_data.extent;
vk_extent_.width = max_uu(vk_extent_.width, 1u);
vk_extent_.height = max_uu(vk_extent_.height, 1u);
Cleanup: Vulkan: Use full surface format GHOST_ContextVK used to pass only the surface texture format to the GPU backend, it didn't pass the color space. This PR also includes the color space. Pull Request: https://projects.blender.org/blender/blender/pulls/133185
2025-01-17 10:28:22 +01:00
surface_texture_ = GPU_texture_create_2d(
"back-left",
Fix: Vulkan: Incorrect framebuffer size When a file is loaded with a minimized window the VKFramebuffer can contain incorrect texture/data that result in a crash when maximizing the window. Pull Request: https://projects.blender.org/blender/blender/pulls/145171
2025-08-28 09:38:39 +02:00
vk_extent_.width,
vk_extent_.height,
Cleanup: Vulkan: Use full surface format GHOST_ContextVK used to pass only the surface texture format to the GPU backend, it didn't pass the color space. This PR also includes the color space. Pull Request: https://projects.blender.org/blender/blender/pulls/133185
2025-01-17 10:28:22 +01:00
1,
to_gpu_format(swap_chain_data.surface_format.format),
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
GPU_TEXTURE_USAGE_ATTACHMENT | GPU_TEXTURE_USAGE_SHADER_READ,
Cleanup: Vulkan: Use full surface format GHOST_ContextVK used to pass only the surface texture format to the GPU backend, it didn't pass the color space. This PR also includes the color space. Pull Request: https://projects.blender.org/blender/blender/pulls/133185
2025-01-17 10:28:22 +01:00
nullptr);
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
back_left->attachment_set(GPU_FB_COLOR_ATTACHMENT0,
GPU_ATTACHMENT_TEXTURE(surface_texture_));
Vulkan: Blendfile thumbnail generation Vulkan would crash when generating a thumbnail in case there is no 3D viewport in the active workspace. When this happens the front buffer is downscaled as thumbnail. We didn't create a front buffer as swap chains are handled differently. We work around this issue in the same way as Metal does. Create a dummy front framebuffer and share the surface texture. When the thumbnail generator reads from the front buffer it will read the data that was created by the back buffer. Pull Request: https://projects.blender.org/blender/blender/pulls/127393
2024-09-10 11:02:43 +02:00
front_left->attachment_set(GPU_FB_COLOR_ATTACHMENT0,
GPU_ATTACHMENT_TEXTURE(surface_texture_));
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
back_left->bind(false);
Cleanup: Vulkan: Use full surface format GHOST_ContextVK used to pass only the surface texture format to the GPU backend, it didn't pass the color space. This PR also includes the color space. Pull Request: https://projects.blender.org/blender/blender/pulls/133185
2025-01-17 10:28:22 +01:00
swap_chain_format_ = swap_chain_data.surface_format;
Vulkan: Move Wayland/HDR support out of experimental This PR moves Wayland/HDR support out of experimental. This allows more people to test and provide feedback. We can always decide later to disable it for the release, but so far we only got positive feedback. Pull Request: https://projects.blender.org/blender/blender/pulls/141666
2025-07-09 13:24:31 +02:00
GCaps.hdr_viewport_support = (swap_chain_format_.format == VK_FORMAT_R16G16B16A16_SFLOAT) &&
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
ELEM(swap_chain_format_.colorSpace,
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT,
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
VK_COLOR_SPACE_SRGB_NONLINEAR_KHR);
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
}
Vulkan: Add Initial VKFrameBuffer. This was backported from tmp-vulkan. When disabling the fence check in ghost it is able to start blender. It will show a black screen so not usable for users.
2023-02-28 06:13:57 +01:00
}
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
}
Vulkan: Frame Buffer Flipping Vulkan coordinate system is flipped compared to OpenGL. This PR flips the drawing when drawn to the on-screen frame buffer. Offscreen frame buffers are still drawn upside down. The flipping is done by making the viewport of the framebuffer negative. Pull Request: https://projects.blender.org/blender/blender/pulls/107743
2023-05-09 09:22:26 +02:00
void VKContext::activate()
{
/* Make sure no other context is already bound to this thread. */
BLI_assert(is_active_ == false);
Fix #128608: Vulkan: Sync issues when sharing context between threads Resources are shared, when running multiple contexts on the same thread. Cycles uses the same context on multiple threads and expected same resources. This change will introduce a single render graph per context and an updated resource management. Render graphs are not shared anymore; Resource pools are still shared, but garbage collection depends on the thread and if background rendering is used. Pull Request: https://projects.blender.org/blender/blender/pulls/128983
2024-10-14 15:42:46 +02:00
VKDevice &device = VKBackend::get().device;
VKThreadData &thread_data = device.current_thread_data();
thread_data_ = std::reference_wrapper<VKThreadData>(thread_data);
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
if (!render_graph_.has_value()) {
render_graph_ = std::reference_wrapper<render_graph::VKRenderGraph>(
*device.render_graph_new());
Vulkan: Add CPU profiling This has limited use cases since it doesn't profile the heavy part of the vulkan backend. Almost 1:1 port of the metal implementation from #139551. Doesn't cover rendergraph submission nor GPU timings. Pull Request: https://projects.blender.org/blender/blender/pulls/139899
2025-06-06 14:39:51 +02:00
/* Recreate the debug group stack for the new graph.
* Note: there is no associated `debug_group_end` as the graph groups
* are implicitly closed on submission. */
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
for (const StringRef &group : debug_stack) {
Vulkan: Add CPU profiling This has limited use cases since it doesn't profile the heavy part of the vulkan backend. Almost 1:1 port of the metal implementation from #139551. Doesn't cover rendergraph submission nor GPU timings. Pull Request: https://projects.blender.org/blender/blender/pulls/139899
2025-06-06 14:39:51 +02:00
std::string str_group = group;
render_graph_.value().get().debug_group_begin(str_group.c_str(),
debug::get_debug_group_color(str_group));
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
}
}
Vulkan: Frame Buffer Flipping Vulkan coordinate system is flipped compared to OpenGL. This PR flips the drawing when drawn to the on-screen frame buffer. Offscreen frame buffers are still drawn upside down. The flipping is done by making the viewport of the framebuffer negative. Pull Request: https://projects.blender.org/blender/blender/pulls/107743
2023-05-09 09:22:26 +02:00
is_active_ = true;
Vulkan: Remove resource pools Multiple previous changes made resource pools obsolete. Resource pools were used to keep track of resources when the frame is rendered. Multiple frames can be rendered at the same time and resources could overlap. This has been replaced (not this commit) to be part of the render graph and when an submission has completed the resources are recycled. Continuation of: https://projects.blender.org/blender/blender/pulls/145408 Pull Request: https://projects.blender.org/blender/blender/pulls/145511
2025-09-01 15:34:14 +02:00
sync_backbuffer();
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
immActivate();
Vulkan: Frame Buffer Flipping Vulkan coordinate system is flipped compared to OpenGL. This PR flips the drawing when drawn to the on-screen frame buffer. Offscreen frame buffers are still drawn upside down. The flipping is done by making the viewport of the framebuffer negative. Pull Request: https://projects.blender.org/blender/blender/pulls/107743
2023-05-09 09:22:26 +02:00
}
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
void VKContext::deactivate()
{
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
flush_render_graph(RenderGraphFlushFlags(0));
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
immDeactivate();
Fix #128608: Vulkan: Sync issues when sharing context between threads Resources are shared, when running multiple contexts on the same thread. Cycles uses the same context on multiple threads and expected same resources. This change will introduce a single render graph per context and an updated resource management. Render graphs are not shared anymore; Resource pools are still shared, but garbage collection depends on the thread and if background rendering is used. Pull Request: https://projects.blender.org/blender/blender/pulls/128983
2024-10-14 15:42:46 +02:00
thread_data_.reset();
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
is_active_ = false;
}
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
void VKContext::begin_frame() {}
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
void VKContext::end_frame()
{
Vulkan: Add CPU profiling This has limited use cases since it doesn't profile the heavy part of the vulkan backend. Almost 1:1 port of the metal implementation from #139551. Doesn't cover rendergraph submission nor GPU timings. Pull Request: https://projects.blender.org/blender/blender/pulls/139899
2025-06-06 14:39:51 +02:00
this->process_frame_timings();
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
}
Vulkan: Remove render graph switch As render graph is now the default, we can remove the render graph switch. This allows us to cleanup unused functions and classes. Pull Request: https://projects.blender.org/blender/blender/pulls/123219
2024-06-14 09:44:59 +02:00
Vulkan: Reduce lag on certain platforms. After reviewing the locations where `GPU_flush()` are used it doesn't seem to be harmfull to include these for the Vulkan backend as well. Hopefully will save some lag that can happen when submitting one huge render graph. Improved playback of rain_restaurant.blend where frames could be dropped resulting into UI lag. Pull Request: https://projects.blender.org/blender/blender/pulls/136654
2025-03-31 12:16:48 +02:00
void VKContext::flush()
{
flush_render_graph(RenderGraphFlushFlags::RENEW_RENDER_GRAPH);
}
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
Vulkan: Swapchain synchronization This PR adds swapchain synchronization. When the swapchain swaps the buffers it can add a wait semaphore/signal semaphore to support GPU based synchronization 10 times playback of `rain_restaurant.blend` on AMD RX 7700 Before: 10 × Animation playback: 72347.5540 ms, average: 7234.75539684 ms After: 10 × Animation playback: 41523.2441 ms, average: 4152.32441425 ms Getting around the OpenGL performance target. Pull Request: https://projects.blender.org/blender/blender/pulls/136259
2025-03-24 10:28:52 +01:00
TimelineValue VKContext::flush_render_graph(RenderGraphFlushFlags flags,
VkPipelineStageFlags wait_dst_stage_mask,
VkSemaphore wait_semaphore,
Refactor: Vulkan: swapchain This PR refactors the way how swapchains are used. Allow scaling of the swapchain content to the actual resolution of the swapchain. can reduce artefacts when resizing windows when supported. When frame rate is to fast the previous implementation could use a semaphore that were still in use, leading to unwanted stuttering on certain platforms. Waiting when the rendering has finished (GHOST_Frame.submission_fence), before the next image is acquired from the swap chain. Mailbox has been disabled as it can calculate more frames then actually been presented, leading to a lag and increased power usage on others. Pull Request: https://projects.blender.org/blender/blender/pulls/136603
2025-04-01 16:01:22 +02:00
VkSemaphore signal_semaphore,
VkFence signal_fence)
Vulkan: Enable render graph This PR hooks up the vulkan backend with the render graph for drawing. It can run Blender better than the previous implementation so we also flipped it to be the default implementation. **Some highlights** - Adds support for framebuffer load/store operations - Adds support for framebuffer subpass transitions - Fixes workbench shadows - Performance is just below OpenGL performance when comparing fps. But the screen feels more fluent when using complex scenes. - Current performance is without doing any optimizations so will improve in the future. - EEVEE will not crash but has artifacts and many parts that require more work. **Related to** - #121648 - #118330 **Known Limitation** - Similar to previous implementation resources can be freed when still in use crashing Blender. This is typically the case when playing back an animation or updating a material icon. **Next steps** - Remove old implementation - Get EEVEE to work - Fix double resource freeing - Improve performance by identifying hotspots and change them Pull Request: https://projects.blender.org/blender/blender/pulls/121787
2024-06-14 08:46:33 +02:00
{
if (has_active_framebuffer()) {
VKFrameBuffer &framebuffer = *active_framebuffer_get();
if (framebuffer.is_rendering()) {
framebuffer.rendering_end(*this);
}
}
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
VKDevice &device = VKBackend::get().device;
Vulkan: Add support for descriptor buffers Descriptor sets/pools are known to be troublesome as it doesn't match how GPUs work, or how application want to work, adding more complexity than needed. This results is quite an overhead allocating and deallocating descriptor sets. This PR will use descriptor buffers when they are available. Most platforms support descriptor buffers. When not available descriptor pools/sets will be used. Although this is a feature I would like to land it in 4.5 due to the API changes. This makes it easier to fix issues when 4.5 is released. The feature can easily be disabled by setting the feature to false if it has to many problems. Pull Request: https://projects.blender.org/blender/blender/pulls/138266
2025-06-06 10:20:36 +02:00
descriptor_set_get().upload_descriptor_sets();
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
TimelineValue timeline = device.render_graph_submit(
&render_graph_.value().get(),
discard_pool,
bool(flags & RenderGraphFlushFlags::SUBMIT),
Vulkan: Swapchain synchronization This PR adds swapchain synchronization. When the swapchain swaps the buffers it can add a wait semaphore/signal semaphore to support GPU based synchronization 10 times playback of `rain_restaurant.blend` on AMD RX 7700 Before: 10 × Animation playback: 72347.5540 ms, average: 7234.75539684 ms After: 10 × Animation playback: 41523.2441 ms, average: 4152.32441425 ms Getting around the OpenGL performance target. Pull Request: https://projects.blender.org/blender/blender/pulls/136259
2025-03-24 10:28:52 +01:00
bool(flags & RenderGraphFlushFlags::WAIT_FOR_COMPLETION),
wait_dst_stage_mask,
wait_semaphore,
Refactor: Vulkan: swapchain This PR refactors the way how swapchains are used. Allow scaling of the swapchain content to the actual resolution of the swapchain. can reduce artefacts when resizing windows when supported. When frame rate is to fast the previous implementation could use a semaphore that were still in use, leading to unwanted stuttering on certain platforms. Waiting when the rendering has finished (GHOST_Frame.submission_fence), before the next image is acquired from the swap chain. Mailbox has been disabled as it can calculate more frames then actually been presented, leading to a lag and increased power usage on others. Pull Request: https://projects.blender.org/blender/blender/pulls/136603
2025-04-01 16:01:22 +02:00
signal_semaphore,
signal_fence);
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
render_graph_.reset();
if (bool(flags & RenderGraphFlushFlags::RENEW_RENDER_GRAPH)) {
render_graph_ = std::reference_wrapper<render_graph::VKRenderGraph>(
*device.render_graph_new());
Vulkan: Add CPU profiling This has limited use cases since it doesn't profile the heavy part of the vulkan backend. Almost 1:1 port of the metal implementation from #139551. Doesn't cover rendergraph submission nor GPU timings. Pull Request: https://projects.blender.org/blender/blender/pulls/139899
2025-06-06 14:39:51 +02:00
/* Recreate the debug group stack for the new graph.
* Note: there is no associated `debug_group_end` as the graph groups
* are implicitly closed on submission. */
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
for (const StringRef &group : debug_stack) {
Vulkan: Add CPU profiling This has limited use cases since it doesn't profile the heavy part of the vulkan backend. Almost 1:1 port of the metal implementation from #139551. Doesn't cover rendergraph submission nor GPU timings. Pull Request: https://projects.blender.org/blender/blender/pulls/139899
2025-06-06 14:39:51 +02:00
std::string str_group = group;
render_graph_.value().get().debug_group_begin(str_group.c_str(),
debug::get_debug_group_color(str_group));
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
}
}
return timeline;
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
}
Vulkan: Remove render graph switch As render graph is now the default, we can remove the render graph switch. This allows us to cleanup unused functions and classes. Pull Request: https://projects.blender.org/blender/blender/pulls/123219
2024-06-14 09:44:59 +02:00
void VKContext::finish() {}
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
Vulkan: Memory Statistics This PR shows the memory footprint in the statusbar when activated. Only memory allocated on the VRAM is counted. Memory allocated on host memory is not counted. ![image](/attachments/33cedc89-9ada-4c0a-9a94-6c1b3e22b64b) Pull Request: https://projects.blender.org/blender/blender/pulls/115184
2023-11-20 14:08:19 +01:00
void VKContext::memory_statistics_get(int *r_total_mem_kb, int *r_free_mem_kb)
{
Vulkan: Remove unused code Vulkan backend has recently switched to a render graph approach. Many code was left so we could develop the render graph beside the previous implementation. Last week we removed the switch. This PR will remove most of the unused code. There might be some left and will be removed when detected. Pull Request: https://projects.blender.org/blender/blender/pulls/123422
2024-06-20 11:34:19 +02:00
const VKDevice &device = VKBackend::get().device;
Vulkan: Memory Statistics This PR shows the memory footprint in the statusbar when activated. Only memory allocated on the VRAM is counted. Memory allocated on host memory is not counted. ![image](/attachments/33cedc89-9ada-4c0a-9a94-6c1b3e22b64b) Pull Request: https://projects.blender.org/blender/blender/pulls/115184
2023-11-20 14:08:19 +01:00
device.memory_statistics_get(r_total_mem_kb, r_free_mem_kb);
}
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
Vulkan: Texture Unpacking This PR adds support for `GPU_unpack_row_length_set` to the vulkan backend. Texture unpacking is used when uploading a part of a texture from host memory to device memory. Pull Request: https://projects.blender.org/blender/blender/pulls/107360
2023-04-26 09:23:58 +02:00
/* -------------------------------------------------------------------- */
/** \name State manager
* \{ */
Vulkan: Resource Pools This PR implements #126353; In short: keep discard list as part of swap chain images. This allows better determination when resources are actually not in use anymore. ## Resource pool Resource pools keep track of the resources for a swap chain image. In Blender this is a bit more complicated due to the way GPUContext work. A single thread can have multiple contexts. Some of them have a swap chain (GHOST Window) other don't (draw manager). The resource pool should be shared between the contexts running on the same thread. When opening multiple windows there are also multiple swap chains to consider. ### Discard pile Resource handles that are deleted and stored in the discard pile. When we are sure that these resources are not used on the GPU anymore these are destroyed. ### Reusable resources There are other resources as well like: - Descriptor sets - Descriptor pools ## Open issues There are some limitations that require future PRs to fix including: - Background rendering - Handling multiple windows - Improve CPU/GPU synchronization - Reuse staging buffers Pull Request: https://projects.blender.org/blender/blender/pulls/126353
2024-08-19 15:37:48 +02:00
VKDescriptorPools &VKContext::descriptor_pools_get()
{
Refactor: Move Vulkan descriptor pools Moves the descriptor pools from resource pools to thread data. The descriptor pools uses a recycling approach and don't need to be guarded anymore inside a resource pool. Now only the descriptor set tracker is inside the resource pool. Pull Request: https://projects.blender.org/blender/blender/pulls/145393
2025-08-29 13:33:35 +02:00
return thread_data_.value().get().descriptor_pools;
Vulkan: Resource Pools This PR implements #126353; In short: keep discard list as part of swap chain images. This allows better determination when resources are actually not in use anymore. ## Resource pool Resource pools keep track of the resources for a swap chain image. In Blender this is a bit more complicated due to the way GPUContext work. A single thread can have multiple contexts. Some of them have a swap chain (GHOST Window) other don't (draw manager). The resource pool should be shared between the contexts running on the same thread. When opening multiple windows there are also multiple swap chains to consider. ### Discard pile Resource handles that are deleted and stored in the discard pile. When we are sure that these resources are not used on the GPU anymore these are destroyed. ### Reusable resources There are other resources as well like: - Descriptor sets - Descriptor pools ## Open issues There are some limitations that require future PRs to fix including: - Background rendering - Handling multiple windows - Improve CPU/GPU synchronization - Reuse staging buffers Pull Request: https://projects.blender.org/blender/blender/pulls/126353
2024-08-19 15:37:48 +02:00
}
VKDescriptorSetTracker &VKContext::descriptor_set_get()
{
Vulkan: Remove resource pools Multiple previous changes made resource pools obsolete. Resource pools were used to keep track of resources when the frame is rendered. Multiple frames can be rendered at the same time and resources could overlap. This has been replaced (not this commit) to be part of the render graph and when an submission has completed the resources are recycled. Continuation of: https://projects.blender.org/blender/blender/pulls/145408 Pull Request: https://projects.blender.org/blender/blender/pulls/145511
2025-09-01 15:34:14 +02:00
return thread_data_.value().get().descriptor_set;
Vulkan: Resource Pools This PR implements #126353; In short: keep discard list as part of swap chain images. This allows better determination when resources are actually not in use anymore. ## Resource pool Resource pools keep track of the resources for a swap chain image. In Blender this is a bit more complicated due to the way GPUContext work. A single thread can have multiple contexts. Some of them have a swap chain (GHOST Window) other don't (draw manager). The resource pool should be shared between the contexts running on the same thread. When opening multiple windows there are also multiple swap chains to consider. ### Discard pile Resource handles that are deleted and stored in the discard pile. When we are sure that these resources are not used on the GPU anymore these are destroyed. ### Reusable resources There are other resources as well like: - Descriptor sets - Descriptor pools ## Open issues There are some limitations that require future PRs to fix including: - Background rendering - Handling multiple windows - Improve CPU/GPU synchronization - Reuse staging buffers Pull Request: https://projects.blender.org/blender/blender/pulls/126353
2024-08-19 15:37:48 +02:00
}
Vulkan: Device Context Resource Management The current Vulkan resource management has some issues as context that are not active can still use resources that are freed via another context. When this happens incorrect data can be read on the GPU and even crash Blender. When trying to bind something that now contains other memory pointers. This change introduces that contexts are tracked via the device. Context will be registered/unregistered with the device instance. Unbinding of resources must pass the device and the device will check all registered contexts. Binding of resources will happen via the active context only. On user perspective this now allowes: - Opening/switching files - Switching workspaces - Switching render engines Pull Request: https://projects.blender.org/blender/blender/pulls/108968
2023-06-15 08:14:37 +02:00
VKStateManager &VKContext::state_manager_get() const
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
{
return *static_cast<VKStateManager *>(state_manager);
}
Vulkan: Missing binding tracking f2ae04db10cca93e143f56279ab86112c29c985e introduces missing binding tracking for SSBO and UBOs. Vulkan relies on validation layers to report on missing bindings, but the binding information should still be cleared in the context state manager. Pull Request: https://projects.blender.org/blender/blender/pulls/120814
2024-04-19 11:13:06 +02:00
void VKContext::debug_unbind_all_ubo()
{
state_manager_get().uniform_buffer_unbind_all();
};
void VKContext::debug_unbind_all_ssbo()
{
state_manager_get().storage_buffer_unbind_all();
};
Vulkan: Texture Unpacking This PR adds support for `GPU_unpack_row_length_set` to the vulkan backend. Texture unpacking is used when uploading a part of a texture from host memory to device memory. Pull Request: https://projects.blender.org/blender/blender/pulls/107360
2023-04-26 09:23:58 +02:00
/** \} */
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
/* -------------------------------------------------------------------- */
Cleanup: spelling in comments & some corrections
2023-05-20 21:17:09 +10:00
/** \name Frame-buffer
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
* \{ */
Vulkan: Clearing Framebuffer + Scissors This PR adds support for clearing framebuffers and scissor testing. Tweaks had to be made to VKTexture to keep track of its layout on the device. Based on the actual call the layout can switch to a more optimum layout. For example during upload of a texture the texture will be converted to a transfer destination optimized layout. When reading from the texture it will be converted to a transfer source optimized layout. The order of the attachments in the framebuffer follows the next rules - When only color attachments are there the color attachments will be placed in the slot they are defined. This way it will match the ShaderCreateInfo binding location. - When a stencil/depth attachment is added it will be placed right after the color attachments. When there isn't a color attachment it will be the first attachment. Pull Request: https://projects.blender.org/blender/blender/pulls/106044
2023-03-28 11:51:32 +02:00
void VKContext::activate_framebuffer(VKFrameBuffer &framebuffer)
{
if (has_active_framebuffer()) {
deactivate_framebuffer();
}
BLI_assert(active_fb == nullptr);
active_fb = &framebuffer;
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
framebuffer.update_size();
Vulkan: Add Support for sRGB Framebuffer Enablement Allow binding of framebuffers without sRGB to linear transform. `GPU_framebuffer_bind_no_srgb`. This Patch removes color transform artifacts in node, image and sequence editor. When the framebuffer is an srgb framebuffer and it is bound without the transformation, the SRGB textures are bound as UNORM variants. As framebuffer, render pass and subpass recreation is ensured by `VKCommandBuffer` we don't need to mark the framebuffer dirty at this time. Later on we can optimize this by adding a state changed detection for framebuffers and render passes. Pull Request: https://projects.blender.org/blender/blender/pulls/113838
2023-10-19 14:41:18 +02:00
framebuffer.update_srgb();
Vulkan: Remove render graph switch As render graph is now the default, we can remove the render graph switch. This allows us to cleanup unused functions and classes. Pull Request: https://projects.blender.org/blender/blender/pulls/123219
2024-06-14 09:44:59 +02:00
framebuffer.rendering_reset();
Vulkan: Clearing Framebuffer + Scissors This PR adds support for clearing framebuffers and scissor testing. Tweaks had to be made to VKTexture to keep track of its layout on the device. Based on the actual call the layout can switch to a more optimum layout. For example during upload of a texture the texture will be converted to a transfer destination optimized layout. When reading from the texture it will be converted to a transfer source optimized layout. The order of the attachments in the framebuffer follows the next rules - When only color attachments are there the color attachments will be placed in the slot they are defined. This way it will match the ShaderCreateInfo binding location. - When a stencil/depth attachment is added it will be placed right after the color attachments. When there isn't a color attachment it will be the first attachment. Pull Request: https://projects.blender.org/blender/blender/pulls/106044
2023-03-28 11:51:32 +02:00
}
Vulkan: Frame Buffer Flipping Vulkan coordinate system is flipped compared to OpenGL. This PR flips the drawing when drawn to the on-screen frame buffer. Offscreen frame buffers are still drawn upside down. The flipping is done by making the viewport of the framebuffer negative. Pull Request: https://projects.blender.org/blender/blender/pulls/107743
2023-05-09 09:22:26 +02:00
VKFrameBuffer *VKContext::active_framebuffer_get() const
{
return unwrap(active_fb);
}
Vulkan: Clearing Framebuffer + Scissors This PR adds support for clearing framebuffers and scissor testing. Tweaks had to be made to VKTexture to keep track of its layout on the device. Based on the actual call the layout can switch to a more optimum layout. For example during upload of a texture the texture will be converted to a transfer destination optimized layout. When reading from the texture it will be converted to a transfer source optimized layout. The order of the attachments in the framebuffer follows the next rules - When only color attachments are there the color attachments will be placed in the slot they are defined. This way it will match the ShaderCreateInfo binding location. - When a stencil/depth attachment is added it will be placed right after the color attachments. When there isn't a color attachment it will be the first attachment. Pull Request: https://projects.blender.org/blender/blender/pulls/106044
2023-03-28 11:51:32 +02:00
bool VKContext::has_active_framebuffer() const
{
Vulkan: Frame Buffer Flipping Vulkan coordinate system is flipped compared to OpenGL. This PR flips the drawing when drawn to the on-screen frame buffer. Offscreen frame buffers are still drawn upside down. The flipping is done by making the viewport of the framebuffer negative. Pull Request: https://projects.blender.org/blender/blender/pulls/107743
2023-05-09 09:22:26 +02:00
return active_framebuffer_get() != nullptr;
Vulkan: Clearing Framebuffer + Scissors This PR adds support for clearing framebuffers and scissor testing. Tweaks had to be made to VKTexture to keep track of its layout on the device. Based on the actual call the layout can switch to a more optimum layout. For example during upload of a texture the texture will be converted to a transfer destination optimized layout. When reading from the texture it will be converted to a transfer source optimized layout. The order of the attachments in the framebuffer follows the next rules - When only color attachments are there the color attachments will be placed in the slot they are defined. This way it will match the ShaderCreateInfo binding location. - When a stencil/depth attachment is added it will be placed right after the color attachments. When there isn't a color attachment it will be the first attachment. Pull Request: https://projects.blender.org/blender/blender/pulls/106044
2023-03-28 11:51:32 +02:00
}
void VKContext::deactivate_framebuffer()
{
Vulkan: Frame Buffer Flipping Vulkan coordinate system is flipped compared to OpenGL. This PR flips the drawing when drawn to the on-screen frame buffer. Offscreen frame buffers are still drawn upside down. The flipping is done by making the viewport of the framebuffer negative. Pull Request: https://projects.blender.org/blender/blender/pulls/107743
2023-05-09 09:22:26 +02:00
VKFrameBuffer *framebuffer = active_framebuffer_get();
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
BLI_assert(framebuffer != nullptr);
Vulkan: Ensure rendering ends when deleting attached framebuffer When a frame buffer that is attached is being deleted the rendering end event will never happen which leads to inconsistent render graphs.
2024-08-20 14:21:25 +02:00
if (framebuffer->is_rendering()) {
framebuffer->rendering_end(*this);
}
Vulkan: Clearing Framebuffer + Scissors This PR adds support for clearing framebuffers and scissor testing. Tweaks had to be made to VKTexture to keep track of its layout on the device. Based on the actual call the layout can switch to a more optimum layout. For example during upload of a texture the texture will be converted to a transfer destination optimized layout. When reading from the texture it will be converted to a transfer source optimized layout. The order of the attachments in the framebuffer follows the next rules - When only color attachments are there the color attachments will be placed in the slot they are defined. This way it will match the ShaderCreateInfo binding location. - When a stencil/depth attachment is added it will be placed right after the color attachments. When there isn't a color attachment it will be the first attachment. Pull Request: https://projects.blender.org/blender/blender/pulls/106044
2023-03-28 11:51:32 +02:00
active_fb = nullptr;
}
Vulkan: Render graph clear attachments Adds support for clear attachments to the render graph. Clearing attachments require that the command buffer is being set for rendering (vkCmdBeginRendering). **What works** - Clear attachments are working with dynamic rendering and the render graph - `GPUVulkanTest.framebuffer_clear_color_single_attachment` - `GPUVulkanTest.framebuffer_clear_color_multiple_attachments` - `GPUVulkanTest.framebuffer_clear_multiple_color_multiple_attachments` - `GPUVulkanTest.framebuffer_scissor_test` - `GPUVulkanTest.framebuffer_clear_depth` **What still needs to be addressed** When a command buffer is rendering it cannot do any pipeline barriers. For clearing attachments this isn't needed, but when we address drawing we might need to register drawing resource dependencies to the dependency list of the begin rendering node. This will be solved when drawing will be implemented. [#121648] The begin rendering node is large as it has to store data for framebuffers with 8 color attachments as well. This might become an overhead and we could solve this by splicing the data of larger nodes into 2 lists. This will be addressed after we are able to draw a screen so we can collect data on this topic. [#121649] Pull Request: https://projects.blender.org/blender/blender/pulls/121073
2024-05-10 15:39:56 +02:00
void VKContext::rendering_end()
{
VKFrameBuffer *framebuffer = active_framebuffer_get();
if (framebuffer) {
framebuffer->rendering_end(*this);
}
}
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
/** \} */
Vulkan: Enable render graph This PR hooks up the vulkan backend with the render graph for drawing. It can run Blender better than the previous implementation so we also flipped it to be the default implementation. **Some highlights** - Adds support for framebuffer load/store operations - Adds support for framebuffer subpass transitions - Fixes workbench shadows - Performance is just below OpenGL performance when comparing fps. But the screen feels more fluent when using complex scenes. - Current performance is without doing any optimizations so will improve in the future. - EEVEE will not crash but has artifacts and many parts that require more work. **Related to** - #121648 - #118330 **Known Limitation** - Similar to previous implementation resources can be freed when still in use crashing Blender. This is typically the case when playing back an animation or updating a material icon. **Next steps** - Remove old implementation - Get EEVEE to work - Fix double resource freeing - Improve performance by identifying hotspots and change them Pull Request: https://projects.blender.org/blender/blender/pulls/121787
2024-06-14 08:46:33 +02:00
/* -------------------------------------------------------------------- */
/** \name Pipeline
* \{ */
void VKContext::update_pipeline_data(GPUPrimType primitive,
VKVertexAttributeObject &vao,
render_graph::VKPipelineData &r_pipeline_data)
Vulkan: Render graph direct compute This PR adds support for compute shaders to render graph. Only direct dispatch is supported. indirect dispatch will be added in a future PR. This change enables the next test cases to be supported when using render graphs - `GPUVulkanTest.push_constants*` - `GPUVulkanTest.shader_compute_*` - `GPUVulkanTest.buffer_texture` - `GPUVulkanTest.specialization_constants_compute` - `GPUVulkanTest.compute_direct` ``` [==========] 95 tests from 2 test suites ran. (24059 ms total) [ PASSED ] 95 tests. ``` Specialization constants are supported when using the render graph. This should conclude the conversion the prototype of the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/120963
2024-04-23 15:43:32 +02:00
{
VKShader &vk_shader = unwrap(*shader);
Vulkan: Enable render graph This PR hooks up the vulkan backend with the render graph for drawing. It can run Blender better than the previous implementation so we also flipped it to be the default implementation. **Some highlights** - Adds support for framebuffer load/store operations - Adds support for framebuffer subpass transitions - Fixes workbench shadows - Performance is just below OpenGL performance when comparing fps. But the screen feels more fluent when using complex scenes. - Current performance is without doing any optimizations so will improve in the future. - EEVEE will not crash but has artifacts and many parts that require more work. **Related to** - #121648 - #118330 **Known Limitation** - Similar to previous implementation resources can be freed when still in use crashing Blender. This is typically the case when playing back an animation or updating a material icon. **Next steps** - Remove old implementation - Get EEVEE to work - Fix double resource freeing - Improve performance by identifying hotspots and change them Pull Request: https://projects.blender.org/blender/blender/pulls/121787
2024-06-14 08:46:33 +02:00
VKFrameBuffer &framebuffer = *active_framebuffer_get();
Fix #139558: Incorrect shader when using edge slide even In this case a triangle shader was used to render points. This change entails: - Using point shaders in this case - Add support for `GPU_point_size` to update the uniform of the point shader. Pull Request: https://projects.blender.org/blender/blender/pulls/139574
2025-05-29 10:12:33 +02:00
/* Override size of point shader when GPU_point size < 0 */
const float point_size = state_manager_get().mutable_state.point_size;
if (primitive == GPU_PRIM_POINTS && point_size < 0.0) {
GPU: Remove wrapper type for `gpu::Shader` This is the first step into merging DRW_gpu_wrapper.hh into the GPU module. This is very similar to #119825. Pull Request: https://projects.blender.org/blender/blender/pulls/144229
2025-08-11 09:34:28 +02:00
GPU_shader_uniform_1f(shader, "size", -point_size);
Fix #139558: Incorrect shader when using edge slide even In this case a triangle shader was used to render points. This change entails: - Using point shaders in this case - Add support for `GPU_point_size` to update the uniform of the point shader. Pull Request: https://projects.blender.org/blender/blender/pulls/139574
2025-05-29 10:12:33 +02:00
}
GPU: Make Shader Specialization Constant API Thread Safe This allows multiple threads to request different specializations without locking usage of all specialized shaders program when a new specialization is being compiled. The specialization constants are bundled in a structure that is being passed to the `Shader::bind()` method. The structure is owned by the calling thread and only used by the `Shader::bind()`. Only querying for the specialized shader (Map lookup) is locking the shader usage. The variant compilation is now also locking and ensured that multiple thread trying to compile the same variant will never result in race condition. Note that this removes the `is_dirty` optimization. This can be added back if this becomes a bottleneck in the future. Otherwise, the performance impact is not noticeable. Pull Request: https://projects.blender.org/blender/blender/pulls/136991
2025-05-19 17:42:55 +02:00
update_pipeline_data(vk_shader,
vk_shader.ensure_and_get_graphics_pipeline(
primitive, vao, state_manager_get(), framebuffer, constants_state_),
r_pipeline_data);
Vulkan: Enable render graph This PR hooks up the vulkan backend with the render graph for drawing. It can run Blender better than the previous implementation so we also flipped it to be the default implementation. **Some highlights** - Adds support for framebuffer load/store operations - Adds support for framebuffer subpass transitions - Fixes workbench shadows - Performance is just below OpenGL performance when comparing fps. But the screen feels more fluent when using complex scenes. - Current performance is without doing any optimizations so will improve in the future. - EEVEE will not crash but has artifacts and many parts that require more work. **Related to** - #121648 - #118330 **Known Limitation** - Similar to previous implementation resources can be freed when still in use crashing Blender. This is typically the case when playing back an animation or updating a material icon. **Next steps** - Remove old implementation - Get EEVEE to work - Fix double resource freeing - Improve performance by identifying hotspots and change them Pull Request: https://projects.blender.org/blender/blender/pulls/121787
2024-06-14 08:46:33 +02:00
}
void VKContext::update_pipeline_data(render_graph::VKPipelineData &r_pipeline_data)
{
VKShader &vk_shader = unwrap(*shader);
GPU: Make Shader Specialization Constant API Thread Safe This allows multiple threads to request different specializations without locking usage of all specialized shaders program when a new specialization is being compiled. The specialization constants are bundled in a structure that is being passed to the `Shader::bind()` method. The structure is owned by the calling thread and only used by the `Shader::bind()`. Only querying for the specialized shader (Map lookup) is locking the shader usage. The variant compilation is now also locking and ensured that multiple thread trying to compile the same variant will never result in race condition. Note that this removes the `is_dirty` optimization. This can be added back if this becomes a bottleneck in the future. Otherwise, the performance impact is not noticeable. Pull Request: https://projects.blender.org/blender/blender/pulls/136991
2025-05-19 17:42:55 +02:00
update_pipeline_data(
vk_shader, vk_shader.ensure_and_get_compute_pipeline(constants_state_), r_pipeline_data);
Vulkan: Enable render graph This PR hooks up the vulkan backend with the render graph for drawing. It can run Blender better than the previous implementation so we also flipped it to be the default implementation. **Some highlights** - Adds support for framebuffer load/store operations - Adds support for framebuffer subpass transitions - Fixes workbench shadows - Performance is just below OpenGL performance when comparing fps. But the screen feels more fluent when using complex scenes. - Current performance is without doing any optimizations so will improve in the future. - EEVEE will not crash but has artifacts and many parts that require more work. **Related to** - #121648 - #118330 **Known Limitation** - Similar to previous implementation resources can be freed when still in use crashing Blender. This is typically the case when playing back an animation or updating a material icon. **Next steps** - Remove old implementation - Get EEVEE to work - Fix double resource freeing - Improve performance by identifying hotspots and change them Pull Request: https://projects.blender.org/blender/blender/pulls/121787
2024-06-14 08:46:33 +02:00
}
void VKContext::update_pipeline_data(VKShader &vk_shader,
VkPipeline vk_pipeline,
render_graph::VKPipelineData &r_pipeline_data)
{
r_pipeline_data.vk_pipeline_layout = vk_shader.vk_pipeline_layout;
r_pipeline_data.vk_pipeline = vk_pipeline;
Vulkan: Render graph direct compute This PR adds support for compute shaders to render graph. Only direct dispatch is supported. indirect dispatch will be added in a future PR. This change enables the next test cases to be supported when using render graphs - `GPUVulkanTest.push_constants*` - `GPUVulkanTest.shader_compute_*` - `GPUVulkanTest.buffer_texture` - `GPUVulkanTest.specialization_constants_compute` - `GPUVulkanTest.compute_direct` ``` [==========] 95 tests from 2 test suites ran. (24059 ms total) [ PASSED ] 95 tests. ``` Specialization constants are supported when using the render graph. This should conclude the conversion the prototype of the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/120963
2024-04-23 15:43:32 +02:00
/* Update push constants. */
Vulkan: Enable render graph This PR hooks up the vulkan backend with the render graph for drawing. It can run Blender better than the previous implementation so we also flipped it to be the default implementation. **Some highlights** - Adds support for framebuffer load/store operations - Adds support for framebuffer subpass transitions - Fixes workbench shadows - Performance is just below OpenGL performance when comparing fps. But the screen feels more fluent when using complex scenes. - Current performance is without doing any optimizations so will improve in the future. - EEVEE will not crash but has artifacts and many parts that require more work. **Related to** - #121648 - #118330 **Known Limitation** - Similar to previous implementation resources can be freed when still in use crashing Blender. This is typically the case when playing back an animation or updating a material icon. **Next steps** - Remove old implementation - Get EEVEE to work - Fix double resource freeing - Improve performance by identifying hotspots and change them Pull Request: https://projects.blender.org/blender/blender/pulls/121787
2024-06-14 08:46:33 +02:00
r_pipeline_data.push_constants_data = nullptr;
r_pipeline_data.push_constants_size = 0;
Vulkan: Render graph direct compute This PR adds support for compute shaders to render graph. Only direct dispatch is supported. indirect dispatch will be added in a future PR. This change enables the next test cases to be supported when using render graphs - `GPUVulkanTest.push_constants*` - `GPUVulkanTest.shader_compute_*` - `GPUVulkanTest.buffer_texture` - `GPUVulkanTest.specialization_constants_compute` - `GPUVulkanTest.compute_direct` ``` [==========] 95 tests from 2 test suites ran. (24059 ms total) [ PASSED ] 95 tests. ``` Specialization constants are supported when using the render graph. This should conclude the conversion the prototype of the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/120963
2024-04-23 15:43:32 +02:00
const VKPushConstants::Layout &push_constants_layout =
vk_shader.interface_get().push_constants_layout_get();
if (push_constants_layout.storage_type_get() == VKPushConstants::StorageType::PUSH_CONSTANTS) {
Vulkan: Enable render graph This PR hooks up the vulkan backend with the render graph for drawing. It can run Blender better than the previous implementation so we also flipped it to be the default implementation. **Some highlights** - Adds support for framebuffer load/store operations - Adds support for framebuffer subpass transitions - Fixes workbench shadows - Performance is just below OpenGL performance when comparing fps. But the screen feels more fluent when using complex scenes. - Current performance is without doing any optimizations so will improve in the future. - EEVEE will not crash but has artifacts and many parts that require more work. **Related to** - #121648 - #118330 **Known Limitation** - Similar to previous implementation resources can be freed when still in use crashing Blender. This is typically the case when playing back an animation or updating a material icon. **Next steps** - Remove old implementation - Get EEVEE to work - Fix double resource freeing - Improve performance by identifying hotspots and change them Pull Request: https://projects.blender.org/blender/blender/pulls/121787
2024-06-14 08:46:33 +02:00
r_pipeline_data.push_constants_size = push_constants_layout.size_in_bytes();
r_pipeline_data.push_constants_data = vk_shader.push_constants.data();
Vulkan: Render graph direct compute This PR adds support for compute shaders to render graph. Only direct dispatch is supported. indirect dispatch will be added in a future PR. This change enables the next test cases to be supported when using render graphs - `GPUVulkanTest.push_constants*` - `GPUVulkanTest.shader_compute_*` - `GPUVulkanTest.buffer_texture` - `GPUVulkanTest.specialization_constants_compute` - `GPUVulkanTest.compute_direct` ``` [==========] 95 tests from 2 test suites ran. (24059 ms total) [ PASSED ] 95 tests. ``` Specialization constants are supported when using the render graph. This should conclude the conversion the prototype of the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/120963
2024-04-23 15:43:32 +02:00
}
Vulkan: Fix push constants tests This fixes several issues with push constants. Push constants test were failing due to setting incorrect parameters. The pipeline stage was used as if it was a shader stage. When using push constants fallback the uniform was loaded to the descriptor set after the descriptor set was checked. Suppress updating push constants of non render graph, when render graph is active. Pull Request: https://projects.blender.org/blender/blender/pulls/121772
2024-05-14 10:44:10 +02:00
/* Update descriptor set. */
Vulkan: Enable render graph This PR hooks up the vulkan backend with the render graph for drawing. It can run Blender better than the previous implementation so we also flipped it to be the default implementation. **Some highlights** - Adds support for framebuffer load/store operations - Adds support for framebuffer subpass transitions - Fixes workbench shadows - Performance is just below OpenGL performance when comparing fps. But the screen feels more fluent when using complex scenes. - Current performance is without doing any optimizations so will improve in the future. - EEVEE will not crash but has artifacts and many parts that require more work. **Related to** - #121648 - #118330 **Known Limitation** - Similar to previous implementation resources can be freed when still in use crashing Blender. This is typically the case when playing back an animation or updating a material icon. **Next steps** - Remove old implementation - Get EEVEE to work - Fix double resource freeing - Improve performance by identifying hotspots and change them Pull Request: https://projects.blender.org/blender/blender/pulls/121787
2024-06-14 08:46:33 +02:00
r_pipeline_data.vk_descriptor_set = VK_NULL_HANDLE;
Fix #140229: Vulkan: Crash during depth aware-navigation Depth navigation sends many small render graphs to the device. It can be that a subsequent render graph uses the same shader as the previous one with the same descriptor set tracker. The descriptor set tracker didn't cleared its full state and a subsequent render graph was generating commands assuming that the device was in a certain state. However it wasn't and a command to bind a descriptor set was skipped resulting in a device out of bound write. Depending on the platform this could overwrite any data on the GPU, including shader programs as the select shader writes to a storage buffer. This clarifies why the issue resulted in very odd and none consistent behavior. This PR fixes this by clearing the VKPipelineData and VKDescriptorTracker. Pull Request: https://projects.blender.org/blender/blender/pulls/140526
2025-06-17 11:17:03 +02:00
r_pipeline_data.descriptor_buffer_device_address = 0;
r_pipeline_data.descriptor_buffer_offset = 0;
Vulkan: Fix push constants tests This fixes several issues with push constants. Push constants test were failing due to setting incorrect parameters. The pipeline stage was used as if it was a shader stage. When using push constants fallback the uniform was loaded to the descriptor set after the descriptor set was checked. Suppress updating push constants of non render graph, when render graph is active. Pull Request: https://projects.blender.org/blender/blender/pulls/121772
2024-05-14 10:44:10 +02:00
if (vk_shader.has_descriptor_set()) {
Vulkan: Resource Pools This PR implements #126353; In short: keep discard list as part of swap chain images. This allows better determination when resources are actually not in use anymore. ## Resource pool Resource pools keep track of the resources for a swap chain image. In Blender this is a bit more complicated due to the way GPUContext work. A single thread can have multiple contexts. Some of them have a swap chain (GHOST Window) other don't (draw manager). The resource pool should be shared between the contexts running on the same thread. When opening multiple windows there are also multiple swap chains to consider. ### Discard pile Resource handles that are deleted and stored in the discard pile. When we are sure that these resources are not used on the GPU anymore these are destroyed. ### Reusable resources There are other resources as well like: - Descriptor sets - Descriptor pools ## Open issues There are some limitations that require future PRs to fix including: - Background rendering - Handling multiple windows - Improve CPU/GPU synchronization - Reuse staging buffers Pull Request: https://projects.blender.org/blender/blender/pulls/126353
2024-08-19 15:37:48 +02:00
VKDescriptorSetTracker &descriptor_set = descriptor_set_get();
Vulkan: Add support for descriptor buffers Descriptor sets/pools are known to be troublesome as it doesn't match how GPUs work, or how application want to work, adding more complexity than needed. This results is quite an overhead allocating and deallocating descriptor sets. This PR will use descriptor buffers when they are available. Most platforms support descriptor buffers. When not available descriptor pools/sets will be used. Although this is a feature I would like to land it in 4.5 due to the API changes. This makes it easier to fix issues when 4.5 is released. The feature can easily be disabled by setting the feature to false if it has to many problems. Pull Request: https://projects.blender.org/blender/blender/pulls/138266
2025-06-06 10:20:36 +02:00
descriptor_set.update_descriptor_set(*this, access_info_, r_pipeline_data);
Vulkan: Fix push constants tests This fixes several issues with push constants. Push constants test were failing due to setting incorrect parameters. The pipeline stage was used as if it was a shader stage. When using push constants fallback the uniform was loaded to the descriptor set after the descriptor set was checked. Suppress updating push constants of non render graph, when render graph is active. Pull Request: https://projects.blender.org/blender/blender/pulls/121772
2024-05-14 10:44:10 +02:00
}
Vulkan: Render graph direct compute This PR adds support for compute shaders to render graph. Only direct dispatch is supported. indirect dispatch will be added in a future PR. This change enables the next test cases to be supported when using render graphs - `GPUVulkanTest.push_constants*` - `GPUVulkanTest.shader_compute_*` - `GPUVulkanTest.buffer_texture` - `GPUVulkanTest.specialization_constants_compute` - `GPUVulkanTest.compute_direct` ``` [==========] 95 tests from 2 test suites ran. (24059 ms total) [ PASSED ] 95 tests. ``` Specialization constants are supported when using the render graph. This should conclude the conversion the prototype of the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/120963
2024-04-23 15:43:32 +02:00
}
Vulkan: Refactor resource binding Resource binding was over-complicated as I didn't understood the state manager and vulkan to make the correct decisions at that time. This refactor will remove a lot of the complexity and improves the performance. **Performance** The performance improvement is noticeable in complex grease pencil scenes. Grease pencil benchmark file picknick: - `NVIDIA Quadro RTX 6000` 17 fps -> 24 fps - `Intel(R) Arc(tm) A750 Graphics (DG2)` 6 -> 21 fps **Bottle-neck** The performance improvements originates from moving the update entry point from state manager to shader interface. The previous implementation (state manager) had to loop over all the bound resources and find in the shader interface where it was located in the descriptor set. Ignoring resources that were not used by the shader. But also making it hard to determine if descriptor sets actually changed. Previous implementation assumed descriptor sets always changed. When descriptor set changed a new descriptor set needed to be allocated. Most drivers this is a fast operation, but on Intel/Mesa this was measurable slow. Using an allocation pool doesn't fit the Vulkan API as you are only able to reuse when the layout matches exactly. Of course doable, but requires another structure to keep track of the actual layouts. **Solution** By using the shader interface as entry point we can: 1. Keep track if there are any changes in the state manager. If not and the layout is the same, the previous shader can be reused. 2. In stead of looping over each bound resource, we loop over bind points. **Future extensions** Bundle all descriptor set uploads just before use. This would be more in line with how 'modern' Vulkan should be implemented. This PR already separates the uploading from the updating and technically allows to upload more than one descriptor set. Instead of looking 1 set back we should measure if we can handle multiple or keep track of the different layouts resources to improve the performance even further. Optional use `VK_KHR_descriptor_buffer` when available. Pull Request: https://projects.blender.org/blender/blender/pulls/128068
2024-09-26 10:59:45 +02:00
render_graph::VKResourceAccessInfo &VKContext::reset_and_get_access_info()
Vulkan: Render graph direct compute This PR adds support for compute shaders to render graph. Only direct dispatch is supported. indirect dispatch will be added in a future PR. This change enables the next test cases to be supported when using render graphs - `GPUVulkanTest.push_constants*` - `GPUVulkanTest.shader_compute_*` - `GPUVulkanTest.buffer_texture` - `GPUVulkanTest.specialization_constants_compute` - `GPUVulkanTest.compute_direct` ``` [==========] 95 tests from 2 test suites ran. (24059 ms total) [ PASSED ] 95 tests. ``` Specialization constants are supported when using the render graph. This should conclude the conversion the prototype of the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/120963
2024-04-23 15:43:32 +02:00
{
Vulkan: Render graph dispatch indirect Add dispatch indirect node. Also refactored the dispatch (direct) node so more logic could be reused. The context only stores a `VKResourceAccessInfo` struct which is reused by both the dispatch and dispatch indirect node. Pull Request: https://projects.blender.org/blender/blender/pulls/120993
2024-04-24 21:28:45 +02:00
access_info_.reset();
return access_info_;
Vulkan: Render graph direct compute This PR adds support for compute shaders to render graph. Only direct dispatch is supported. indirect dispatch will be added in a future PR. This change enables the next test cases to be supported when using render graphs - `GPUVulkanTest.push_constants*` - `GPUVulkanTest.shader_compute_*` - `GPUVulkanTest.buffer_texture` - `GPUVulkanTest.specialization_constants_compute` - `GPUVulkanTest.compute_direct` ``` [==========] 95 tests from 2 test suites ran. (24059 ms total) [ PASSED ] 95 tests. ``` Specialization constants are supported when using the render graph. This should conclude the conversion the prototype of the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/120963
2024-04-23 15:43:32 +02:00
}
Vulkan: Initial Graphics Pipeline Initial graphic pipeline targeting. The goal of this PR is to have an initial graphics pipeline with missing features. It should help identifying areas that requires engineering. Current state is that developers of the GPU module can help with the many smaller pieces that needs to be engineered in order to get it working. It is not intended for users or developers from other modules, but your welcome to learn and give feedback on the code and engineering part. We do expect that large parts of the code still needs to be re-engineered into a more future-proof implementation. **Some highlights**: - In Vulkan the state is kept in the pipeline. Therefore the state is tracked per pipeline. In the near future this could be used as a cache. More research is needed against the default pipeline cache that vulkan already provides. - This PR is based on the work that Kazashi Yoshioka already did. And include work from him in the next areas - Vertex attributes - Vertex data conversions - Pipeline state - Immediate support working. - This PR modifies the VKCommandBuffer to keep track of the framebuffer and its binding state(render pass). Some Vulkan commands require no render pass to be active, other require a render pass. As the order of our commands on API level can not be separated this PR introduces a state engine to keep track of the current state and desired state. This is a temporary solution, the final solution will be proposed when we have a pixel on the screen. At that time I expect that we can design a command encoder that supports all the cases we need. **Notices**: - This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work but hasn't been validated yet. - The graphics pipeline is implemented with pixels in mind, not with performance. Currently when a draw call is scheduled it is flushed and waited until it is finished drawing, before other draw calls can be scheduled. We expected the performance to be worse that it actually is, but we expect huge performance gains in the future. - Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't implemented and might crash when used. - Using multiple windows or resizing of window isn't supported and will stall the system. Pull Request: https://projects.blender.org/blender/blender/pulls/106224
2023-05-11 13:01:56 +02:00
/** \} */
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
/* -------------------------------------------------------------------- */
/** \name Graphics pipeline
* \{ */
Vulkan: Acquire/release swapchain images `GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In that case an approach where swap chain images are acquired and released would map better. This PR introduces `GHOST_SwapWindowBufferAcquire` and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap chains. Previous implementation would first record all GPU commands based on the last used swap chain. In case a swapchain needed to be recreated (window resize, move to other monitor) the recorded commands would not match the swap chain and could lead to artifacts. OpenGL only implements the release functions as they don't have a mechanism to acquire a swap chain image. (Need to validate with the Metal API how this is working and adapt is needed). Currently when starting blender on a HDR capable display the first frame would be based on an sRGB surface and presented on an extended RGB (or other) surface. As these don't match the first frame could be incorrect and also lead to UBs as another surface is expected. Pull Request: https://projects.blender.org/blender/blender/pulls/145728
2025-09-11 07:51:30 +02:00
void VKContext::swap_buffer_acquired_callback()
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
{
VKContext *context = VKContext::get();
BLI_assert(context);
Vulkan: Acquire/release swapchain images `GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In that case an approach where swap chain images are acquired and released would map better. This PR introduces `GHOST_SwapWindowBufferAcquire` and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap chains. Previous implementation would first record all GPU commands based on the last used swap chain. In case a swapchain needed to be recreated (window resize, move to other monitor) the recorded commands would not match the swap chain and could lead to artifacts. OpenGL only implements the release functions as they don't have a mechanism to acquire a swap chain image. (Need to validate with the Metal API how this is working and adapt is needed). Currently when starting blender on a HDR capable display the first frame would be based on an sRGB surface and presented on an extended RGB (or other) surface. As these don't match the first frame could be incorrect and also lead to UBs as another surface is expected. Pull Request: https://projects.blender.org/blender/blender/pulls/145728
2025-09-11 07:51:30 +02:00
context->swap_buffer_acquired_handler();
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
}
Vulkan: Acquire/release swapchain images `GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In that case an approach where swap chain images are acquired and released would map better. This PR introduces `GHOST_SwapWindowBufferAcquire` and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap chains. Previous implementation would first record all GPU commands based on the last used swap chain. In case a swapchain needed to be recreated (window resize, move to other monitor) the recorded commands would not match the swap chain and could lead to artifacts. OpenGL only implements the release functions as they don't have a mechanism to acquire a swap chain image. (Need to validate with the Metal API how this is working and adapt is needed). Currently when starting blender on a HDR capable display the first frame would be based on an sRGB surface and presented on an extended RGB (or other) surface. As these don't match the first frame could be incorrect and also lead to UBs as another surface is expected. Pull Request: https://projects.blender.org/blender/blender/pulls/145728
2025-09-11 07:51:30 +02:00
void VKContext::swap_buffer_draw_callback(const GHOST_VulkanSwapChainData *swap_chain_data)
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
{
VKContext *context = VKContext::get();
BLI_assert(context);
Vulkan: Acquire/release swapchain images `GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In that case an approach where swap chain images are acquired and released would map better. This PR introduces `GHOST_SwapWindowBufferAcquire` and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap chains. Previous implementation would first record all GPU commands based on the last used swap chain. In case a swapchain needed to be recreated (window resize, move to other monitor) the recorded commands would not match the swap chain and could lead to artifacts. OpenGL only implements the release functions as they don't have a mechanism to acquire a swap chain image. (Need to validate with the Metal API how this is working and adapt is needed). Currently when starting blender on a HDR capable display the first frame would be based on an sRGB surface and presented on an extended RGB (or other) surface. As these don't match the first frame could be incorrect and also lead to UBs as another surface is expected. Pull Request: https://projects.blender.org/blender/blender/pulls/145728
2025-09-11 07:51:30 +02:00
context->swap_buffer_draw_handler(*swap_chain_data);
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
}
Vulkan: Acquire/release swapchain images `GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In that case an approach where swap chain images are acquired and released would map better. This PR introduces `GHOST_SwapWindowBufferAcquire` and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap chains. Previous implementation would first record all GPU commands based on the last used swap chain. In case a swapchain needed to be recreated (window resize, move to other monitor) the recorded commands would not match the swap chain and could lead to artifacts. OpenGL only implements the release functions as they don't have a mechanism to acquire a swap chain image. (Need to validate with the Metal API how this is working and adapt is needed). Currently when starting blender on a HDR capable display the first frame would be based on an sRGB surface and presented on an extended RGB (or other) surface. As these don't match the first frame could be incorrect and also lead to UBs as another surface is expected. Pull Request: https://projects.blender.org/blender/blender/pulls/145728
2025-09-11 07:51:30 +02:00
void VKContext::swap_buffer_acquired_handler()
{
sync_backbuffer();
}
void VKContext::swap_buffer_draw_handler(const GHOST_VulkanSwapChainData &swap_chain_data)
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
{
Fix #144048: Vulkan: Crash minimized windows Swapchain handling of minimized windows wasn't correct. On some platforms it still tried to create images with no surface. This PR will discard swapchains of minimized windows, but still being able to flush the render graph and free resources. Pull Request: https://projects.blender.org/blender/blender/pulls/144189
2025-08-08 11:03:02 +02:00
const bool do_blit_to_swapchain = swap_chain_data.image != VK_NULL_HANDLE;
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
const bool use_shader = swap_chain_data.surface_format.colorSpace ==
VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT;
Vulkan: Add debug group for swapchain Improves debugging swapchains when using renderdoc. Pull Request: https://projects.blender.org/blender/blender/pulls/133190
2025-01-17 11:40:11 +01:00
Fix #144048: Vulkan: Crash minimized windows Swapchain handling of minimized windows wasn't correct. On some platforms it still tried to create images with no surface. This PR will discard swapchains of minimized windows, but still being able to flush the render graph and free resources. Pull Request: https://projects.blender.org/blender/blender/pulls/144189
2025-08-08 11:03:02 +02:00
/* When swapchain is invalid/minimized we only flush the render graph to free GPU resources. */
if (!do_blit_to_swapchain) {
flush_render_graph(RenderGraphFlushFlags::SUBMIT | RenderGraphFlushFlags::RENEW_RENDER_GRAPH);
return;
}
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
VKDevice &device = VKBackend::get().device;
render_graph::VKRenderGraph &render_graph = this->render_graph();
Fix #144048: Vulkan: Crash minimized windows Swapchain handling of minimized windows wasn't correct. On some platforms it still tried to create images with no surface. This PR will discard swapchains of minimized windows, but still being able to flush the render graph and free resources. Pull Request: https://projects.blender.org/blender/blender/pulls/144189
2025-08-08 11:03:02 +02:00
VKFrameBuffer &framebuffer = *unwrap(active_fb);
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
framebuffer.rendering_end(*this);
Fix #144048: Vulkan: Crash minimized windows Swapchain handling of minimized windows wasn't correct. On some platforms it still tried to create images with no surface. This PR will discard swapchains of minimized windows, but still being able to flush the render graph and free resources. Pull Request: https://projects.blender.org/blender/blender/pulls/144189
2025-08-08 11:03:02 +02:00
VKTexture *color_attachment = unwrap(unwrap(framebuffer.color_tex(0)));
device.resources.add_image(swap_chain_data.image, 1, "SwapchainImage");
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
GPU_debug_group_begin("BackBuffer.Blit");
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
if (use_shader) {
VKTexture swap_chain_texture("swap_chain_texture");
swap_chain_texture.init_swapchain(swap_chain_data.image,
to_gpu_format(swap_chain_data.surface_format.format));
Shader *shader = device.vk_backbuffer_blit_sh_get();
GPU_shader_bind(shader);
GPU_shader_uniform_1f(shader, "sdr_scale", swap_chain_data.sdr_scale);
Color Management: Improve gamma 2.2 vs piecewise sRGB handling for HDR See the code comments for detailed explanation. But overall we use particular combinations of sRGB and gamma 2.2 encode/decode to match SDR applications while still ensuring HDR values are passed on linearly. This means the user interface and SDR content will display different in Windows HDR mode off and on, but that is consistent with other applications. Split use_hdr variable into use_hdr_buffer about the graphics buffer, and use_hdr_display about the chosen display in Blender. Ref #145022 Pull Request: https://projects.blender.org/blender/blender/pulls/145025
2025-08-23 01:23:32 +02:00
/* See display_as_extended_srgb in libocio_display_processor.cc for details on this choice. */
#if defined(_WIN32) || defined(__APPLE__)
GPU_shader_uniform_1b(shader, "use_gamma22", false);
#else
GPU_shader_uniform_1b(shader, "use_gamma22", true);
#endif
Vulkan: HDR support for Windows This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains . For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain, When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader is used to flip and invert the gamma. SDR white level is updated from a few window event changes, but actually none of them immediately respond to SDR white level changes in the system. That requires using the WinRT API, which we don't do so far. Current limitations: - Intel GPU support - Dual GPU support In the future we may add controls inside Blender for absolute HDR nits, across different platforms. But this makes behavior closer to macOS. See !144565 for details Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/144717
2025-08-22 10:11:55 +02:00
VKStateManager &state_manager = state_manager_get();
state_manager.image_bind(color_attachment, 0);
state_manager.image_bind(&swap_chain_texture, 1);
int2 dispatch_size = math::divide_ceil(
int2(swap_chain_data.extent.width, swap_chain_data.extent.height), int2(16));
VKBackend::get().compute_dispatch(UNPACK2(dispatch_size), 1);
}
else {
render_graph::VKBlitImageNode::CreateInfo blit_image = {};
blit_image.src_image = color_attachment->vk_image_handle();
blit_image.dst_image = swap_chain_data.image;
blit_image.filter = VK_FILTER_LINEAR;
VkImageBlit &region = blit_image.region;
region.srcOffsets[0] = {0, 0, 0};
region.srcOffsets[1] = {color_attachment->width_get(), color_attachment->height_get(), 1};
region.srcSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
region.srcSubresource.mipLevel = 0;
region.srcSubresource.baseArrayLayer = 0;
region.srcSubresource.layerCount = 1;
region.dstOffsets[0] = {0, int32_t(swap_chain_data.extent.height), 0};
region.dstOffsets[1] = {int32_t(swap_chain_data.extent.width), 0, 1};
region.dstSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
region.dstSubresource.mipLevel = 0;
region.dstSubresource.baseArrayLayer = 0;
region.dstSubresource.layerCount = 1;
render_graph.add_node(blit_image);
}
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
render_graph::VKSynchronizationNode::CreateInfo synchronization = {};
synchronization.vk_image = swap_chain_data.image;
synchronization.vk_image_layout = VK_IMAGE_LAYOUT_PRESENT_SRC_KHR;
synchronization.vk_image_aspect = VK_IMAGE_ASPECT_COLOR_BIT;
render_graph.add_node(synchronization);
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
GPU_debug_group_end();
Vulkan: Swapchain synchronization This PR adds swapchain synchronization. When the swapchain swaps the buffers it can add a wait semaphore/signal semaphore to support GPU based synchronization 10 times playback of `rain_restaurant.blend` on AMD RX 7700 Before: 10 × Animation playback: 72347.5540 ms, average: 7234.75539684 ms After: 10 × Animation playback: 41523.2441 ms, average: 4152.32441425 ms Getting around the OpenGL performance target. Pull Request: https://projects.blender.org/blender/blender/pulls/136259
2025-03-24 10:28:52 +01:00
flush_render_graph(RenderGraphFlushFlags::SUBMIT | RenderGraphFlushFlags::RENEW_RENDER_GRAPH,
Vulkan: HDR support for Wayland This change enables HDR support for wayland as an experimental feature. It supports both non-linear extended sRGB and un-clamped sRGB. Windows isn't supported as the HDR settings are not accessible via an API and would require similar settings that games use to configure the monitor. Adding those sliders isn't what we would like to add. Vulkan (working group) is working on new extensions that might change the shortcomings. It isn't clear yet what the extension will do and what the impact is for applications that want to use it. When the extension is out we should review at the situation again. Pull Request: https://projects.blender.org/blender/blender/pulls/133159
2025-06-24 11:51:14 +02:00
VK_PIPELINE_STAGE_TRANSFER_BIT,
Vulkan: Swapchain synchronization This PR adds swapchain synchronization. When the swapchain swaps the buffers it can add a wait semaphore/signal semaphore to support GPU based synchronization 10 times playback of `rain_restaurant.blend` on AMD RX 7700 Before: 10 × Animation playback: 72347.5540 ms, average: 7234.75539684 ms After: 10 × Animation playback: 41523.2441 ms, average: 4152.32441425 ms Getting around the OpenGL performance target. Pull Request: https://projects.blender.org/blender/blender/pulls/136259
2025-03-24 10:28:52 +01:00
swap_chain_data.acquire_semaphore,
Refactor: Vulkan: swapchain This PR refactors the way how swapchains are used. Allow scaling of the swapchain content to the actual resolution of the swapchain. can reduce artefacts when resizing windows when supported. When frame rate is to fast the previous implementation could use a semaphore that were still in use, leading to unwanted stuttering on certain platforms. Waiting when the rendering has finished (GHOST_Frame.submission_fence), before the next image is acquired from the swap chain. Mailbox has been disabled as it can calculate more frames then actually been presented, leading to a lag and increased power usage on others. Pull Request: https://projects.blender.org/blender/blender/pulls/136603
2025-04-01 16:01:22 +02:00
swap_chain_data.present_semaphore,
swap_chain_data.submission_fence);
Vulkan: Device command builder This PR implements a new the threading model for building render graphs based on tests performed last month. For out workload multithreaded command building will block in the driver or device. So better to use a single thread for command building. Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/ - When a context is activated on a thread the context asks for a render graph it can use by calling `VKDevice::render_graph_new`. - Parts of the GPU backend that requires GPU commands will add a specific render graph node to the render graph. The nodes also contains a reference to all resources it needs including the access it needs and the image layout. - When the context is flushed the render graph is submitted to the device by calling `VKDevice::render_graph_submit`. - The device puts the render graph in `VKDevice::submission_pool`. - There is a single background thread that gets the next render graph to send to the GPU (`VKDevice::submission_runner`). - Reorder the commands of the render graph to comply with Vulkan specific command order rules and reducing possible bottlenecks. (`VKScheduler`) - Generate the required barriers `VKCommandBuilder::groups_extract_barriers`. This is a separate step to reduce resource locking giving other threads access to the resource states when they are building the render graph nodes. - GPU commands and pipeline barriers are recorded to a VkCommandBuffer. (`VKCommandBuilder::record_commands`) - When completed the command buffer can be submitted to the device queue. `vkQueueSubmit` - Render graphs that have been submitted can be reused by a next thread. This is done by pushing the render graph to the `VKDevice::unused_render_graphs` queue. Pull Request: https://projects.blender.org/blender/blender/pulls/132681
2025-01-27 08:55:23 +01:00
Vulkan: Remove render graph switch As render graph is now the default, we can remove the render graph switch. This allows us to cleanup unused functions and classes. Pull Request: https://projects.blender.org/blender/blender/pulls/123219
2024-06-14 09:44:59 +02:00
device.resources.remove_image(swap_chain_data.image);
Vulkan: Device statistics This PR adds device statistics which can be printed to the console. By default nothing is printed, but developer can choose to enable it during development. Pull Request: https://projects.blender.org/blender/blender/pulls/124150
2024-07-04 13:47:54 +02:00
#if 0
device.debug_print();
#endif
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
}
GPU: Make Shader Specialization Constant API Thread Safe This allows multiple threads to request different specializations without locking usage of all specialized shaders program when a new specialization is being compiled. The specialization constants are bundled in a structure that is being passed to the `Shader::bind()` method. The structure is owned by the calling thread and only used by the `Shader::bind()`. Only querying for the specialized shader (Map lookup) is locking the shader usage. The variant compilation is now also locking and ensured that multiple thread trying to compile the same variant will never result in race condition. Note that this removes the `is_dirty` optimization. This can be added back if this becomes a bottleneck in the future. Otherwise, the performance impact is not noticeable. Pull Request: https://projects.blender.org/blender/blender/pulls/136991
2025-05-19 17:42:55 +02:00
void VKContext::specialization_constants_set(
const shader::SpecializationConstants *constants_state)
{
constants_state_ = (constants_state != nullptr) ? *constants_state :
shader::SpecializationConstants{};
}
Vulkan: Rewrite GHOST_ContextVK This is a rewrite of GHOST_ContextVK to align with Metal backend as described in #111389 - solution 3 with the adaptation that GHOST is still responsible for presenting the swap chain image and a post callback is still needed in case the swapchain is recreated. This PR also includes some smaller improvements in stability. Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/ * Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK * VKFramebuffer doesn't contain a swap chain image. * Swapchain images can only be used as a blit destination or present source. Not as an attachment. * GHOST_ContextVK::swapBuffers would call a callback with the image the GPU module needs to blit the results to. * Clearing of depth/stencil attachments when no depth write state is set. * Enable VK_KHR_maintenance4 to relax the stage interface mapping. * Removes most vulkan validation warnings/errors. * Detection of frame buffer changes that needs to be applied before performing a command requiring render pass (draw/clear attachment) **Benefits** * Late retrieval of a swap chain image results in better overall performance as Blender doesn't need to wait until the image is presented on the screen. * Easier API and clearer state (transitions) * More control over Image layouts and command buffer states. (Better alignment with Vulkan API) Pull Request: https://projects.blender.org/blender/blender/pulls/111473
2023-08-29 15:05:08 +02:00
/** \} */
Vulkan: Initial OpenXR support The Blender's VkInstance cannot be shared with OpenXR VkInstance. The reason is a chicken and egg problem where OpenXR needs to be started before Vulkan. OpenXR can add special vulkan specific requirements (instance&device) that are only available when the user starts an OpenXR session. The goal implementation is to share memory between both instances using [VK_KHR_external_memory](https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_external_memory.html) and related extensions. However this seems to be a bridge to far as a initial step. Reason: There are not that many samples/ guides and documentation to be found to handle the workflow that we require. We want to do a smaller step by step approach to gain the needed knowledge. For that reason this PR does the most stupidest thing that can be done to share memory between instances. Download the render result to CPU RAM share the host pointer with the OpenXR instance which copies it to the swap chain. Also the synchronization is done using wait idle commands. <video src="attachments/32a0d69b-c3fa-4272-aea0-d207609afaaf" title="Screencast From 2025-03-18 11-16-17.webm" controls></video> **Gaining knowledge** - Experiment with `VK_KHR_external_memory_host` extension for uploading vertex buffers (not related to OpenXR). - Import host pointer with `VK_KHR_external_memory_host`. This reduces the additional memcpy on OpenXR side. - Export host pointer from Blender side from a mappable buffer. - Replace host pointers with fd/dmabuf/winhandle - Remove mappable buffer. Ref #133718 Pull Request: https://projects.blender.org/blender/blender/pulls/133824
2025-03-27 16:57:51 +01:00
/* -------------------------------------------------------------------- */
/** \name OpenXR
* \{ */
void VKContext::openxr_acquire_framebuffer_image_callback(GHOST_VulkanOpenXRData *openxr_data)
{
VKContext *context = VKContext::get();
BLI_assert(context);
context->openxr_acquire_framebuffer_image_handler(*openxr_data);
}
void VKContext::openxr_release_framebuffer_image_callback(GHOST_VulkanOpenXRData *openxr_data)
{
VKContext *context = VKContext::get();
BLI_assert(context);
context->openxr_release_framebuffer_image_handler(*openxr_data);
}
void VKContext::openxr_acquire_framebuffer_image_handler(GHOST_VulkanOpenXRData &openxr_data)
{
VKFrameBuffer &framebuffer = *unwrap(active_fb);
VKTexture *color_attachment = unwrap(unwrap(framebuffer.color_tex(0)));
openxr_data.extent.width = color_attachment->width_get();
openxr_data.extent.height = color_attachment->height_get();
Vulkan/OpenXR: Add support for VK_KHR_external_memory_fd Current implementation uses a CPU roundtrip to transfer render result to the Xr Swapchain. This PR adds support for sharing the render result on Linux systems by using file descriptors. To extend this solution to win32 or dx handles can be done by extending the data transfer modes, register the correct extensions. When not using the same GPU between Blender and OpenXR the CPU roundtrip will still be used. Solution has been validated with monado simulator and seems to be as fast as OpenGL. Performance can be improved by using GPU based synchronization. Current API is limited as we cannot chain the different renders and swapchains. Pull Request: https://projects.blender.org/blender/blender/pulls/136933
2025-04-04 16:01:06 +02:00
Fix: Vulkan/OpenXR: Use correct data format for CPU transfers Incorrect data format was selected when using CPU data transfers in OpenXR. It always used `GPU_DATA_HALF_FLOAT`, also when the swapchains where `GPU_RGBA8`. This resulted in black screens in release mode, and asserts in debud mode. Fixed by selecting the correct data transfer data type based on the swapchain format. Co-authored-by: jeroen@blender.org <Jeroen Bakker> Pull Request: https://projects.blender.org/blender/blender/pulls/137269
2025-04-10 14:22:55 +02:00
/* Determine the data format for data transfer. */
Refactor: GPU: Texture: Replace eGPUTextureFormat by TextureFormat This offers better semantic and safety of the API. Part of #130632 Pull Request: https://projects.blender.org/blender/blender/pulls/142818
2025-07-22 14:58:54 +02:00
const TextureFormat device_format = color_attachment->device_format_get();
Fix: Vulkan/OpenXR: Use correct data format for CPU transfers Incorrect data format was selected when using CPU data transfers in OpenXR. It always used `GPU_DATA_HALF_FLOAT`, also when the swapchains where `GPU_RGBA8`. This resulted in black screens in release mode, and asserts in debud mode. Fixed by selecting the correct data transfer data type based on the swapchain format. Co-authored-by: jeroen@blender.org <Jeroen Bakker> Pull Request: https://projects.blender.org/blender/blender/pulls/137269
2025-04-10 14:22:55 +02:00
eGPUDataFormat data_format = GPU_DATA_HALF_FLOAT;
Refactor: GPU: Texture: Replace eGPUTextureFormat by TextureFormat This offers better semantic and safety of the API. Part of #130632 Pull Request: https://projects.blender.org/blender/blender/pulls/142818
2025-07-22 14:58:54 +02:00
if (ELEM(device_format, TextureFormat::UNORM_8_8_8_8)) {
Fix: Vulkan/OpenXR: Use correct data format for CPU transfers Incorrect data format was selected when using CPU data transfers in OpenXR. It always used `GPU_DATA_HALF_FLOAT`, also when the swapchains where `GPU_RGBA8`. This resulted in black screens in release mode, and asserts in debud mode. Fixed by selecting the correct data transfer data type based on the swapchain format. Co-authored-by: jeroen@blender.org <Jeroen Bakker> Pull Request: https://projects.blender.org/blender/blender/pulls/137269
2025-04-10 14:22:55 +02:00
data_format = GPU_DATA_UBYTE;
}
Vulkan/OpenXR: Add support for VK_KHR_external_memory_fd Current implementation uses a CPU roundtrip to transfer render result to the Xr Swapchain. This PR adds support for sharing the render result on Linux systems by using file descriptors. To extend this solution to win32 or dx handles can be done by extending the data transfer modes, register the correct extensions. When not using the same GPU between Blender and OpenXR the CPU roundtrip will still be used. Solution has been validated with monado simulator and seems to be as fast as OpenGL. Performance can be improved by using GPU based synchronization. Current API is limited as we cannot chain the different renders and swapchains. Pull Request: https://projects.blender.org/blender/blender/pulls/136933
2025-04-04 16:01:06 +02:00
switch (openxr_data.data_transfer_mode) {
case GHOST_kVulkanXRModeCPU:
Fix: Vulkan/OpenXR: Use correct data format for CPU transfers Incorrect data format was selected when using CPU data transfers in OpenXR. It always used `GPU_DATA_HALF_FLOAT`, also when the swapchains where `GPU_RGBA8`. This resulted in black screens in release mode, and asserts in debud mode. Fixed by selecting the correct data transfer data type based on the swapchain format. Co-authored-by: jeroen@blender.org <Jeroen Bakker> Pull Request: https://projects.blender.org/blender/blender/pulls/137269
2025-04-10 14:22:55 +02:00
openxr_data.cpu.image_data = color_attachment->read(0, data_format);
Vulkan/OpenXR: Add support for VK_KHR_external_memory_fd Current implementation uses a CPU roundtrip to transfer render result to the Xr Swapchain. This PR adds support for sharing the render result on Linux systems by using file descriptors. To extend this solution to win32 or dx handles can be done by extending the data transfer modes, register the correct extensions. When not using the same GPU between Blender and OpenXR the CPU roundtrip will still be used. Solution has been validated with monado simulator and seems to be as fast as OpenGL. Performance can be improved by using GPU based synchronization. Current API is limited as we cannot chain the different renders and swapchains. Pull Request: https://projects.blender.org/blender/blender/pulls/136933
2025-04-04 16:01:06 +02:00
break;
case GHOST_kVulkanXRModeFD: {
flush_render_graph(RenderGraphFlushFlags::SUBMIT |
RenderGraphFlushFlags::WAIT_FOR_COMPLETION |
RenderGraphFlushFlags::RENEW_RENDER_GRAPH);
Refactor: Vulkan/OpenXR: Import memory handles only once Importing memory is done to often. when memory doens't change the previous imported memory can be used. The idea is to keep track of the last used buffer and keep reusing it until the view/resolution has changed. This should not happen during a session. Pull Request: https://projects.blender.org/blender/blender/pulls/138984
2025-05-19 12:32:08 +02:00
if (openxr_data.gpu.vk_image_blender != color_attachment->vk_image_handle()) {
VKMemoryExport exported_memory = color_attachment->export_memory(
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT);
openxr_data.gpu.image_handle = exported_memory.handle;
openxr_data.gpu.new_handle = true;
openxr_data.gpu.image_format = to_vk_format(color_attachment->device_format_get());
openxr_data.gpu.memory_size = exported_memory.memory_size;
openxr_data.gpu.memory_offset = exported_memory.memory_offset;
openxr_data.gpu.vk_image_blender = color_attachment->vk_image_handle();
}
Vulkan/OpenXR: Add support for VK_KHR_external_memory_fd Current implementation uses a CPU roundtrip to transfer render result to the Xr Swapchain. This PR adds support for sharing the render result on Linux systems by using file descriptors. To extend this solution to win32 or dx handles can be done by extending the data transfer modes, register the correct extensions. When not using the same GPU between Blender and OpenXR the CPU roundtrip will still be used. Solution has been validated with monado simulator and seems to be as fast as OpenGL. Performance can be improved by using GPU based synchronization. Current API is limited as we cannot chain the different renders and swapchains. Pull Request: https://projects.blender.org/blender/blender/pulls/136933
2025-04-04 16:01:06 +02:00
break;
}
Vulkan/OpenXR: Support VK_KHR_external_memory_win32 This PR add support to use a win32 handle to perform share render result with the OpenXR vulkan instance. This is only possible when the GPU matches. Otherwise a CPU roundtrip will be performed. Pull Request: https://projects.blender.org/blender/blender/pulls/137093
2025-04-08 15:21:55 +02:00
case GHOST_kVulkanXRModeWin32: {
flush_render_graph(RenderGraphFlushFlags::SUBMIT |
RenderGraphFlushFlags::WAIT_FOR_COMPLETION |
RenderGraphFlushFlags::RENEW_RENDER_GRAPH);
Refactor: Vulkan/OpenXR: Import memory handles only once Importing memory is done to often. when memory doens't change the previous imported memory can be used. The idea is to keep track of the last used buffer and keep reusing it until the view/resolution has changed. This should not happen during a session. Pull Request: https://projects.blender.org/blender/blender/pulls/138984
2025-05-19 12:32:08 +02:00
if (openxr_data.gpu.vk_image_blender != color_attachment->vk_image_handle()) {
VKMemoryExport exported_memory = color_attachment->export_memory(
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT);
openxr_data.gpu.image_handle = exported_memory.handle;
openxr_data.gpu.new_handle = true;
openxr_data.gpu.image_format = to_vk_format(color_attachment->device_format_get());
openxr_data.gpu.memory_size = exported_memory.memory_size;
openxr_data.gpu.memory_offset = exported_memory.memory_offset;
openxr_data.gpu.vk_image_blender = color_attachment->vk_image_handle();
}
Vulkan/OpenXR: Support VK_KHR_external_memory_win32 This PR add support to use a win32 handle to perform share render result with the OpenXR vulkan instance. This is only possible when the GPU matches. Otherwise a CPU roundtrip will be performed. Pull Request: https://projects.blender.org/blender/blender/pulls/137093
2025-04-08 15:21:55 +02:00
break;
}
Vulkan/OpenXR: Add support for VK_KHR_external_memory_fd Current implementation uses a CPU roundtrip to transfer render result to the Xr Swapchain. This PR adds support for sharing the render result on Linux systems by using file descriptors. To extend this solution to win32 or dx handles can be done by extending the data transfer modes, register the correct extensions. When not using the same GPU between Blender and OpenXR the CPU roundtrip will still be used. Solution has been validated with monado simulator and seems to be as fast as OpenGL. Performance can be improved by using GPU based synchronization. Current API is limited as we cannot chain the different renders and swapchains. Pull Request: https://projects.blender.org/blender/blender/pulls/136933
2025-04-04 16:01:06 +02:00
}
Vulkan: Initial OpenXR support The Blender's VkInstance cannot be shared with OpenXR VkInstance. The reason is a chicken and egg problem where OpenXR needs to be started before Vulkan. OpenXR can add special vulkan specific requirements (instance&device) that are only available when the user starts an OpenXR session. The goal implementation is to share memory between both instances using [VK_KHR_external_memory](https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_external_memory.html) and related extensions. However this seems to be a bridge to far as a initial step. Reason: There are not that many samples/ guides and documentation to be found to handle the workflow that we require. We want to do a smaller step by step approach to gain the needed knowledge. For that reason this PR does the most stupidest thing that can be done to share memory between instances. Download the render result to CPU RAM share the host pointer with the OpenXR instance which copies it to the swap chain. Also the synchronization is done using wait idle commands. <video src="attachments/32a0d69b-c3fa-4272-aea0-d207609afaaf" title="Screencast From 2025-03-18 11-16-17.webm" controls></video> **Gaining knowledge** - Experiment with `VK_KHR_external_memory_host` extension for uploading vertex buffers (not related to OpenXR). - Import host pointer with `VK_KHR_external_memory_host`. This reduces the additional memcpy on OpenXR side. - Export host pointer from Blender side from a mappable buffer. - Replace host pointers with fd/dmabuf/winhandle - Remove mappable buffer. Ref #133718 Pull Request: https://projects.blender.org/blender/blender/pulls/133824
2025-03-27 16:57:51 +01:00
}
void VKContext::openxr_release_framebuffer_image_handler(GHOST_VulkanOpenXRData &openxr_data)
{
Vulkan/OpenXR: Add support for VK_KHR_external_memory_fd Current implementation uses a CPU roundtrip to transfer render result to the Xr Swapchain. This PR adds support for sharing the render result on Linux systems by using file descriptors. To extend this solution to win32 or dx handles can be done by extending the data transfer modes, register the correct extensions. When not using the same GPU between Blender and OpenXR the CPU roundtrip will still be used. Solution has been validated with monado simulator and seems to be as fast as OpenGL. Performance can be improved by using GPU based synchronization. Current API is limited as we cannot chain the different renders and swapchains. Pull Request: https://projects.blender.org/blender/blender/pulls/136933
2025-04-04 16:01:06 +02:00
switch (openxr_data.data_transfer_mode) {
case GHOST_kVulkanXRModeCPU:
MEM_freeN(openxr_data.cpu.image_data);
openxr_data.cpu.image_data = nullptr;
break;
case GHOST_kVulkanXRModeFD:
/* Nothing to do as import of the handle by the XrInstance removes the ownership of the
* handle. Ref
* https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_external_memory_fd.html#_issues
*/
break;
Vulkan/OpenXR: Support VK_KHR_external_memory_win32 This PR add support to use a win32 handle to perform share render result with the OpenXR vulkan instance. This is only possible when the GPU matches. Otherwise a CPU roundtrip will be performed. Pull Request: https://projects.blender.org/blender/blender/pulls/137093
2025-04-08 15:21:55 +02:00
case GHOST_kVulkanXRModeWin32:
#ifdef _WIN32
Refactor: Vulkan/OpenXR: Import memory handles only once Importing memory is done to often. when memory doens't change the previous imported memory can be used. The idea is to keep track of the last used buffer and keep reusing it until the view/resolution has changed. This should not happen during a session. Pull Request: https://projects.blender.org/blender/blender/pulls/138984
2025-05-19 12:32:08 +02:00
if (openxr_data.gpu.new_handle) {
/* Exported handle isn't consumed during import and should be freed after use. */
CloseHandle(HANDLE(openxr_data.gpu.image_handle));
openxr_data.gpu.image_handle = 0;
}
Vulkan/OpenXR: Support VK_KHR_external_memory_win32 This PR add support to use a win32 handle to perform share render result with the OpenXR vulkan instance. This is only possible when the GPU matches. Otherwise a CPU roundtrip will be performed. Pull Request: https://projects.blender.org/blender/blender/pulls/137093
2025-04-08 15:21:55 +02:00
#endif
break;
Vulkan/OpenXR: Add support for VK_KHR_external_memory_fd Current implementation uses a CPU roundtrip to transfer render result to the Xr Swapchain. This PR adds support for sharing the render result on Linux systems by using file descriptors. To extend this solution to win32 or dx handles can be done by extending the data transfer modes, register the correct extensions. When not using the same GPU between Blender and OpenXR the CPU roundtrip will still be used. Solution has been validated with monado simulator and seems to be as fast as OpenGL. Performance can be improved by using GPU based synchronization. Current API is limited as we cannot chain the different renders and swapchains. Pull Request: https://projects.blender.org/blender/blender/pulls/136933
2025-04-04 16:01:06 +02:00
}
Vulkan: Initial OpenXR support The Blender's VkInstance cannot be shared with OpenXR VkInstance. The reason is a chicken and egg problem where OpenXR needs to be started before Vulkan. OpenXR can add special vulkan specific requirements (instance&device) that are only available when the user starts an OpenXR session. The goal implementation is to share memory between both instances using [VK_KHR_external_memory](https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_external_memory.html) and related extensions. However this seems to be a bridge to far as a initial step. Reason: There are not that many samples/ guides and documentation to be found to handle the workflow that we require. We want to do a smaller step by step approach to gain the needed knowledge. For that reason this PR does the most stupidest thing that can be done to share memory between instances. Download the render result to CPU RAM share the host pointer with the OpenXR instance which copies it to the swap chain. Also the synchronization is done using wait idle commands. <video src="attachments/32a0d69b-c3fa-4272-aea0-d207609afaaf" title="Screencast From 2025-03-18 11-16-17.webm" controls></video> **Gaining knowledge** - Experiment with `VK_KHR_external_memory_host` extension for uploading vertex buffers (not related to OpenXR). - Import host pointer with `VK_KHR_external_memory_host`. This reduces the additional memcpy on OpenXR side. - Export host pointer from Blender side from a mappable buffer. - Replace host pointers with fd/dmabuf/winhandle - Remove mappable buffer. Ref #133718 Pull Request: https://projects.blender.org/blender/blender/pulls/133824
2025-03-27 16:57:51 +01:00
}
/** \} */
Cleanup: trailing space
2023-01-31 15:49:04 +11:00
} // namespace blender::gpu
Reference in New Issue Copy Permalink