Vulkan Cookbook 第六章 1 指定附件描述

指定附件描述

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

渲染过程表示一组成为附件的资源(图像),在渲染操作期间使用这些附件。它们分为颜色、深度/模板,输入或解析附件。在我们创建渲染过程之前,需要描述其中使用的所有附件。

怎么做...

  1. 创建一个名为attachments_descriptions的vkattachmentDescription类型元素的向量。为渲染过程中使用的每个附件向vkattachmentDescription向量添加一个元素,并为其成员使用以下只:
    ·flags为0
    ·format为给定附件的选定格式
    ·samples为每像素采样数
    ·对于loadOp,请指定在开始渲染过程时应对附件内容执行的操作类型,如果应清除附件内容,则为VK_ATTACHMENT_LOAD_OP_CLEAR值;如果应保留其当前内容,则为VK_ATTACHMENT_LOAD_OP_LOAD值;如果我们打算自己覆盖整个附件并且我们不关心其当前内容(此参数用于颜色附件或深度/模板附件的深度方面),则应保留其当前内容或VK_ATTACHMENT_LOAD_OP_DONT_CARE值。
    ·对于storeOp,指定渲染过程后如何处理附件的内容,如果应保留它们,则使用VK_ATTACHMENT_STORE_OP_STORE值;如果在渲染后不需要内容,则使用VK_ATTACHMENT_STORE_OP_DONT_CARE值(此参数用于颜色附件或 深度/模板附件的深度方面)
    ·指定如何在stencilLoadOp的渲染过程开始时处理附件模板方向(组件)(与loadOp成员相同,但只是对于深度/模板附件的模板方面)
    ·指定在stencilStoreOp的渲染过程以后应如何处理附件的模板方面(组件)(与storeOp成员相同,但只是对于深度/模板附件的模板方面)
    ·initialLayout为开始渲染过程时将使用的图像布局
    ·finalLayout为渲染过程后图像应自动转换到的布局

这个怎么运作...

当我们创建渲染过程时,必须创建一个附件描述数组,这是渲染过程中使用的所有附件的一般列表。然后将此数组中的索引用于子过程描述(请参阅指定子过程描述内容)。类似地,当我们创建一个缓冲区并准确指定每个附件应该使用哪个图像资源时,需要定义一个列表,其中每个元素对应于描述数组的元素。

通常,当我们绘制几何体时,我们将其渲染为至少一个颜色附件。也许我们还希望启用深度测试,因此也需要深度附件。此处介绍了此类常见方案的附件说明:

std::vector<VkAttachmentDescription> attachments_descriptions = { 
  {
    0,
    VK_FORMAT_R8G8B8A8_UNORM, 
    VK_SAMPLE_COUNT_1_BIT, 
    VK_ATTACHMENT_LOAD_OP_CLEAR, 
    VK_ATTACHMENT_STORE_OP_STORE, 
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, 
    VK_ATTACHMENT_STORE_OP_DONT_CARE, 
    VK_IMAGE_LAYOUT_UNDEFINED, 
    VK_IMAGE_LAYOUT_PRESENT_SRC_KHR,
  }, 
  {
    0,
    VK_FORMAT_D16_UNORM,
    VK_SAMPLE_COUNT_1_BIT, 
    VK_ATTACHMENT_LOAD_OP_CLEAR, 
    VK_ATTACHMENT_STORE_OP_STORE, 
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, 
    VK_ATTACHMENT_STORE_OP_DONT_CARE, 
    VK_IMAGE_LAYOUT_UNDEFINED, 
    VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL,
  } 
};

在前面的示例中,我们指定了两个附件:一个带有R8G8B8A8_UNORM,另一个带有D16_UNORM格式。两个附件都应该在渲染过程开始时清除(类似于在帧的开头调用OpenGL的glClear()函数)。我们还希望在渲染过程完成时保留第一个附件的内容,但不需要第二个附件的内容。对于两者,还指定了UNDEFINED初始布局。UNDEFINED布局始终可用于初始/旧布局,着意味着在设置内存屏障时我们不需要图像内容。

最终布局的值取决于我们打算在渲染过程后使用图像的方式。如果直接渲染到交换链图像中并且我们想要在屏幕上显示它,应该使用PRESENT_SRC布局(如前所示)。对于深度附件,如果我们不打算在渲染过程之后使用深度组建(通常为真),应该设置为渲染过程的最后一个子过程中指定的布局值相同的布局值。

渲染过程也可能不适用任何附件。在这种情况下,我们不需要指定附件描述,但这种情况很少见。

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、付费专栏及课程。

余额充值