想象你是一位城市物流调度总管，手下的骑手们正站在一座巨型城市的配送中心门口。屏幕上的每一个像素，都像一位安坐家中的顾客，等待骑手把“光线”这份货物亲手送到。传统光栅化像平邮批量投递——骑手不等看清门牌，就往整片街区甩包裹，速度飞快，但玻璃幕墙的倒影、雨后路面的霓虹，这些细节全都送错了人家。光线追踪则像高精尖的“精准配送”：每位骑手从配送中心出发，沿着精确路线穿行大街小巷，与每栋楼（三角形）擦肩而过时都停下来确认一次门牌号。真实得无与伦比，但慢得离谱——过去软件渲染一帧画面，常常要等上几天。 NVIDIA RTX显卡的故事，就是给这支出色的配送队伍配了两件神器：RT Core（专属导航硬件）和 Tensor Core（AI调度大脑）。RT Core把最耗时的“光线撞楼”判定做成芯片里的硬电路，让骑手从“纸地图问路”升级为“GPS导航直达”；Tensor Core则用AI弥补光线采样不足留下的画面噪点，像经验丰富的老调度员，看一眼稀疏的送货记录就能脑补出整条街的轮廓。两件神器再加上BVH城市导航地图和DXR总调度系统，实时光线追踪终于从科幻概念变成了你显卡里每秒60帧的真实画面。

岗位关联

理解RTX硬件加速原理，能帮你从“调API”升级到“懂底层”，在图形渲染性能优化、实时光追方案选型时做出正确决策。

目录
  1. 可视化演示
  2. 光追核心原理
  3. 软件光追困境
  4. BVH加速结构
  5. RT Core硬件架构
  6. Tensor Core与AI降噪
  7. 软硬协同管线
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示光线追踪渲染流程、RT Core与SM协同架构及GPU架构演进对比，切换模式了解硬件加速原理。

本节配有交互动效（进入视口后自动加载，约 3KB）。

光线追踪渲染流程 射线发射：从相机发射光线穿过像素 BVH遍历：层次包围盒加速求交测试 Ray-Scene Intersection via BVH 每帧发射数千万条射线进行求交计算

光追核心原理

想象你是城市快递调度中心的总管。顾客下了一个“想看到玻璃窗反射的夕阳”的订单，这个订单要送到屏幕左上角的那位像素手里。配送路线怎么走？传统做法（光栅化）是：不管顾客在哪栋楼上，直接用一个模板把整栋楼“拍扁”到街道上——速度快，但玻璃窗反射、夕阳透过树叶的斑驳光影这些细节全都丢了。光线追踪不一样：每位骑手（光线）从配送中心（摄像机）出发，沿着精确方向在城市街道中穿行，每遇到一栋建筑（三角形）就停下来确认“这是不是我的目的地”。是，就把建筑的颜色、材质、光照信息原路送回；不是，就继续往下走。这就是光追能还原倒影、半影、全局光照的秘密——每个像素都在认认真真“送货上门”。

这个“沿途确认”的过程，在图形学里叫光线与三角形求交（Ray-Triangle Intersection）。渲染时我们关掉“上帝视角”，只从观察点发射光线，每条光线都对应最终图像里的一个像素。数学上，一条光线就是一条射线：

有了光线方程，下一步就是在场景中做求交——也就是配送员挨家挨户问路。每敲一次门，就是一次三角形求交测试。当整座城市有千万栋建筑时，问路的次数就成了天文数字。你这才明白：把配送做得真实（光线追踪）不难，做得快（实时）才是真正的难题。

R(t)=O+t D,t≥0\displaystyle R(t) = O + t\,D,\quad t \ge 0
光线的每一处位置，等于起点 O 加上方向 D 乘以距离 t。t ≥ 0 表示只计算前方的路，不回望起点。
  1. O（起点）光线的出发点，也就是摄像机镜头的位置，对应快递配送中心。
    O=(x0, y0, z0)\displaystyle O = (x_0,\, y_0,\, z_0)
  2. D（方向）光线朝哪个方向射出，决定了它会照到场景中的哪些三角形，对应骑手的配送路线。
    D=(xd, yd, zd)\displaystyle D = (x_d,\, y_d,\, z_d)
  3. t（距离参数）沿方向“走”的里程数，t 越大离起点越远。找到三角形后返回的 t 值就是命中距离。
    t=∥P−O∥\displaystyle t = \|P - O\|
  4. t ≥ 0（前向约束）光线是半条直线，只照射前方，不会回头看摄像机背后的物体。
    t∈[0, +∞)\displaystyle t \in [0,\, +\infty)

