雨果·巴拉:行业北极星Vision Pro过度设计不适合产品市场

研发实战:如何在Oculus Mobile VR平台进行Vulkan开发

查看引用/信息源请点击:映维网

Oculus正在大力推广Vulkan的采用

映维网 2019年08月09日)移动VR从一开始就将OpenGL ES作为图形API,但现在大多数引擎都开始转向Vulkan和DX12等API,因为它们为开发者提供了更大的灵活性和更低的渲染负载。Oculus日前介绍了GL和Vulkan在开发VR游戏功能方面的差异。需要注意的是,本文深入介绍了与图形相关的细节,读者需要掌握GL和Vulkan的基本知识。下面是映维网的具体整理:

由于Adreno图形驱动和Oculus运行时方面的改动,下面介绍的大多数功能都需要新发布的Build 7.0版本。

1. 多重采样抗锯齿(Multi-sampling Anti-aliasing;MSAA)

与PC显卡不同,移动芯片集的MSAA是由Tiler执行MASS操作,然后当Tile完成时进行解析(将所有子样本平均到最终像素),再将其结果存储到主存储器。由于从Tile内存到一般内存的带宽是非MSAA,这允许我们以接近与非MSAA相同的速度运行MSAA帧缓冲器。这对VR非常重要,因为每个眼睛的像素非常低,会产生明显的边缘锯齿。

对于GLES,这是通过使用MSAA帧缓冲区将其渲染到非MSAA纹理来完成。MSAA帧缓冲区使用以下函数进行初始化:glFramebufferTextureMultisampleMultiviewOVR

尽管有效,但由于其隐式性质,这引起了一系列的问题,例如“我不认为我的系统支持MSAA,我的纹理只是RGBA8888,我如何启用MSAA”。

在Vulkan中,由于一切都为显式。每个子通道由包含pColorAttachments,pDepthStencilAttachment和pResolveAttachments的vkSubpassDescription结构定义。一个优秀的Vulkan应用程序应该通过附着4x MSAA缓冲区来设置MSAA,并将其用于颜色/深度附件中的颜色和深度,以及pResolveAttachment中的非MSAA颜色缓冲区。应用程序同时应该将pColorAttachments和pDepthStencilAttachments storeOperations设置为VK_ATTACHMENT_STORE_OP_DONT_CARE。这将告诉驱动:“我以后不会要求这种颜色或深度,请不要将它们存储在Tile内存中并丢弃它们”。

加分项是,MSAA颜色和深度缓冲区应该设置为瞬态,并且系统会慢吞吞地分配它们的内存,因为所述缓冲区甚至没有内存(唯一的是pResolveAttachment中的颜色解析附件)。下面是一个优秀的管道状态示例:

使用这一路径(通过renderpass/subpass系统进行MSAA处理)而非vkCmdResolveImage路径非常重要。vkCmdResolveImage路径是一个以PC为中心的API,它不会利用Tiler在存储期间解析的能力,所以通过vkCmdResolveImage命令执行MSAA的引擎会将4x MSAA数据存储在内存中,再次从内存加载到Tiler ,然后将非MSAA解析回内存。这很容易就会给GPU添加3ms。

2. 多视图(Multiviw)

每次提交时,Multiview这个扩展允许GPU驱动程序在纹理数组的N个不同的切片(slice)执行N次绘制调用。它在VR中通过单次绘制调用来在2-deep纹理阵列绘制左眼和右眼。Vulkan通过VK_KHR_Multiview扩展提供支持。它需要颜色,深度和解析图像为2D Array而非2D,并且需要将VkRenderPassMultiviewCreateInfo结构添加到要通过Multiview执行的渲染通道。它(在UE4.23进行了测试)支持多个子通道。renderdoc管道状态图片(与上面相同)展示了具有2个视图的多视图捕获(一个用于左眼,一个用于右眼)。

VkRenderPassMultiviewCreateInfo有一个pViewMasks参数,其要求对多视图的视图数进行按位掩码。对于viewMask[0]值为0b11,双视图系统要求bit0和bit1为真。

我们的运行时本身支持纹理数组作为时间扭曲合成的输入纹理。开发者应该使用VRAPI_TEXTURE_TYPE_2D_ARRAY枚举创建纹理,而非渲染到多视图缓冲区,然后再手动将它们复制到非多视图图像并发送到VRAPI(计算要求非常高)。

3. 固定注视点渲染(Fixed Foveated Rendering;FFR)

从开发者的角度来看,由于两个FFR API之间存在较大的架构差异,所以GL和Vulkan之间的FFR非常不同。从概念上讲,FFR是一种应用于帧缓冲区的渲染设置,因为它会修改GPU计算帧的方式,同时不会以任何方式影响纹理(无论发生什么,颜色和深度纹理中的所有纹素都会被填充)。

实际上,来自QCOM的原始FFR扩展应该通过glFramebufferFoveationConfigQCOM函数应用于帧缓冲区,而老实说它应该存在于API中。但对于Oculus Go,我们希望在无需深入的引擎/应用改动的情形下引入这项功能。更重要的是,我们希望运行时控制应用的注视点设置,这样我们就不需要每位开发者和引擎来控制FFR设置,并且整个平台上都会具有同类设置。所以,我们要求QCOM在颜色纹理中存储FFR元数据(由我们控制,因为运行时分配纹理而非帧缓冲区),因此诞生了glTextureFoveationParametersQCOM。从开发者的角度来看,这个实现在很大程度上是隐藏在运行时中。开发者请求FFR级别(关闭/低/中/高),而我们自动为他们配置更低的级别。

