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

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

79 lines
2.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
*/
#include "vk_render_graph.hh"
namespace blender::gpu::render_graph {
VKRenderGraph::VKRenderGraph(std::unique_ptr<VKCommandBufferInterface> command_buffer,
VKResourceStateTracker &resources)
: command_buffer_(std::move(command_buffer)), resources_(resources)
{
}
void VKRenderGraph::free_data()
{
command_buffer_.reset();
}
void VKRenderGraph::remove_nodes(Span<NodeHandle> node_handles)
{
UNUSED_VARS_NDEBUG(node_handles);
BLI_assert_msg(node_handles.size() == nodes_.size(),
"Currently only supporting removing all nodes. The VKScheduler doesn't walk the "
"nodes, and will use incorrect ordering when not all nodes are removed. This "
"needs to be fixed when implementing a better scheduler.");
links_.clear();
Vulkan: Fix memory leak in render graph There was a memory leak in the render graph where nodes where freed, but not the data it could keep. Detected during adding support for compute shaders and running the draw tests. Pull Request: https://projects.blender.org/blender/blender/pulls/120906
2024-04-22 06:22:31 +02:00
for (VKRenderGraphNode &node : nodes_) {
node.free_data();
}
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
nodes_.clear();
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Submit graph
* \{ */
void VKRenderGraph::submit_for_present(VkImage vk_swapchain_image)
{
/* Needs to be executed at forehand as `add_node` also locks the mutex. */
VKSynchronizationNode::CreateInfo synchronization = {};
synchronization.vk_image = vk_swapchain_image;
synchronization.vk_image_layout = VK_IMAGE_LAYOUT_PRESENT_SRC_KHR;
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
synchronization.vk_image_aspect = VK_IMAGE_ASPECT_COLOR_BIT;
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
add_node<VKSynchronizationNode>(synchronization);
std::scoped_lock lock(resources_.mutex);
Span<NodeHandle> node_handles = scheduler_.select_nodes_for_image(*this, vk_swapchain_image);
command_builder_.build_nodes(*this, *command_buffer_, node_handles);
/* TODO: To improve performance it could be better to return a semaphore. This semaphore can be
* passed in the swapchain to ensure GPU synchronization. This also require a second semaphore to
* pause drawing until the swapchain has completed its drawing phase.
*
* Currently using CPU synchronization for safety. */
command_buffer_->submit_with_cpu_synchronization();
remove_nodes(node_handles);
command_buffer_->wait_for_cpu_synchronization();
}
void VKRenderGraph::submit_buffer_for_read(VkBuffer vk_buffer)
{
std::scoped_lock lock(resources_.mutex);
Span<NodeHandle> node_handles = scheduler_.select_nodes_for_buffer(*this, vk_buffer);
command_builder_.build_nodes(*this, *command_buffer_, node_handles);
command_buffer_->submit_with_cpu_synchronization();
remove_nodes(node_handles);
command_buffer_->wait_for_cpu_synchronization();
}
/** \} */
} // namespace blender::gpu::render_graph
Reference in New Issue Copy Permalink