软件光追困境

继续我们的快递故事。假设你的公司接下了整座城市所有像素的订单：一张 1080p 图片有约 200 万个像素，每个像素至少派出一位骑手（光线）。如果每位骑手都要挨家挨户敲门问路——每敲一次门就是一次求交——而城市里有约 1000 万扇“门”（三角形），你算算总共有多少次敲门？这就是软件光追的致命伤：不是技术做不到，而是计算量实在太大。早年的《玩具总动员》用软件光追渲染一帧，服务器集群也要跑上几个小时，想达到每秒 60 帧简直是痴人说梦。

为了把问题说清楚，我们把总耗时写成一个公式：

用这个公式估算：200 万像素 × 2 条光线 × 1000 万三角形 × 50 纳秒 ≈ 23 天。也就是说，靠纯软件暴力求交，渲染一帧画面要将近一个月。难怪传统方案只能妥协：要么用光栅化换速度牺牲真实感，要么用离线渲染追求画质但等上数小时。光追想要实时，必须从硬件层面想出路。

Ttotal=Npixel×Nray×Ntri×Ttest\displaystyle T_{\text{total}} = N_{\text{pixel}} \times N_{\text{ray}} \times N_{\text{tri}} \times T_{\text{test}}
总耗时 = 像素数量 × 每像素光线数 × 场景三角形数量 × 单次求交耗时。这个公式是理解光追“慢”的钥匙。
  1. N_pixel（像素数）一张 1080p 图片约 200 万个像素，每个像素最终需要一个颜色。
    Npixel≈1920×1080=2.07×106\displaystyle N_{\text{pixel}} \approx 1920 \times 1080 = 2.07 \times 10^{6}
  2. N_ray（光线数）实时光追为了控制成本，每个像素通常只发 1～2 条光线。
    Nray≈1∼2\displaystyle N_{\text{ray}} \approx 1 \sim 2
  3. N_tri（三角形数）现代游戏场景动辄 500 万～2000 万个三角形。
    Ntri≈1×107\displaystyle N_{\text{tri}} \approx 1 \times 10^{7}
  4. T_test（单次求交耗时）在 CPU 上做一次完整的光线-三角形求交约需几十纳秒。
    Ttest≈20∼100 ns\displaystyle T_{\text{test}} \approx 20 \sim 100\ \text{ns}

BVH加速结构

配送要提速，第一件事不是换骑手，而是换导航地图。你给城市做了一套分级导航：先按环路划分大区（根盒子），再分成街道（子盒子），最后细化到门牌（叶子盒子）。骑手拿到导航仪，第一件事不是敲门，而是看这栋楼在不在自己配送的大区内——不在？整片区域直接跳过！这就是 BVH（Bounding Volume Hierarchy，层次包围盒）的核心思想：用一层层越来越小的盒子框住三角形，让光线沿盒子层级快速下潜，而不是遍历所有三角形。

BVH 把“遍历全部三角形”变成“在树中查找”。每一层先做包围盒求交——一个几纳秒就能完成的简单运算；如果光线连盒子都没碰到，盒子里的成千上万个三角形直接就“免检”了。复杂度从暴力法的 O(N) 降到了 O(log N)：

BVH 不是免费的：离线构建场景树要额外时间，动态物体每帧更新也有开销。不过对静态或半静态场景，构建一次可以复用很多帧——就像城市导航地图，测绘一次能用很久。这张“导航地图”的存在，正是接下来 RT Core 硬件加速的基石：地图画好了，还需要一台硬件级的导航仪来快速查图。

