Vulkan Cookbook 第六章 3 指定子过程之间的依赖关系

博客主要围绕渲染过程中子过程依赖关系的指定展开。当子过程操作存在依赖时需指定,定义依赖关系与设置内存屏障类似。介绍了创建变量设置依赖项各成员值的方法,还说明了其运作原理及设置图像内存障碍时的要求,并给出子过程间依赖关系的示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

指定子过程之间的依赖关系

译者注:示例代码点击此处

当给定子过程中的操作依赖于同一渲染过程中较早的子过程中的操作结果时,我们需要指定子过程依赖性。 如果渲染过程中记录的操作与之前执行的操作之间存在依赖关系,或者在渲染过程之后执行的操作与渲染过程中执行的操作之间存在依赖关系,则也需要这样做。 也可以在单个子过程中定义依赖关系。

提示:定义子过程依赖关系与设置内存屏障类似。

怎么做...

创建一个类型为std::vector<VkSubpassDependency>的变量,命名为subpass_dependencies。 subpass_dependencies中设置每个依赖项为其成员使用以下值:
  ·在srcsubass的第二组(“消费”)操作(或渲染过程之前的命令的VK_SUBPASS_EXTERNAL值)之前完成(“生产”)操作的子类的索引。
  ·dstSubpass为子操作的索引,其操作取决于前一组命令(或渲染过程后操作的VK_SUBPASS_EXTERNAL值)
  ·srcStageMask为生成“消费”命令读取的结果的管道阶段集
   ·dstStageMask是一组依赖于“生产”命令生成的数据的管道阶段。
   · srcAccessMask为“生产”命令发生的内存操作类型
   ·dstAccessMask为将在“消费”命令中执行的内存操作类型
    ·对于dependencyFlags,如果依赖项由region定义,则使用VK_DEPENDENCY_BY_REGION_BIT值 - 这意味着在执行从同一区域读取数据的操作之前,必须完成为给定内存区域生成数据的操作; 如果未指定此标志,则依赖项为全局,这意味着必须在执行“消费”命令之前生成整个映像的数据。

这个怎么运作...

指定子过程之间(或渲染过程之前或之后的子过程和命令之间)的依赖关系与设置图像存储器屏障非常相似,并且具有类似的用途。 当我们想要指定来自一个子过程(或渲染过程之后的命令)的命令取决于在另一个子过程中执行的操作的结果(或在渲染过程之前执行的命令)时,我们不需要为布局转换设置依赖关系 - 这些依赖关系是根据为渲染过程附件和子过程描述提供的信息自动执行的。 更重要的是,当我们为不同的子过程指定不同的附件布局时,但在两个子过程中,给定的附件仅用于读取,我们也不需要指定依赖项。

当我们想要在渲染过程中设置图像内存障碍时,还需要子过程依赖性。 如果没有指定所谓的“自我依赖”(源和目标子过程具有相同的索引),我们就不能这样做。 但是,如果我们为给定的子过程定义这样的依赖关系,可以在其中记录一个内存屏障。 在其他情况下,源子过程索引必须低于目标子过程索引(不包括VK_SUBPASS_EXTERNAL值)。

接下来是一个例子,我们在两个子过程之间准备一个依赖关系 - 第一个将几何绘制成颜色和深度附件,第二个使用颜色数据进行后处理(它从颜色附件中读取):

std::vector<VkSubpassDependency> subpass_dependencies
  { 
    0, 
    1, 
    VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, 
    VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, 
    VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT, 
    VK_ACCESS_INPUT_ATTACHMENT_READ_BIT, 
    VK_DEPENDENCY_BY_REGION_BIT 
  } 
};

在第一和第二子过程(具有值0和1的索引)之间设置上述依赖性。 写入颜色附件在COLOR_ATTACHMENT_OUTPUT阶段执行。 后处理在fragment shader中完成,此阶段被定义为“消费”阶段。 当我们绘制几何图形时,执行对颜色附件的写入(具有COLOR_ATTACHMENT_WRITE值的访问掩码)。 然后将颜色附件用作输入附件,并在后处理子过程中从中读取(因此我们使用值为INPUT_ATTACHMENT_READ的访问掩码)。 由于我们不需要从图像的其他部分读取数据,我们可以通过区域指定依赖性(片段在第一个子过程中的给定坐标处存储颜色值,并且在下一个子过程相同坐标中通过片段读取相同的值)。 当我们这样做时,我们不应该假设区域大于单个像素,因为区域的大小在各种硬件平台上可能是不同的。

Computer graphics have a very long and interesting history. Many APIs or custom approaches to the generation of 2D or 3D images have come and gone. A landmark in this history was the invention of OpenGL, one of the first graphics libraries, which allowed us to create real-time, high-performance 3D graphics, and which was available for everyone on multiple operating systems. It is still developed and widely used even today. And this year we can celebrate its 25th birthday! But many things have changed since OpenGL was created. The graphics hardware industry is evolving very quickly. And recently, to accommodate these changes, a new approach to 3D graphics rendering was presented. It took the form of a low-level access to the graphics hardware. OpenGL was designed as a high-level API, which allows users to easily render images on screen. But this high-level approach, convenient for users, is difficult for graphics drivers to handle. This is one of the main reasons for restricting the hardware to show its full potential. The new approach tries to overcome these struggles–it gives users much more control over the hardware, but also many more responsibilities. This way application developers can release the full potential of the graphics hardware, because the drivers no longer block them. Low-level access allows drivers to be much smaller, much thinner. But these benefits come at the expense of much more work that needs to done by the developers. The first evangelist of the new approach to graphics rendering was a Mantle API designed by AMD. When it proved that low-level access can give considerable performance benefits, other companies started working on their own graphics libraries. One of the most notable representatives of the new trend were Metal API, designed by Apple, and DirectX 12, developed by Microsoft. But all of the above libraries were developed with specific operating systems and/or hardware in mind. There was no open and multiplatform standard such as OpenGL. Until last year. Year 2016 saw the release of the Vulkan API, developed by Khronos consortium, which maintains the OpenGL library. Vulkan also represents the new approach, a low-level access to the graphics hardware, but unlike the other libraries it is available for everyone on multiple operating systems and hardware platforms–from high-performance desktop computers with Windows or Linux operating systems, to mobile devices with Android OS. And as it is still being very new, there are few resources teaching developers how to use it. This book tries to fill this gap.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值