来源
在Nvidia的此网页中，作者似乎暗示您可以在单独的线程上为每只眼睛创建一个命令缓冲区。但是，与实例化立体声渲染相比，我看不出有什么好处，因为您还必须处理多个命令缓冲区的同步。 ），我在考虑何时为每只眼睛使用帧缓冲区，这是VR的一种“幼稚”的渲染方式。我想尽管您可以像立体实例渲染一样渲染到一个帧缓冲区。无论如何，我关注的同步问题是一只眼睛的完成速度比另一只眼睛快得多。似乎在立体实例渲染中，由于工作负载更易分割，因此不太可能发生这种情况。我看到的另一个问题是同步可能会导致性能下降，这是您必须等待两个线程完成发送各自的命令缓冲区后才能再次发送。可以说，这可能不是一个大问题，但是似乎还是不必要的。
空间局部性问题
似乎还因为没有一种方法可以保证对象何时通过管道而使您与实例化相比，可能会在GPU上获得更多的高速缓存未命中。
问题
与实例化立体声渲染相比，使用多个命令缓冲区进行立体声渲染有没有优势？

评论

“因为还必须处理多个命令缓冲区的同步”，您特别指的是什么同步？
我对问题进行了更具体的编辑。基本上，我关心的同步类型有两种，一种是帧缓冲，另一种是命令缓冲区提交/频率。

#1 楼

是的，有优势。您可以将不同的命令缓冲区呈现给不同的队列。

特别是现代NVIDIA硬件，提供了完整的16个独立的队列，能够呈现独立的图形操作。通过将每只眼睛放在一个单独的队列中，您可能能够更有效地使用可用的硬件资源。

然后，事实并非如此。这完全取决于在最低级别的硬件上如何工作。



无论如何，我关注的同步问题将是一只眼睛完成比另一只眼睛快得多。似乎在立体声实例渲染中，这种情况不太可能发生，因为工作负载更容易被整除。


它基本上不会在实例渲染中发生。但是您说这就像是一件好事。

如果一只眼睛恰好比另一只眼睛具有更高的场景复杂性，那么这意味着实例化立体渲染将浪费大量顶点的顶点处理。永远不会出现的“弱”眼睛。而如果分别构建命令缓冲区，则只会提交对两个场景都重要的内容。

如果将两个CB提交到同一队列中，则处理这些CB的总时间可能少于处理大型CB所花的时间，因为它没有计算出不会被剔除的三角形。如果将两个CB提交到不同的队列，则如何平衡将完全取决于硬件如何适应给定的工作负载。如果它可以很好地适应，那么您会没事的。

因此，在这种情况下，多CB设置可能表示对硬件资源的更有效利用。当然，这种情况很少见。

这种情况下的同步确实不是问题。如果一只眼睛相对于另一只眼睛而言如此复杂以至于您丢下一帧，那么使用哪种形式进行渲染都没关系。您要丢帧。

使用Vulkan，将完全独立的内容呈现到多个队列并不难。确实，您可能需要的唯一真正的同步就是同步交换链图像的呈现，这可以通过信号量轻松实现。


我看到的另一个问题是同步可能导致性能下降命中之处在于您必须等待两个线程完成发送各自的命令缓冲区后才能再次发送。


不，您不需要。如果要重用CB，则始终可以使用VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT，它可以提交已使用的CB。而且，如果您不重复使用CB（即，您的CB不是静态的），则无需在意；只是双缓冲您的命令池，以便您不尝试重置正在使用的CB。

后者是使用Vulkan渲染动态场景的通用标准方法。