S=Nlog⁡2N\displaystyle S = \frac{N}{\log_2 N}
N 是场景三角形数量，S 是理想加速比。当 N=1000 时 S≈100 倍；当 N=100 万时 S≈5 万倍（理想情况）。
  1. N（三角形总数）场景中所有三角形的个数，对应城市所有楼栋的数量。
    N=106\displaystyle N = 10^{6}
  2. log₂N（层级查找次数）BVH 遍历一次最多访问的节点数量，对应导航“先大区后门牌”的跳转次数。
    log⁡2106≈20\displaystyle \log_2 10^{6} \approx 20
  3. S（加速比）暴力穷举次数与 BVH 层级查找次数的比值，S 越大加速越明显。
    S=10620=5×104\displaystyle S = \frac{10^{6}}{20} = 5 \times 10^{4}

RT Core硬件架构

有了导航地图（BVH），还要给每位骑手配一台导航仪。NVIDIA 从 Turing 架构开始在 GPU 中加入了专门的光线追踪硬件单元——RT Core。它把“检查盒子是否相交”和“计算光线与三角形交点”这两个高频操作做成了芯片里的硬电路，像加法器一样即插即用。骑手不再需要掏出纸笔慢慢算，导航仪一秒钟能完成数十亿次求交判断。这也是"RTX"这个名字的由来：Ray Tracing 的硬件原生支持。

RT Core 判断一个三角形是否被光线命中，核心用到的数学是重心坐标。假设三角形三个顶点是 P0、P1、P2，光线在某个点 P 撞上了三角形所在的平面，那么 P 能不能写成三个顶点的加权平均，且所有权重都不为负？如果能，就说明 P 在三角形内部，光线真真切切打中了这个三角形：

RT Core 把这些计算做成了高度并行的流水线，一个时钟周期可以同时处理多个盒子和三角形的判定。更重要的是，它还和旁边的 SM（流式多处理器）紧密协作：RT Core 负责“这单货在哪”，SM 负责“这单货长什么样”——材质、光照、纹理都在 SM 里计算。分工明确，各司其职。

P⃗=w0P⃗0+w1P⃗1+w2P⃗2,w0+w1+w2=1,wi≥0\displaystyle \vec{P} = w_0 \vec{P}_0 + w_1 \vec{P}_1 + w_2 \vec{P}_2,\quad w_0 + w_1 + w_2 = 1,\quad w_i \ge 0
重心坐标公式：三角形内任意一点，都能由三个顶点按比例合成，所有比例非负。就像“这件货由 A 仓库出 30%、B 仓库出 50%、C 仓库出 20%”——总比例是 100%，而且没有哪家出“负货”。
  1. P0、P1、P2（三角形顶点）场景中一个三角形的三个角点坐标，对应一栋建筑的三个定位柱。
    P⃗0=(x0,y0,z0), P⃗1=(x1,y1,z1), P⃗2=(x2,y2,z2)\displaystyle \vec{P}_0=(x_0,y_0,z_0),\ \vec{P}_1=(x_1,y_1,z_1),\ \vec{P}_2=(x_2,y_2,z_2)
  2. w0、w1、w2（重心权重）三个顶点对命中点的贡献比例，类似三种原料在配方中的占比。
    w0+w1+w2=1\displaystyle w_0 + w_1 + w_2 = 1
  3. w_i ≥ 0（内部约束）三个权重都非负，命中点才在三角形内部；只要有一个权重为负，点就在三角形外面。
    wi≥0  ⟺  P⃗∈△P0P1P2\displaystyle w_i \ge 0 \iff \vec{P} \in \triangle P_0P_1P_2
  4. t（命中距离）求得重心坐标后，进一步得到命中点沿光线的距离 t，供着色器判断哪个命中点最近。
    t=(O⃗−P⃗0)⋅n⃗D⃗⋅n⃗\displaystyle t = \frac{(\vec{O}-\vec{P}_0)\cdot\vec{n}}{\vec{D}\cdot\vec{n}}

Tensor Core与AI降噪

