OptiX资料学习笔记1——简介

OptiX资料学习笔记1——简介

OptiX引擎的现状

目前有三种开源的API支持NVIDIA的光线追踪功能，分别为：

• DirectX Raytracing (DXR) DX的光线追踪API
• Vulkan (VK_NV_ray_tracing extension) Vulkan的光线追踪拓展API
• NVIDIA OptiX 最后的便是NVIDIA的OptiX引擎的API
  NVIDIA OptiX支持NVIDIA的CUDA技术，来实现光线追踪功能。

OptiX引擎7.0.0

• NVIDIA OptiX 7 API在抽象级别和功能方面类似于DXR。但是，NVIDIA OptiX 7增加了对运动模糊和多级变换的支持，这些功能都是以生产级渲染/高质量的渲染为目标的光线追踪应用所需要的。
• NVIDIA OptiX 7包含用于构建加速结构和编译执行光线跟踪操作的程序网络的功能。它采用了与DXR，Vulkan和最新版本的NVIDIA OptiX相同的编程模型，包括射线相交，Any Hit和Closest Hit等。现在几乎所有的光线追踪框架都脱离了传统的fragment shader、vertex shader这种与GPU的交互模式。
• NVIDIA OptiX 7 API以NVIDIA的CUDA为核心，API的设计的原则为无状态(我的理解是在使用optix的api时，需要将需要到的各种数据及各种一并传递到引擎中去，不知道这样理解对不对，如果不对还请大家提出)，多线程(CUDA就是用来多线程并行计算加速)，异步(个人理解这里应该是cpu和GPU中的计算是不同步的，也可能是optix的内核的运行和CUDA的内核是不同步的)和显式控制(这里也是CUDA的特性，指的是在我们对显存进行控制的时候，是直接指定的一些东西来控制的，比如block的数量，显存的大小啥的)。支持场景的轻量化，用户可以使用内置的三角形或者用户自定义的基元。同时也支持NVIDIA的AI去噪和神经网络。
• 一个NVIDIA OptiX 上下文控制一个GPU(这里说的a single GPU究竟是调用整个GPU还是一部分的GPU性能还不是很清楚)，但是不控制CPU的分配，但是类似CUDA,它可以创建少量的handle去控制在设备上分配和调用启动时所需要的的资源，当上下文被销毁时，这个handle也会被释放。（tips：这些handle对象会占用主机的内存，它们会消耗少量的主机内存（通常十几mb）,并且跟占用的GPU资源的大小没有关系）
• 大部分的NVIDIA OptiX 7都是线程安全的。除了一些用于记录的特殊API函数。
• 同时NVIDIA OptiX 7编程模型提供了一个面向未来的应用程序API：随着NVIDIA新硬件功能的发布，现有程序可以使用它们。 例如，当添加支持时，可以将基于软件的光线跟踪算法映射到硬件，或者当基础算法或硬件支持这种更改时，可以将基于软件的光线跟踪算法映射到软件。（最后一段机翻的，懒得看了，NVIDIA吹牛逼的一段）

程序创建的注意事项

• 该应用程序使用Acceleration Structure构建、编译并使用HOST/DEVICE进行内存传输。
• 在可能的情况下，所有的API函数都必须使用CUDA流，(为了性能，即便是20系显卡，对于实时的光追也比较吃力)并异步调用GPU函数。如果使用多个流，则应该确保CUDA事件要满足所需要的的依赖关系，避免在GPU上出现竞争的情况。（tips：有一些小的特殊情况。）
• 程序开发人员也可以通过一些方法去创建multi-GPU功能，例如负载均衡和通过NVLINK共享GPU内存等。为了效率和一致性，与CUDA内核不同，NVIDIA OptiX运行时允许在任何时间点将一项任务（例如单条射线）的执行移动到不同的通道/线程，像扭曲或streaming multiprocessor（SM）等。 因此，应用程序不能在提供给OptiX的程序中使用共享内存，同步，Barriers或其他的sm特殊线程。

看法

• 图形学中最重要的就是GI，而光线追踪应该是目前最好事先实时GI的路了吧，但是从实际的开发来看，尤其的7的api设计的挺无语的，可能以后会有改进吧，主要是把很多应该分开的东西合在一起了，比如官方写的examples中的scene中还带着管线和shader的创建，就很离谱。这些东西本来都是应该以其他的方式分离开的，还有为了性能几乎把所有数据都存在显存里了，加重了开发成本。不会cuda看个代码都云里雾里的，总的来说目前还是个半成品，硬件性能也跟不上。