griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
3d5d8de17ddc7cb37874bea12359d07fa4e60708
test2/source/blender/gpu/vulkan/render_graph/vk_command_builder.hh

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

207 lines
7.7 KiB
C++
Raw Normal View History

Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
/* SPDX-FileCopyrightText: 2024 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
/** \file
* \ingroup gpu
*/
#pragma once
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
#include "BLI_set.hh"
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
#include "vk_common.hh"
#include "vk_render_graph_node.hh"
#include "vk_scheduler.hh"
namespace blender::gpu::render_graph {
class VKRenderGraph;
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
struct LayeredImageBinding {
VkImage vk_image;
VkImageLayout vk_image_layout;
uint32_t layer;
uint32_t layer_count;
};
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
/**
* Build the command buffer for sending to the device queue.
*
* Determine which nodes needs to be scheduled, Then for each node generate the needed pipeline
* barriers and commands.
*/
class VKCommandBuilder {
private:
/* Pool of VKBufferMemoryBarriers that can be reused when building barriers */
Vector<VkBufferMemoryBarrier> vk_buffer_memory_barriers_;
Vector<VkImageMemoryBarrier> vk_image_memory_barriers_;
/** Template buffer memory barrier. */
VkBufferMemoryBarrier vk_buffer_memory_barrier_;
/** Template image memory barrier. */
VkImageMemoryBarrier vk_image_memory_barrier_;
struct {
/**
* State of the bound pipelines during command building.
*/
VKBoundPipelines active_pipelines;
/**
* When building memory barriers we need to track the src_stage_mask and dst_stage_mask and
* pass them to
* `https://docs.vulkan.org/spec/latest/chapters/synchronization.html#vkCmdPipelineBarrier`
*
* NOTE: Only valid between `reset_barriers` and `send_pipeline_barriers`.
*/
VkPipelineStageFlags src_stage_mask = VK_PIPELINE_STAGE_NONE;
VkPipelineStageFlags dst_stage_mask = VK_PIPELINE_STAGE_NONE;
Vulkan: Render graph debug groups This PR implements debug groups in the render graph. Each node contains a reference to the debug group they belong to. During scheduling the nodes can be reordered and the correct debug group needs to be activated. This is done by keeping track of the current debug group. When a different debug group is needed, the needed ends/begins are added to the command buffer. This mechanism also cleans up debug groups that are not used at all as they don't have any nodes associated to it. Pull Request: https://projects.blender.org/blender/blender/pulls/122054
2024-05-21 17:34:55 +02:00
/**
* Index of the active debug_group. Points to an element in
* `VKRenderGraph.debug_.used_groups`.
*/
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
int64_t active_debug_group_id = -1;
Vulkan: Render graph debug groups This PR implements debug groups in the render graph. Each node contains a reference to the debug group they belong to. During scheduling the nodes can be reordered and the correct debug group needs to be activated. This is done by keeping track of the current debug group. When a different debug group is needed, the needed ends/begins are added to the command buffer. This mechanism also cleans up debug groups that are not used at all as they don't have any nodes associated to it. Pull Request: https://projects.blender.org/blender/blender/pulls/122054
2024-05-21 17:34:55 +02:00
/** Current level of debug groups. (number of nested debug groups). */
int debug_level = 0;
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
/**
* All layered attachments of the last rendering scope (VKNodeType::BEGIN_RENDERING).
*
* when binding layer from these images we expect that they aren't used as attachment and can
* be transitioned into a different image layout. These image layouts are stored in
* `layered_bindings`.
*/
Set<VkImage> layered_attachments;
Vector<LayeredImageBinding> layered_bindings;
const bool subresource_tracking_enabled() const
{
return !layered_attachments.is_empty();
}
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
} state_;
public:
VKCommandBuilder();
/**
* Build the commands of the nodes provided by the `node_handles` parameter. The commands are
* recorded into the given `command_buffer`.
*
* Pre-condition:
* - `command_buffer` must not be in initial state according to
* https://docs.vulkan.org/spec/latest/chapters/cmdbuffers.html#commandbuffers-lifecycle
*
* Post-condition:
* - `command_buffer` will be in executable state according to
* https://docs.vulkan.org/spec/latest/chapters/cmdbuffers.html#commandbuffers-lifecycle
*/
void build_nodes(VKRenderGraph &render_graph,
VKCommandBufferInterface &command_buffer,
Span<NodeHandle> node_handles);
private:
/**
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
* Build the commands of the node group provided by the `node_group` parameter. The commands are
* recorded into the given `command_buffer`.
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
*
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
* build_nodes splits the given node_handles into groups. All synchronization events inside the
* group will be pushed to the front or back of this group. This allows us to record resource
* usage on node level, perform reordering and then invoke the synchronization events outside
* rendering scopes.
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
*/
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
void build_node_group(VKRenderGraph &render_graph,
VKCommandBufferInterface &command_buffer,
Span<NodeHandle> node_group,
Vulkan: Fix incorrect layout transition When many text using BLF the glymp texture could be re-written. In this case the new upload should be done in a separate render graph node group. This wasn't the case and resulted in validation warnings about the glyph texture being in an layout that wasn't expected. This PR simplifies the group extraction a bit by looking ahead when the group ends. Pull Request: https://projects.blender.org/blender/blender/pulls/123547
2024-06-21 13:26:52 +02:00
std::optional<NodeHandle> &r_rendering_scope);
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
/**
Vulkan: Render graph drawing This PR adds drawing support to the render graph. It adds support for draw, indirect draw, indexed draw and indexed indirect draw. Draw commands can only be executed within a rendering scope. Data transfer commands and dispatch commands cannot be executed within a rendering scope. Blender can still send in commands in any order and the render graph needs to find out the best order to minimize context switches (rendering/begin/end). This is the responsibility of the scheduler. The scheduler will push data transfer and dispatch commands outside the rendering scope: - data transfer and dispatch commands at the beginning are done before the rendering begin. - data transfer and dispatch commands at the end are done after the rendering end. - data transfer and dispatches in between draw commands will be pushed to the beginning if they are not yet being used. - for all other data transfer and dispatch commands the rendering is suspenderd and will be continued afterwards. Within a rendering context it is not allowed to perform synchronization commands. Any synchronization commands inside a rendering scope will be performed before the rendering scope begins. Nodes are now organized in groups to simplify the code around this area. Pull Request: https://projects.blender.org/blender/blender/pulls/123168
2024-06-13 09:37:17 +02:00
* Build the pipeline barriers that should be recorded before any other commands of the node
* group the given node is part of is being recorded.
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
*/
void build_pipeline_barriers(VKRenderGraph &render_graph,
VKCommandBufferInterface &command_buffer,
NodeHandle node_handle,
VkPipelineStageFlags pipeline_stage);
void reset_barriers();
void send_pipeline_barriers(VKCommandBufferInterface &command_buffer);
void add_buffer_barriers(VKRenderGraph &render_graph,
NodeHandle node_handle,
VkPipelineStageFlags node_stages);
void add_buffer_barrier(VkBuffer vk_buffer,
VkAccessFlags src_access_mask,
VkAccessFlags dst_access_mask);
void add_buffer_read_barriers(VKRenderGraph &render_graph,
NodeHandle node_handle,
VkPipelineStageFlags node_stages);
void add_buffer_write_barriers(VKRenderGraph &render_graph,
NodeHandle node_handle,
VkPipelineStageFlags node_stages);
void add_image_barriers(VKRenderGraph &render_graph,
NodeHandle node_handle,
VkPipelineStageFlags node_stages);
void add_image_barrier(VkImage vk_image,
VkAccessFlags src_access_mask,
VkAccessFlags dst_access_mask,
VkImageLayout old_image_layout,
Vulkan: Render graph textures This PR implements render graph for VKTexture. During the implementation some tweaks to the render graph was done to support depth and stencil textures. The render graph will record the image aspect being used for each node. This will then be used to generate barriers for the correct aspect. Also fixes an issue that uploading of array textures didn't allocate a large enough staging buffer. Pull Request: https://projects.blender.org/blender/blender/pulls/120821
2024-04-19 14:55:39 +02:00
VkImageLayout new_image_layout,
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
VkImageAspectFlags aspect_mask,
uint32_t layer_base = 0,
uint32_t layer_count = VK_REMAINING_ARRAY_LAYERS);
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
void add_image_read_barriers(VKRenderGraph &render_graph,
NodeHandle node_handle,
VkPipelineStageFlags node_stages);
void add_image_write_barriers(VKRenderGraph &render_graph,
NodeHandle node_handle,
VkPipelineStageFlags node_stages);
Vulkan: Render graph debug groups This PR implements debug groups in the render graph. Each node contains a reference to the debug group they belong to. During scheduling the nodes can be reordered and the correct debug group needs to be activated. This is done by keeping track of the current debug group. When a different debug group is needed, the needed ends/begins are added to the command buffer. This mechanism also cleans up debug groups that are not used at all as they don't have any nodes associated to it. Pull Request: https://projects.blender.org/blender/blender/pulls/122054
2024-05-21 17:34:55 +02:00
/**
* Ensure that the debug group associated with the given node_handle is activated.
*
* When activating it determines how to walk from the current debug group to the to be activated
* debug group by performing end/begin commands on the command buffer.
*
* This ensures that when nodes are reordered that they still appear in the right debug group.
*/
void activate_debug_group(VKRenderGraph &render_graph,
VKCommandBufferInterface &command_buffer,
NodeHandle node_handle);
/**
* Make sure no debugging groups are active anymore.
*/
void finish_debug_groups(VKCommandBufferInterface &command_buffer);
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
private:
/**
* Update the layered attachments list when beginning a new render scope.
*/
void layer_tracking_begin(const VKRenderGraph &render_graph, NodeHandle node_handle);
/**
* Ensure the layout of a layer.
*
* - `old_layout` should be the expected layout of the full image.
*/
void layer_tracking_update(VkImage vk_image,
uint32_t layer,
uint32_t layer_count,
VkImageLayout old_layout,
VkImageLayout new_layout);
/**
* End layer tracking.
*
* All modified layers (layer_tracking_update) will be changed back to the image layout of
* the texture (most likely a `VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL`).
*
* When rendering is suspended, the suspend parameter should be 'true'. This keeps the array
* textures to be kept for when the rendering is resumed.
*/
void layer_tracking_end(VKCommandBufferInterface &command_buffer, bool suspend);
Vulkan: Render graph core **Design Task**: blender/blender#118330 This PR adds the core of the render graph. The render graph isn't used. Current implementation of the Vulkan Backend is slow by design. We focused on stability, before performance. With the new introduced render graph the focus will shift to performance and keep the stability at where it is. Some highlights: - Every context will get its own render graph. (`VKRenderGraph`). - Resources (and resource state tracking) is device specific (`VKResourceStateTracker`). - No node reordering / sub graph execution has been implemented. Currently All nodes in the graph is executed in the order they were added. (`VKScheduler`). - The links inside the graph describe the resources the nodes read from (input links) or writes to (output links) - When resources are written to a resource stamp is incremented allowing keeping track of which nodes needs which stamp of a resource. - At each link the access information (how does the node accesses the resource) and image layout (for image resources) are stored. This allows the render graph to find out how a resource was used in the past and will be used in the future. That is important to construct pipeline barriers that don't stall the whole GPU. # Defined nodes This implementation has nodes for: - Blit image - Clear color image - Copy buffers to buffers - Copy buffers to images - Copy images to images - Copy images to buffers - Dispatch compute shader - Fill buffers - Synchronization Each node has a node info, create info and data struct. The create info contains all data to construct the node, including the links of the graph. The data struct only contains the data stored inside the node. The node info contains the node specific implementation. > NOTE: Other nodes will be added after this PR lands to main. # Resources Before a render graph can be used, the resources should be registered to `VKResourceStateTracker`. In the final implementation this will be owned by the `VKDevice`. Registration of resources can be done by calling `VKResources.add_buffer` or `VKResources.add_image`. # Render graph Nodes can be added to the render graph. When adding a node its read/ write dependencies are extracted and converted into links (`VKNodeInfo. build_links`). When the caller wants to have a resource up to date the functions `VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present` can be called. These functions will select and order the nodes that are needed and convert them to `vkCmd*` commands. These commands include pipeline barrier and image layout transitions. The `vkCmd` are recorded into a command buffer which is sent to the device queue. ## Walking the graph Walking the render graph isn't implemented yet. The idea is to have a `Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and `Map<ResourceWithStamp, NodeHandle> producers`. These attributes can be stored in the render graph and created when building the links, or can be created inside the VKScheduler as a variable. The exact detail which one would be better is unclear as there aren't any users yet. At the moment the scheduler would need them we need to figure out the best way to store and retrieve the consumers/producers. # Unit tests The render graph can be tested by enabling `WITH_GTEST` and use `vk_render_graph` as a filter. ``` bin/tests/blender_test --gtest_filter="vk_render_graph*" ``` Pull Request: https://projects.blender.org/blender/blender/pulls/120427
2024-04-19 10:46:50 +02:00
};
} // namespace blender::gpu::render_graph
Reference in New Issue Copy Permalink