实时光追还剩最后一个拦路虎：采样不足。为了跑满 60 帧，每个像素通常只能发 1～2 条光线，好比配送虽然有了 GPS 导航，但很多小区只派了一位骑手，拍回的照片（采样）稀稀拉拉，画面出现大量噪点——像老式电视的雪花。这就是蒙特卡洛采样噪声：光线越少，噪声越明显。怎么办？NVIDIA 请出了第二位神器：Tensor Core。

Tensor Core 是 GPU 上的 AI 矩阵运算单元，最初为深度学习矩阵乘法设计，在光追管线里它专门负责降噪。它用训练好的神经网络，把“稀疏采样 + 随机噪点”的画面补全成干净图像。数学上可以理解为一个加权平均过程：每个像素的新颜色，由周围相似像素的颜色按“相似度”加权平均而来：

实际管线中，Tensor Core 降噪还会引入时域信息：把上一帧、上上帧的颜色缓存一起加权，让画面随时间稳定不发闪，这就是“时空联合滤波”。有了 AI 降噪，1～2 条光线的稀疏采样就能呈现出接近几十条光线的效果，画面终于可以实时可用了。

C^(x)=∑y∈Ω(x)w(x,y) C(y)∑y∈Ω(x)w(x,y)\displaystyle \hat{C}(x) = \frac{\sum_{y \in \Omega(x)} w(x,y)\, C(y)}{\sum_{y \in \Omega(x)} w(x,y)}
降噪公式：像素 x 的颜色，用其邻域 Ω 内像素 y 的颜色加权平均替代。权重 w 基于颜色、深度、法线等相似度计算——越相似的邻居权重越大，不相似的邻居几乎不影响。
  1. x 与 Ω(x)（目标像素与邻域)x 是当前要重建颜色的像素，Ω(x) 是以 x 为中心的一小块区域，比如 7×7 的窗口，对应“周边几条街的送货记录”。
    Ω(x)={y:∣yx−xx∣≤3, ∣yy−xy∣≤3}\displaystyle \Omega(x) = \{ y : |y_x - x_x| \le 3,\ |y_y - x_y| \le 3 \}
  2. w(x, y)（相似度权重）y 的颜色、深度与 x 越接近，权重越大；差异越大，权重趋近于 0，防止把不同物体的颜色“糊”在一起。
    w(x,y)=exp⁡(−∥C(x)−C(y)∥2σ2)\displaystyle w(x,y) = \exp\left(-\frac{\|C(x)-C(y)\|^2}{\sigma^2}\right)
  3. C(y)（采样颜色）邻域像素的原始颜色值，是配送记录里已有的真实数据。
    C(y)=(Ry, Gy, By)\displaystyle C(y) = (R_y,\, G_y,\, B_y)
  4. 归一化（除以权重和）分子是加权颜色总和，分母是权重总和，相除后得到归一化的重建颜色，保证亮度不偏不倚。
    C^(x)=∑yw(x,y) C(y)∑yw(x,y)\displaystyle \hat{C}(x) = \frac{\textstyle\sum_y w(x,y)\, C(y)}{\textstyle\sum_y w(x,y)}

软硬协同管线

现在把整个配送体系串起来看：城市导航地图（BVH）、骑手导航仪（RT Core）、AI 调度台（Tensor Core）和总调度系统（DXR API）如何协同？NVIDIA 通过 DirectX Raytracing（DXR）等接口把渲染流程标准化：先由 CPU 或 GPU 构建加速结构，然后光线的发射和求交交给 RT Core，命中后的着色计算回到 SM，最后 Tensor Core 对结果降噪输出到屏幕。每一步都有专门的“部门”负责，流水线像齿轮一样咬合。

实时渲染有一条铁律：帧预算。60 帧每秒意味着每帧只有约 16.67 毫秒的时间完成全部工作：

从纸地图问路到 GPS 导航，从全城加班到当日达，RTX 的实时光追是一场硬件与软件协同设计的系统工程。理解了这套框架，你再看游戏里那面逼真的玻璃幕墙、雨夜路面上流动的霓虹倒影，就知道每一个像素背后，都有一位“骑手”在硬件级导航下穿过城市千万个包围盒，精准命中那一个三角形。下一次深夜打游戏，不妨想象这个画面——不是光在跑，是整个城市的物流在跑。

