griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
3d5d8de17ddc7cb37874bea12359d07fa4e60708
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.

366 lines
11 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
*/
#include "vk_context.hh"
Vulkan: Provide Debug Utilities This PR uses the VK_EXT_debug_utils extension, but it's only for labeling, so it doesn't rely on the VK_LAYER_KHRONOS_validation functionality. The functions that do these things are loaded into the runtime as vulkan extensions. Declare the function pointers in a struct and make them members of vk_context. Pull Request: https://projects.blender.org/blender/blender/pulls/106098
2023-04-21 12:32:40 +02:00
#include "vk_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
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 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 {
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
VKContext::VKContext(void *ghost_window,
void *ghost_context,
render_graph::VKResourceStateTracker &resources)
: render_graph(std::make_unique<render_graph::VKCommandBufferWrapper>(), resources)
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();
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;
GPU: Add GPU_shader_batch_create_from_infos This is the first commit of the several required to support subprocess-based parallel compilation on OpenGL. This provides the base API and implementation, and exposes the max subprocesses setting on the UI, but it's not used by any code yet. More information and the rest of the code can be found in #121925. This one includes: - A new `GPU_shader_batch` API that allows requesting the compilation of multiple shaders at once, allowing GPU backed to compile them in parallel and asynchronously without blocking the Blender UI. - A virtual `ShaderCompiler` class that backends can use to add their own implementation. - A `ShaderCompilerGeneric` class that implements synchronous/blocking compilation of batches for backends that don't have their own implementation yet. - A `GLShaderCompiler` that supports parallel compilation using subprocesses. - A new `BLI_subprocess` API, including IPC (required for the `GLShaderCompiler` implementation). - The implementation of the subprocess program in `GPU_compilation_subprocess`. - A new `Max Shader Compilation Subprocesses` option in `Preferences > System > Memory & Limits` to enable parallel shader compilation and the max number of subprocesses to allocate (each subprocess has a relatively high memory footprint). Implementation Overview: There's a single `GLShaderCompiler` shared by all OpenGL contexts. This class stores a pool of up to `GCaps.max_parallel_compilations` subprocesses that can be used for compilation. Each subprocess has a shared memory pool used for sending the shader source code from the main Blender process and for receiving the already compiled shader binary from the subprocess. This is synchronized using a series of shared semaphores. The subprocesses maintain a shader cache on disk inside a `BLENDER_SHADER_CACHE` folder at the OS temporary folder. Shaders that fail to compile are tried to be compiled again locally for proper error reports. Hanged subprocesses are currently detected using a timeout of 30s. Pull Request: https://projects.blender.org/blender/blender/pulls/122232
2024-06-05 18:45:57 +02:00
Vulkan: Parallel shader compilation This PR introduces parallel shader compilation for Vulkan shader modules. This will improve shader compilation when switching to material preview or EEVEE render preview. It also improves material compilation. However in order to measure the differences shaderc needs to be updated. PR has been created so we can already start with the code review. This PR doesn't include SPIR-V caching, what will land in a separate PR as it needs more validation. Parallel shader compilation has been tested on AMD/NVIDIA on Linux. Testing on other platforms is planned in the upcoming days. **Performance** ``` AMD Ryzen™ 9 7950X × 32, 64GB Ram Operating system: Linux-6.8.0-44-generic-x86_64-with-glibc2.39 64 Bits, X11 UI Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.107.02 ``` *Test*: Start blender, open barbershop_interior.blend and wait until the viewport has fully settled. | Backend | Test | Duration | | ------- | ------------------------- | -------- | | OpenGL | Coldstart/No subprocesses | 1:52 | | OpenGL | Coldstart/8 Subprocesses | 0:54 | | OpenGL | Warmstart/8 Subprocesses | 0:06 | | Vulkan | Coldstart Without PR | 0:59 | | Vulkan | Warmstart Without PR | 0:58 | | Vulkan | Coldstart With PR | 0:33 | | Vulkan | Warmstart With PR | 0:08 | The difference in time (why OpenGL is faster in a warm start is that all shaders are cached). Vulkan in this case doesn't cache anything and all shaders are recompiled each time. Caching the shaders will be part of a future PR. Main reason not to add it to this PR directly is that SPIR-V cannot easily be validated and would require a sidecar to keep SPIR-V compatible with external tools.. **NOTE**: - This PR was extracted from #127418 - This PR requires #127564 to land and libraries to update. Linux lib is available as attachment in this PR. It works without, but is as slow as single threaded compilation. Pull Request: https://projects.blender.org/blender/blender/pulls/127698
2024-09-20 08:30:09 +02:00
compiler = &VKBackend::get().shader_compiler;
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;
}
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
VKBackend::get().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: 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
imm = nullptr;
Vulkan: Parallel shader compilation This PR introduces parallel shader compilation for Vulkan shader modules. This will improve shader compilation when switching to material preview or EEVEE render preview. It also improves material compilation. However in order to measure the differences shaderc needs to be updated. PR has been created so we can already start with the code review. This PR doesn't include SPIR-V caching, what will land in a separate PR as it needs more validation. Parallel shader compilation has been tested on AMD/NVIDIA on Linux. Testing on other platforms is planned in the upcoming days. **Performance** ``` AMD Ryzen™ 9 7950X × 32, 64GB Ram Operating system: Linux-6.8.0-44-generic-x86_64-with-glibc2.39 64 Bits, X11 UI Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.107.02 ``` *Test*: Start blender, open barbershop_interior.blend and wait until the viewport has fully settled. | Backend | Test | Duration | | ------- | ------------------------- | -------- | | OpenGL | Coldstart/No subprocesses | 1:52 | | OpenGL | Coldstart/8 Subprocesses | 0:54 | | OpenGL | Warmstart/8 Subprocesses | 0:06 | | Vulkan | Coldstart Without PR | 0:59 | | Vulkan | Warmstart Without PR | 0:58 | | Vulkan | Coldstart With PR | 0:33 | | Vulkan | Warmstart With PR | 0:08 | The difference in time (why OpenGL is faster in a warm start is that all shaders are cached). Vulkan in this case doesn't cache anything and all shaders are recompiled each time. Caching the shaders will be part of a future PR. Main reason not to add it to this PR directly is that SPIR-V cannot easily be validated and would require a sidecar to keep SPIR-V compatible with external tools.. **NOTE**: - This PR was extracted from #127418 - This PR requires #127564 to land and libraries to update. Linux lib is available as attachment in this PR. It works without, but is as slow as single threaded compilation. Pull Request: https://projects.blender.org/blender/blender/pulls/127698
2024-09-20 08:30:09 +02:00
compiler = nullptr;
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: 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::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: 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
VKDevice &device = VKBackend::get().device;
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);
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
VKThreadData &thread_data = thread_data_.value().get();
if (assign_if_different(thread_data.resource_pool_index, swap_chain_data.swap_chain_index)) {
VKResourcePool &resource_pool = thread_data.resource_pool_get();
Vulkan: Refactor immediate mode Immediate mode uses the old 'resource tracker' which has been replaced by swap chain resource pools. This PR optimizes immediate mode buffers by utilizing resource pools. Pull Request: https://projects.blender.org/blender/blender/pulls/128188
2024-09-26 16:01:30 +02:00
imm = &resource_pool.immediate;
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
resource_pool.discard_pool.destroy_discarded_resources(device);
resource_pool.reset();
resource_pool.discard_pool.move_data(device.orphaned_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
const bool reset_framebuffer = swap_chain_format_ != swap_chain_data.format ||
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;
}
surface_texture_ = GPU_texture_create_2d("back-left",
swap_chain_data.extent.width,
swap_chain_data.extent.height,
1,
to_gpu_format(swap_chain_data.format),
GPU_TEXTURE_USAGE_ATTACHMENT,
nullptr);
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);
swap_chain_format_ = swap_chain_data.format;
vk_extent_ = swap_chain_data.extent;
}
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
}
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
#if 0
else (is_background) {
discard all orphaned data
}
#endif
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);
imm = &thread_data.resource_pool_get().immediate;
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;
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()
{
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
flush_render_graph();
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
imm = nullptr;
thread_data_.reset();
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
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
void VKContext::end_frame() {}
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::flush() {}
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: 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::flush_render_graph()
{
if (has_active_framebuffer()) {
VKFrameBuffer &framebuffer = *active_framebuffer_get();
if (framebuffer.is_rendering()) {
framebuffer.rendering_end(*this);
}
}
Vulkan: Batch Upload Descriptor Sets Descriptor sets will be uploaded in batch. This allows drivers to do additional optimizations or at least push some looping to the driver side. Pull Request: https://projects.blender.org/blender/blender/pulls/128167
2024-09-26 12:04:09 +02:00
descriptor_set_get().upload_descriptor_sets();
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
render_graph.submit();
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()
{
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
return thread_data_.value().get().resource_pool_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()
{
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
return thread_data_.value().get().resource_pool_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();
update_pipeline_data(
vk_shader,
vk_shader.ensure_and_get_graphics_pipeline(primitive, vao, state_manager_get(), framebuffer),
r_pipeline_data);
}
void VKContext::update_pipeline_data(render_graph::VKPipelineData &r_pipeline_data)
{
VKShader &vk_shader = unwrap(*shader);
update_pipeline_data(vk_shader, vk_shader.ensure_and_get_compute_pipeline(), r_pipeline_data);
}
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;
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: 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
descriptor_set.update_descriptor_set(*this, access_info_);
r_pipeline_data.vk_descriptor_set = descriptor_set.vk_descriptor_set;
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
* \{ */
void VKContext::swap_buffers_pre_callback(const GHOST_VulkanSwapChainData *swap_chain_data)
{
VKContext *context = VKContext::get();
BLI_assert(context);
context->swap_buffers_pre_handler(*swap_chain_data);
}
void VKContext::swap_buffers_post_callback()
{
VKContext *context = VKContext::get();
BLI_assert(context);
context->swap_buffers_post_handler();
}
void VKContext::swap_buffers_pre_handler(const GHOST_VulkanSwapChainData &swap_chain_data)
{
VKFrameBuffer &framebuffer = *unwrap(back_left);
VKTexture *color_attachment = unwrap(unwrap(framebuffer.color_tex(0)));
Vulkan: Render graph - swapchain handling This PR implements swapchain handling when using the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/122144
2024-05-23 12:00:36 +02:00
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_NEAREST;
VkImageBlit &region = blit_image.region;
region.srcOffsets[0] = {0, color_attachment->height_get() - 1, 0};
region.srcOffsets[1] = {color_attachment->width_get(), 0, 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, 0, 0};
region.dstOffsets[1] = {
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
int32_t(swap_chain_data.extent.width), int32_t(swap_chain_data.extent.height), 1};
Vulkan: Render graph - swapchain handling This PR implements swapchain handling when using the render graph. Pull Request: https://projects.blender.org/blender/blender/pulls/122144
2024-05-23 12:00:36 +02:00
region.dstSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
region.dstSubresource.mipLevel = 0;
region.dstSubresource.baseArrayLayer = 0;
region.dstSubresource.layerCount = 1;
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
/* Swap chain commands are CPU synchronized at this moment, allowing to temporary add the swap
* chain image as device resources. When we move towards GPU swap chain synchronization we need
* to keep track of the swap chain image between frames. */
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
VKDevice &device = VKBackend::get().device;
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.add_image(swap_chain_data.image,
Vulkan: Layer tracking during render scope EEVEE can bind layers of a texture that is also used as an attachment. When binding the image layout of these specific layers can be different that the image layout of the whole image. This fixes the known synchronization issues inside EEVEE. wasp_bot, tree_creature and wanderer scenes can be rendered without any synchronization issue reported by the Vulkan validation layers. Design task: #124214 When beginning to render the attachments are being evaluated. If there is an arrayed texture (with multiple layers) the individual layers of that texture can be tracked during until the rendering is ended. When the same texture is bound to a shader it will be a different layer (otherwise there is a feedback loop, which isn't allowed). The bound layers will typically need a different layout the transition to the new layout is executed and recorded. When the rendering ends, the layers are transitioned back to the layout the texture is expected in. It can happen that a layer is used multiple times during the same rendering. In that case the rendering should be suspended to perform the transition. Image layout transitions are not allowed during rendering. There is one place where a layer needs to be transited multiple times that is when EEVEE wants to extract the thickness from the shadow. The thickness is stored inside the gbuffer_normal which is also used as an attachment. Eval then samples the thickness from the gbuffer_normal as a sampler. To work around this issue we suspend the rendering when a `GPU_BARRIER_SHADER_IMAGE_ACCESS` is signaled. Pull Request: https://projects.blender.org/blender/blender/pulls/124407
2024-07-16 16:39:18 +02:00
1,
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
VK_IMAGE_LAYOUT_PRESENT_SRC_KHR,
Vulkan: Improve debugging render graph Adds debug print function to output a node with its inputs and outputs. Also keep track of the name of the resource (only images) what will be presented. Tracking of the resource name is only done in debug builds. Pull Request: https://projects.blender.org/blender/blender/pulls/124033
2024-07-02 13:29:34 +02:00
render_graph::ResourceOwner::SWAP_CHAIN,
"SwapchainImage");
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_end(*this);
render_graph.add_node(blit_image);
Vulkan: Batch Upload Descriptor Sets Descriptor sets will be uploaded in batch. This allows drivers to do additional optimizations or at least push some looping to the driver side. Pull Request: https://projects.blender.org/blender/blender/pulls/128167
2024-09-26 12:04:09 +02:00
descriptor_set_get().upload_descriptor_sets();
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
render_graph.submit_for_present(swap_chain_data.image);
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
}
void VKContext::swap_buffers_post_handler()
{
sync_backbuffer();
}
/** \} */
Cleanup: trailing space
2023-01-31 15:49:04 +11:00
} // namespace blender::gpu
Reference in New Issue Copy Permalink