尽管这个解决方案为Go和Quest带来了相当大的帮助,但它却面临着多重挑战。首先,因为它是基于VRAPI修改颜色纹理元数据,所以每个预通道(不会渲染到颜色纹理中)都不是根据注视点进行。现在没有太大问题,因为我们的大多数应用程序都是单通道,但情况总是会发生改变,因为开发者希望启用(例如)HDR管道。其次,QCOM有一个硬编码的注视点功能模型,它不允许我们根据视场和透镜来选择我们真正想要的分辨率曲线。

通过引入VK_EXT_fragment_density_map扩展,Vulkan完全修复了这个问题。需要注视点渲染的应用程序渲染通道不是采用硬编码方程式,而是添加另一个图像附件。它不是写入附件,而是读取附件。这个附件是一个R8G8像素密度图像,与普通附件相比(1216×1344渲染通道将具有38×42片段密度附件),其分辨率为/32并驱动应该渲染的帧缓冲区域的分辨率。

下面是一个片段密度图像示例。黄色区域是我们1:1的高分辨率区域,离屏幕中心越来越远,像素密度将越来越小。

尽管上图纹理有一种注视点的形状,但这种纹理可以是你想要的形状。例如,如果开放世界游戏的开发者不太愿意花费太多时间,他们完全可以减少天空的有效分辨率。对于以方程式为中心的GL扩展,这是完全不可能的事情。纹理同时可以绑定到任何渲染通道,所以双通道HDR-LDR渲染器的开发者可以简单地绑定两个渲染通道中的纹理,并将FFR应用于两者。

考虑到我们还是希望维持VrDriver对注视点曲线的控制,但rendepass是完全由应用程序控制,所以我们最终采用了混合方法。当开发者创建交换链来从Vulkan中的Oculus运行时获取颜色纹理时,它会创建另一个交换链:注视点交换链,其中颜色交换链的索引0与注视点交换链的索引0匹配,依此类推。开发者可以通过新的vrapi_GetTextureSwapChainBufferFoveationVulkan函数请求注视点交换链图像,并且无需对其进行任何修改,只需将它们绑定到自己想要启用FFR的渲染通道即可。

当使用普通的FFR控制API时,我们的运行时将修改注视点交换链图像并生成一个注视点图像,其强度与开发者请求的设置相对应。上图示例是运行时为High注视点设置生成的注视点图像。如果引擎没有任何进一步的变化,图像将自动切换注视点曲线,下一个renderpass的执行将使用新的FFR设置,就像开发者使用OpenGLES的FFR扩展一样。

4. 工具

Vulkan的一大优势是它是PC和Mobile共享的图形API。最重要的是,它是一个无状态API,这意味着驱动程序不需要在命令之间存储基础状态。这极大地帮助了像RenderDoc这样的工具。它支持MSAA,Multiview,VK_EXT_fragment_density_map,并且自RenderDoc 1.4起就可以配合Oculus Quest一起使用。片段密度贴图纹理可以在RenderDoc中可视化,从而确保你获得自己想要的注视点图像,并且帧将包含注视点图像,所以你可以看到头显中的真实纹理输出。

5. 引擎

Oculus 4.22.2 release 1.39.0是我们建议用于Vulkan开发的首个UE4版本。它实现了MSAA,Multiviw,FFR,sRGB原生渲染和多个UE4-Vulkan漏洞修复。注意,要在GitHub中访问所述文件,你需要登录订阅账号,否则你将会看到404错误页面。

我们看到了相当不错的性能增益,一个SunTemple的开发版本在渲染线程上从16ms变成了13sm。另外,由于着色器是SPIRV预编译而非GLSL,加载速度有了显著的提升。

不仅只是速度,Vulkan优化的设计和固有的多线程处理允许我们实现GLES所无法支持的功能,如引擎内每帧定时器查询。stat unit中的GPU定时器数据现在已经可用,并由引擎生成的计时器查询驱动,不再是从运行时传回的平均数据,而且stat gpu为你提供逐渲染通道信息。Vulkan同时允许我们能够开始考虑未来的理论功能,如基于子通道的HDR,多线程着色器加载,简单的色调映射等等。

尽管我们发现这一版本和最新的Quest操作系统就Vulkan而言相当稳定,但对UE4-Vulkan-VR来说仍然是早期阶段,所以如果你遇到任何问题,请向我们报告反馈。

6. 示例

Oculus Mobile样本目录中的VrCubeWorld_Vulkan样本现在已经实现了所有这些功能,你可以进行参阅并从中获取灵感。

7. 总结

希望这篇文章能够为你当前的Vulkan图形开发工作带来帮助,或者如果你是原生开发者或UE4开发者,希望这篇文章可以鼓励你尝试使用Vulkan。除了允许你在PC和移动平台之间轻松共享代码之外,它同时可以令你的图形代码工作更清晰,更快速。

本文链接https://news.nweon.com/64773
转载须知:转载摘编需注明来源映维网并保留本文链接
素材版权:除额外说明,文章所用图片、视频均来自文章关联个人、企业实体等提供
QQ交流群苹果Vision  |  Meta Quest  |  微软HoloLens  |  AR/VR开发者  |  映维粉丝读者

您可能还喜欢...

资讯