16.67 ms=Ttrace+Tshade+Tdenoise\displaystyle 16.67\ \text{ms} = T_{\text{trace}} + T_{\text{shade}} + T_{\text{denoise}}
每秒 60 帧的帧预算：一帧只有 16.67 毫秒。RT Core 把 trace（求交）大幅压缩，Tensor Core 把 denoise（降噪）压缩，SM 负责中间的 shade（着色）——三者协同，预算才够用。
  1. 16.67 ms（帧预算）每秒 60 帧时分配给每帧的总时间，等于 1000 毫秒除以 60。
    1000 ms60≈16.67 ms\displaystyle \frac{1000\ \text{ms}}{60} \approx 16.67\ \text{ms}
  2. T_trace（求交时间）光线遍历 BVH 和三角形求交的总耗时，RT Core 将这部分打进硬件，从“天”压缩到“毫秒”。
    Ttrace=Nrays×tRT Core per ray\displaystyle T_{\text{trace}} = N_{\text{rays}} \times t_{\text{RT Core per ray}}
  3. T_shade（着色时间）SM 计算材质、光照、纹理的耗时，决定画面的“质感”。
    Tshade=Nhits×tshader\displaystyle T_{\text{shade}} = N_{\text{hits}} \times t_{\text{shader}}
  4. T_denoise（降噪时间）Tensor Core 运行 AI 网络重建画面的耗时，补全稀疏采样留下的盲区。
    Tdenoise=Npixels×tAI per pixel\displaystyle T_{\text{denoise}} = N_{\text{pixels}} \times t_{\text{AI per pixel}}

AI 应用场景

游戏引擎实时光追

阶段：实时渲染管线优化 / 硬件加速计算

解决的问题：传统光栅化无法处理动态反射、软阴影和全局光照；纯软件光追帧率只有个位数。RT Core 硬件求交加上 Tensor Core AI 降噪，让光追从“离线特效”变成“实时默认选项”。

具体案例：在《赛博朋克 2077》中开启光追模式后，湿漉漉街道上的霓虹灯倒影、车窗玻璃的反射都是实时计算的。每个像素发出 1～2 条光线，RT Core 完成 BVH 遍历与三角形求交，Tensor Core 运行降噪网络把稀疏采样补全成干净画面，最终以 60 帧流畅输出。

建筑与影视实时预览

阶段：交互式渲染 / 设计预览

解决的问题：离线渲染器一帧数小时，设计师调整一个灯光参数后无法即时看到效果，严重影响设计迭代节奏。

具体案例：建筑设计师在 Unreal Engine 中用 Lumen + RTX 实时预览：拖动太阳角度滑杆，RT Core 立刻更新远景阴影和天空光反弹，Tensor Core 保证预览画质干净无噪点，从“调完参数等半天”变成“所见即所得”。

离线渲染AI降噪加速

阶段：渲染后处理 / 降噪

解决的问题：电影级离线渲染的蒙特卡洛采样同样有噪点，传统降噪算法容易糊掉毛发、金属拉丝等高频细节。

具体案例：三维动画工作室用 OptiX 降噪器（基于 Tensor Core 的 AI 降噪）把单像素所需的采样数从数万降到数百，原来需要渲染一整夜的镜头，现在几小时就能出图，且细节保留度显著优于传统双边滤波。

Python 演示

