【发布时间】:2017-05-15 15:28:29
【问题描述】:
我阅读了一些关于如何在 opengl 4.3 计算着色器中实现光线追踪器的教程,这让我想起了困扰我一段时间的事情。 GPU 究竟是如何处理实现此类操作所需的大量随机访问读取的?每个流处理器都有自己的数据副本吗?似乎系统会因内存访问而变得非常拥挤,但这只是我自己的,可能是不正确的直觉。
【问题讨论】:
标签: opengl gpu compute-shader random-access
我阅读了一些关于如何在 opengl 4.3 计算着色器中实现光线追踪器的教程,这让我想起了困扰我一段时间的事情。 GPU 究竟是如何处理实现此类操作所需的大量随机访问读取的?每个流处理器都有自己的数据副本吗?似乎系统会因内存访问而变得非常拥挤,但这只是我自己的,可能是不正确的直觉。
【问题讨论】:
标签: opengl gpu compute-shader random-access
流式多处理器 (SM) 具有缓存,但它们相对较小,无助于真正的随机访问。
相反,GPU 正试图掩盖内存访问延迟:即每个 SM 分配的执行线程数多于其核心数。在每个空闲时钟上,它都会调度一些在内存访问中未被阻塞的线程。当某个线程所需的数据不在 SM 缓存中时,该线程会暂停直到该数据到达,让其他线程代替执行。
请注意,仅当计算量超过等待数据所花费的时间(例如,每像素照明计算)时,此屏蔽才有效。如果不是这种情况(例如,只是将大量 32 位浮点数相加),那么您可能会在内存总线带宽上遇到瓶颈,并且大多数情况下您的线程将停止等待它们的位到达。
可以帮助使用 SM 的相关事物是 数据局部性。当多个线程访问附近的内存位置时,一个缓存行获取将带来多个线程所需的数据。例如,在对透视扭曲三角形进行纹理处理时,即使每个片段的纹理坐标可以是“随机的”,但附近的片段仍然可能从纹理中读取附近的纹素。因此,线程之间共享了许多公共数据。
另一方面,光线追踪在数据本地化方面非常糟糕。二次射线往往发散很多,并在几乎随机的位置撞击不同的表面。这使得将 SM 架构用于光线场景交叉或着色目的变得非常困难。
【讨论】: