Meta早前发布了Application SpaceWarp（AppSW）。这是是一种面向开发者的优化技术，可以为合适的内容释放额外的计算能力。在Meta的初始测试中，AppSW为应用提供了高达70%的额外计算，而且几乎没有可感知的瑕疵。
尽管早前已经进行过一番介绍，但为了进一步帮助大家了解这项技术，Meta日前通过一篇博文解释了AppSW，并提供了相关的常见问题回答。下面是映维网的具体整理：
凭借AppSW提供的额外CPU/GPU性能，我们相信你可以将虚拟现实体验提升到一个全新的水平。现在随着V34操作系统和SDK的发布，所述功能已准备好供你使用。我们非常期待看到你在自己的应用中进行测试，并向大家分享你的经验。
1. 什么是AppSW？
Application SpaceWarp允许应用以实际显示刷新率的一半进行渲染，例如72fps的一半36fps。除了标准的眼睛缓冲区外，应用同时必须渲染运动矢量缓冲区和深度缓冲区，然后我们的系统将使用所述缓冲区合成新帧，并向显示器输出72 FPS。
2. 它能提供多少帮助？
当应用可以以显示速度的一半进行渲染时，它现在的计算预算几乎是以前的两倍。当然，AppSW存在自己的开销，运动矢量生成和帧合成都需要一定的时间。运动矢量生成增加了应用进程的GPU总成本，帧合成则增加了合成器的GPU总成本。
幸运的是，瑕不掩瑜。在对第一方应用的初始测试中，我们看到了计算预算增加了70%。
3. 它的工作原理？
要从旧帧合成新帧，我们需要知道每个给定像素的未来位置。一种方法是通过帧外推和帧重投影，借助于运动矢量数据和深度数据。运动矢量描述每个像素的移动速度，所以我们可以使用它来预测像素的未来位置。深度缓冲区可以告诉像素到渲染camera的距离，从而用于执行基于深度的重投影，以减少头显延迟。
生成运动矢量的方法有很多，但它们大多属于两大类：
- 通过分析历史帧执行运动估计
- 应用分析性渲染
AppSW正在使用第二种方法。生成的数据更可靠（基本是ground truth），并且可以实现比第一种方法高得多的分辨率。实际上，实时渲染行业已经广泛采用这种技术。如果你熟悉运动模糊或时间消除混叠等标准图形功能，其使用了与我们非常相似的方法来生成运动向量（或称为速度缓冲区）。所以，AppSW自然适合游戏引擎和3D渲染应用。
有关如何在代码中准确生成运动向量的详细信息，请参考我们的开发者指南（Unreal、Unity、Native）。下图显示了运动矢量和深度数据的实际情况。请注意，AppSW所需的运动矢量和深度数据的分辨率可能远低于彩色眼睛缓冲区，而这是运动矢量生成开销非常低的原因之一。
当XR应用以较低的帧速率渲染时，延迟是舒适体验的最大挑战之一，因为帧管道需要更长的时间，并且姿态预测变得不准确。为了减少使用AppSW时的延迟，我们使用了以下技术提供了完整的管道优化：
- Phase Sync：协调应用框架，并根据应用的工作负载使其在正确的时间启动。尽可能晚地执行头显和控制器传感器读取，以减少头显和控制器延迟。
- Late Latching：进一步将传感器读取时间延迟到CPU渲染帧结束，从而节省一帧延迟。
- Positional TimeWarp（PTW）：Asynchronous TimeWarp（ATW）可以在显示之前纠正头显旋转错误，这在每个Quest应用中都有启用。PTW可以使用深度缓冲区数据进一步纠正头显转换延迟，而这将由AppSW应用自动启用。从纯头显延迟的角度来看，我们甚至可以说AppSW应用在使用PTW时比没有AppSW的完整FPS应用具有更少的延迟。
从时间轴的角度来看，下图显示了每项技术在框架管道上的位置。
总的来说，AppSW不仅仅是帧合成，它是一组结合在一起的技术，并可提供最佳的半刷新率XR体验。
4. 限制和最佳实践
AppSW是一个非常强大的工具。但我们想明确的是，AppSW并不是什么灵丹妙药，可能不适合所有类型的应用。最终，开发者自己有责任决定如何以及何时使用这个工具，并彻底测试，以确认应用中没有图形故障或质量影响。
对于这个特定的主题，我们可以谈论很多，比如透明度渲染、运动矢量精度、控制器延迟或图像失真。最重要的是理解技术的基本理论，这不仅可以帮助你识别AppSW的潜在问题用法，而且可以帮助你找出解决方案。我们鼓励你参阅我们的开发者指南。
5. 完整开发包
V34操作系统和SDK版本提供了完整的AppSW开发包。以下是所包含的内容：
- Unity：Unity的AppSW支持托管在我们的github上。我们展示了一个关于如何将技术集成到应用程序中的参考实现。具体请访问这个页面。
- Unreal：我们在UE4.27-V34分支共享了一个复选框解决方案。具体请访问这个页面。
- Native：我们的AppSW扩展以官方OpenXR规范发布。为了在源代码级别更好地理解它，我们在SDK包中包含了一个源代码示例XrSpaceWarp。具体请访问这个页面。
- 工具：OVRMetrics Tool已更新至包含AppSW度量。
- 开发者教育：请参考我们的开发者指南（Unreal、Unity、Native）
- 讨论和同行支持：请前往开发者论坛。
6. 结论
如果使用得当，Application SpaceWarp是一个强大的功能，可以为应用提供显著的额外计算能力。除了在文档中提到的以外，你可能会遇到非常见的情况并对性能造成影响。你可以选择通过调整内容或寻找自己的解决办法。关键是要理解这项技术和应用的图形管道。
为大家带来AppSW只是旅程的开始。我们期待听到你的问题、反馈和bug报告。
7. 常见问题
AppSW和Rift ASW之间的区别是什么？
对于一直关注Oculus渲染功能的人而言，你可能相当熟悉PC ASW。这是一个专为Oculus Rift应用发布的功能。尽管存在相似之处，但我们想指出的是，PC ASW与Application Spacewarp是截然不同的技术。
PC ASW使用历史帧分析生成的运动矢量，而AppSW使用应用生成的运动矢量。由于应用具有关于对象运动的所有信息，所以运动向量不依赖于要生成的任何估计/猜测。这将允许AppSW使用更高质量的运动矢量，更接近“ground truth”运动矢量，从而提高整体视觉质量。
在功能类型级别，PC ASW是一种系统功能，并在低规格机器自动触发。Application SpaceWarp则是完全由开发者驱动的功能。开发者可以在开发/设计阶段管理功能的激活。更重要的是，开发者可以完全控制每一个运动矢量/深度，这为开发者的创新留下了大量的空间。
即使在使用PC ASW时，你的目标是帮助大多数最终用户以全帧速率运行，而ASW只是一种在需要时启动的功能。
PC ASW提供给你的额外计算能力不会经常能用到。AppSW可允许应用始终以半速率运行，而整个应用都有可能获得更高的计算预算。当然，这同时意味着任何AppSW伪影都将更加严重，因为它们将应用于所有用户，而不仅仅是一小部分用户。
我一定会得到70%的额外计算吗？
不一定总是这样，但理论上非常接近。AppSW的效率将受到一系列变量的影响，如场景复杂度、图形复杂度、目标帧速率、显示分辨率等。根据你的实际内容，性能的确切提升程度将有所不同。我们的“70%”数据来自于对内部UE4内容的测试。我们认为所述内容可以当成是一般内容的代表，但你的内容可能会得到不同的数字，大于或小于70%。
AppSW支持什么刷新率？
AppSW支持所有可用的刷新速率：Quest 1和Quest 2头显的72/90/120，相应的半速率AppSW应用渲染速率为36/45/60。确定目标刷新率是开发者自己的选择。
当以更高的刷新率为目标时，总体延迟会更好，AppSW的伪影同样更少。然而，由于AppSW的合成器开销固定，平均AppSW开销的百分比会更高。
例如，70%的额外计算数字是完整FPS 72 FPS应用 vs 36/72 AppSW应用的差异。
如果选择更高的刷新率，则性能提升将更小。例如，45/90 AppSW的性能提升会小于36/72，而60/120则甚至更少。
AppSW是否强制启用Late-Latching？
我们鼓励开发者启用Late-Latching以改善延迟，特别是控制器延迟。从Oculus github的UE4.23开始，UE4 Late-Latching就已经可用。另外，Unity Late-Latching处于实验特性阶段。为了避免增加Unity应用中的集成过程复杂度，我们建议首先确保AppSW在你的应用中正常工作，然后才启用Late-Latching。如果你看到任何bug，请告知我们知道。
AppSW是否必须使用OpenXR？
是的，我们只支持OpenXR下的AppSW，因为我们完全致力于支持OpenXR API的发展。例如，在Unity应用中，你依然可以使用Oculus XR插件，但要使用OpenXR后端。
AppSW是否需要Vulkan？
我们的UE4/Unity AppSW集成仅支持使用Vulkan+Multiview的应用。
从技术上讲，如果你是使用GLES的本地开发人员，AppSW依然可以正常工作，但支持Late-Latching需要Vulkan的内存模型，所以我们通常建议在Vulkan下使用AppSW。
AppSW是否属于“要么完整启用，要么完全禁用”的功能？
不是。你可以随时按每帧粒度启用AppSW。例如，在GitHub附带的简单Unity测试应用中，点击“B”按钮将在每帧打开/关闭AppSW。
所以，你不必为这个功能始终打开或关闭而感到压力。当然，在你的应用程序中，有些场景你可以打开的，有些场景你可以关闭。
文章来源：映维网
评论