python112 行
"""RT Core 思路演示: 暴力求交 vs BVH 包围盒剪枝"""def dot(a, b):    return a[0] * b[0] + a[1] * b[1] + a[2] * b[2]  def cross(a, b):    return (a[1] * b[2] - a[2] * b[1],            a[2] * b[0] - a[0] * b[2],            a[0] * b[1] - a[1] * b[0])  class AABB:    def __init__(self):        self.min = [1e9, 1e9, 1e9]        self.max = [-1e9, -1e9, -1e9]     def include(self, tri):        for p in (tri[0], tri[1], tri[2]):            for i in range(3):                self.min[i] = min(self.min[i], p[i])                self.max[i] = max(self.max[i], p[i])     def hit(self, o, d):        tmin, tmax = 0.0, 1e9        for i in range(3):            if abs(d[i]) < 1e-8:                if o[i] < self.min[i] or o[i] > self.max[i]:                    return False            else:                t1 = (self.min[i] - o[i]) / d[i]                t2 = (self.max[i] - o[i]) / d[i]                if t1 > t2:                    t1, t2 = t2, t1                tmin = max(tmin, t1)                tmax = min(tmax, t2)                if tmin > tmax:                    return False        return True  def intersect(o, d, tri):    e1 = tuple(tri[1][i] - tri[0][i] for i in range(3))    e2 = tuple(tri[2][i] - tri[0][i] for i in range(3))    p = cross(d, e2)    det = dot(e1, p)    if abs(det) < 1e-8:        return None    inv = 1.0 / det    tvec = tuple(o[i] - tri[0][i] for i in range(3))    u = dot(tvec, p) * inv    if u < 0.0 or u > 1.0:        return None    q = cross(tvec, e1)    v = dot(d, q) * inv    if v < 0.0 or u + v > 1.0:        return None    t = dot(e2, q) * inv    return t if t > 0.0 else None  def make_skyline(x0, n):    tris = []    for i in range(n):        h = 1.0 + (i % 3) * 0.7        z = -3.0 - (i % 4)        x = x0 + i * 1.0        tris.append(((x, 0, z), (x + 0.7, 0, z), (x + 0.35, h, z)))    return tris  def main():    left = make_skyline(-8.0, 8)   # 左城: 光线不会经过    right = make_skyline(0.5, 8)   # 右城: 光线会穿过    all_tris = left + right    o, d = (0, 0, 0), (1, 0, -1)   # 光线朝右前方射出     # 暴力法: 逐个测试全部三角形    brute_tests, best_t, best_i = 0, 1e9, -1    for i, tri in enumerate(all_tris):        brute_tests += 1        t = intersect(o, d, tri)        if t is not None and t < best_t:            best_t, best_i = t, i     # BVH 法: 根盒 -> 左右子盒 -> 盒内三角形    root, lb, rb = AABB(), AABB(), AABB()    for tri in all_tris:        root.include(tri)    for tri in left:        lb.include(tri)    for tri in right:        rb.include(tri)     bvh_tests, hit_t, hit_i = 0, 1e9, -1    if root.hit(o, d):        bvh_tests += 1        for box, tris in ((lb, left), (rb, right)):            bvh_tests += 1            if box.hit(o, d):                for i, tri in enumerate(tris):                    bvh_tests += 1                    t = intersect(o, d, tri)                    if t is not None and t < hit_t:                        hit_t, hit_i = t, i     print("暴力法: %d 次求交 -> 命中 #%d" % (brute_tests, best_i))    print("BVH 法: %d 次求交 -> 命中 #%d" % (bvh_tests, hit_i))    print("BVH 剪枝跳过了 %d 个不相关三角形, 这就是 rt core 硬件化的思想" % (len(left),))  if __name__ == "__main__":    main()
目的：用纯 Python 实现光线-三角形求交（Möller-Trumbore 算法）和 AABB 包围盒剪枝，对比暴力求交与 BVH 思路的测试次数差异，直观感受 RT Core 硬件加速背后的算法原理。
  1. r1 = (self.min[i] - o[i]) / d[i]计算光线在这一轴上进入盒子的参数 t，对应“找出骑手进入这条街的时间”。
  2. if tmin > tmax: return False只要有一个轴出现“离开早于进入”，光线就没穿过盒子，整批三角形免检。
  3. p = cross(d, e2)求光线方向与三角形一条边的叉积，为重心坐标求交做准备。
  4. if u < 0.0 or u > 1.0: return None重心坐标 u 超界，说明命中点不在三角形内，直接放弃。
  5. left = make_skyline(-8.0, 8)生成左侧 8 个三角形，模拟光线不会经过的“城市片区”。
  6. root, lb, rb = AABB(), AABB(), AABB()构建根盒与左右子盒，对应 BVH 的层级结构。
  7. if root.hit(o, d):先测根盒，只有根盒命中才继续向下遍历，这就是“先看大区再看门牌”。
  8. for box, tris in ((lb, left), (rb, right)):分别测试左右子盒，未命中的子盒整体跳过。

常见误区

误区我一直以为 RT Core 和 Tensor Core 是一回事，都是跑神经网络的，所谓“光线追踪硬件加速”就是靠 AI 芯片硬算出来的。

正解RT Core 是专用的光线求交硬件，负责 BVH 遍历、AABB 测试和三角形相交测试，不做通用矩阵运算；Tensor Core 才是跑 AI 矩阵运算的单元。在光追管线里，RT Core 负责“找到光线撞到了什么”，Tensor Core 负责“把稀疏采样用 AI 补全”。两者是 GPU 里不同的硬件单元，分工协作。

为何常见：RTX 名字里的“RT“和 Tensor Core 听起来都像”AI 加速”，加上 DLSS 的宣传深入人心，很容易把两种核心混为一谈。

误区开了光追，游戏画面就和现实一模一样了——光线无限次反弹、所有物理现象都精确模拟，每一个光子都被追踪。

正解实时光追是高度近似的工程方案。每个像素通常只有 1～2 条光线，递归反弹次数受限，间接光照大量依赖 AI 降噪“脑补”。真实感来自“有限光线的聪明猜测”，而不是对物理世界的完整模拟。离线渲染可以更接近物理，但代价是数小时一帧。

为何常见：游戏宣传片和影视幕后把光追描述得神乎其神，玩家容易把“更真实”误解为“完全真实”。

误区既然 RT Core 硬件加速那么快，BVH 肯定也免费——场景里物体随便动，硬件都能瞬间搞定。

正解BVH 构建本身就是一大笔开销。它需要先把场景三角形按空间位置组织成树，动态物体每帧变化时还要增量更新甚至重建。RT Core 加速的是“遍历 BVH 找交点”，而不是自动构建 BVH。这也是为什么实时光追会先用光栅化做基础遮挡，再用光追叠加特定效果——把 BVH 更新的成本控制住。

为何常见：硬件加速给人的错觉是“不需要再做软件优化了”，恰恰相反，BVH 的构建策略往往决定了光追性能的上下限。

误区既然 RT Core 这么强，以后所有渲染都该走光线追踪，传统光栅化直接淘汰算了。

正解RT Core 只加速求交环节，着色、材质计算仍然依赖 SM。更重要的是，混合渲染（光栅化 + 光追）才是当前效率最高的方案：先用光栅化快速得到基础画面，再用光追叠加反射、软阴影、全局光照这些光栅化做不好的部分。全场景光追在可预见的未来都不会成为唯一选择。

为何常见：把“硬件加速求交”误当成“硬件完成整个渲染”，忽略了光追管线里还有着色、降噪、后处理等多个环节。

面试题

Q1. RT Core 在 RTX 显卡中的核心职责是？

单选题 · easy

  • A.加速光线与三角形求交运算← 正确答案
  • B.替代 GPU 完成全部像素着色
  • C.专门生成深度学习网络权重
  • D.压缩渲染所需的纹理数据

答案：A。RT Core 是专用硬件求交单元，把 BVH 遍历和三角形相交测试硬件化。像素着色由 SM 负责，深度学习权重计算由 Tensor Core 负责，纹理压缩也不是 RT Core 的职责。

Q2. BVH 加速结构能显著提速的根本原因是？

单选题 · mid

  • A.减少光线需要测试的三角形数量← 正确答案
  • B.提高单个三角形求交的浮点精度
  • C.将三角形预转换成屏幕像素
  • D.自动降低场景中三角形数量

答案：A。BVH 通过层级包围盒做剪枝，光线先测盒子，盒子不命中则整棵子树跳过，把复杂度从 O(N) 降到 O(log N)。它不会提高单次求交精度，也不转换像素或减少三角形数量。

Q3. 光线方程 R(t)=O+tD 中，t 表示什么？

单选题 · mid

  • A.光线沿方向传播的距离参数← 正确答案
  • B.光线起点的颜色强度值
  • C.场景包围盒的层次数量
  • D.像素着色器的调用次数

答案：A。t 是光线从起点 O 出发、沿方向 D 传播的距离参数。t 越大离起点越远，找到交点时返回的 t 就是命中距离。颜色、包围盒层次、着色器调用都与 t 无关。

Q4. Tensor Core 在实时光追管线中的主要作用是？

单选题 · easy

  • A.AI 降噪重建稀疏采样画面← 正确答案
  • B.完全替代 RT Core 做求交
  • C.提高 BVH 树的构建速度
  • D.实时压缩每条光线数据

答案：A。Tensor Core 是 AI 矩阵运算单元，负责运行降噪网络把稀疏采样补全。求交是 RT Core 的工作，BVH 构建也不是 Tensor Core 的强项，光线数据压缩更不是它的职责。

Q5. 软件光追在渲染一帧时计算量爆炸的根本原因是？

单选题 · mid

  • A.每个像素要与海量三角形求交← 正确答案
  • B.显卡散热不佳导致核心降频
  • C.显示器刷新率太低
  • D.显存容量不足以缓冲帧

答案：A。软件光追中，每个像素发出的光线都要与场景中大量三角形做求交测试，计算量随场景复杂度线性爆炸。散热、刷新率、显存容量都不是计算量问题的根源。

Q6. 重心坐标判定“命中点在三角形内”的条件是？

单选题 · hard

  • A.u 和 v 均非负且 u 加 v 不超过 1← 正确答案
  • B.u 和 v 的乘积大于等于 1
  • C.求交距离 t 必须小于 0
  • D.三角形三个顶点全为正数

答案：A。重心坐标中，当 u ≥ 0、v ≥ 0 且 u + v ≤ 1 时，第三个权重 w = 1-u-v 也非负，三点加权平均落在三角形内部。u·v ≥ 1、t < 0、顶点坐标正负都与“内部”判定无关。

Q7. 实时光追降噪常用的辅助策略包括？

多选题 · mid

  • A.Tensor Core 执行 AI 重建← 正确答案
  • B.时域累积多帧信息← 正确答案
  • C.空间邻域像素加权← 正确答案
  • D.强制关闭全部光线反射

答案：ABC。AI 重建、时域累积、空间加权是实时光追降噪的三大支柱：用 AI 网络补全、融合历史帧信息、按空间相似度加权。关闭光线反射是牺牲效果而不是降噪策略。

Q8. RTX 光追软硬协同的关键组件包括？

多选题 · mid

  • A.DXR API 制定渲染规范← 正确答案
  • B.RT Core 提供硬件级求交← 正确答案
  • C.Tensor Core 负责 AI 降噪← 正确答案
  • D.使用 CPU 串行执行全部渲染

答案：ABC。DXR 是软件接口标准，RT Core 做硬件求交，Tensor Core 做 AI 降噪，三者协同构成 RTX 光追管线。用 CPU 串行渲染正是软件光追缓慢的旧路，不是 RTX 的解决方案。

Q9. 光线穿过 AABB 包围盒的条件是？

单选题 · hard

  • A.最近进入距离不超过最远离开距离← 正确答案
  • B.光线与盒子的最近距离大于 0
  • C.包围盒的中心位于光线前方
  • D.盒子体积与光线长度成正比

答案：A。slab 法分别计算光线在三个轴上进入盒子的 t 和离开盒子的 t，取最大进入距离 t_min 与最小离开距离 t_max。光线穿过盒子当且仅当 t_min ≤ t_max。中心位置和盒子体积都不决定相交关系。

Q10. 相比传统光栅化，光线追踪的优势体现在？

多选题 · mid

  • A.反射与折射效果更真实← 正确答案
  • B.全局光照过渡更自然← 正确答案
  • C.三角形数量自动减少
  • D.阴影可呈现半影软阴影← 正确答案

答案：ABD。光线追踪能逐像素追溯光线路径，反射折射、全局光照、软阴影都能物理正确地呈现。但光追不会自动减少三角形数量，场景建模仍需艺术家手工完成。