opengl - glUseProgram() 在硬件级别如何工作？

Question

1. 我认为(我不确定)，每当我们调用 glUseProgram() 时，顶点着色器、碎片着色器、几何着色器等都会加载到 GPU 中相应类型处理器的程序内存中(例如顶点着色器 -> 顶点着色器)着色器处理器)。
   但我也对这种“加载”发生的速度感到惊讶。尽管具有复杂的渲染管道和多个着色器，游戏通常能够提供非常好的 FPS(1)，这意味着程序加载可能每秒发生数千次。
   我的想法正确吗？如果是，我真的低估了 GPU 的强大功能吗？
2. (与 (1) 相关的小问题)在哪里可以找到有关内部 GPU 总线带宽与性能(或 FPS)之间相关性的更多信息？
3. 另一个小问题)着色器是在客户端还是设备上编译的？
4. 编译后，着色器程序是否存储在 GPU 的(共享)内存中，或者处理器缓存是否足够大以容纳许多着色器？

Answer 1

are loaded in program memory of the respective type processors in the GPU

我非常确定编译的着色器与着色单元保持“足够接近”，以使加载本身非常高效。指令缓存包含必要的数据，并且很容易用 VRAM 中的数据重写它们。毕竟，不需要 CPU 同步，一切都完全在 GPU 内发生。

这里需要注意的重要一点是，现代 GPU 不再具有“各自类型的处理器”；他们实际上只使用可以运行各种计算的通用着色单元，包括但不限于片段和顶点着色。

Despite having a complex rendering pipeline and multiple shaders, games are often able to give very good FPS(1) which means program loading is probably happening thousands of times each second.

是的，现代游戏可以有数千个管道设置来绘制框架。 GPU速度很快。现代 OpenGL 使更多程序能够更轻松地使用单独的着色器对象扩展，这有助于使渲染更加模块化。

2. (Mini question related to (1)) Where can I find more information regarding correlation between internal GPU bus bandwidth vs performance(or FPS)?

这个问题太宽泛，无法回答，并且在很大程度上取决于工作量。 This is an interesting document不过，这可能会解答您的问题，并可能激发您进行进一步的研究。

总而言之，glUseProgram 本身通常在现代驱动程序上几乎不会做任何事情(就性能而言)。这是因为驱动程序使用一种惰性评估形式，并且只有在确定哪些绘制调用将使用它们时才真正提交状态更改。现在，驱动程序在优化不必要的调用、重新排序等方面的效率完全取决于实现。

3. Are shaders compiled on client or on device?

按照 OpenGL 的术语，它们是在服务器上编译的，但这并不一定意味着物理设备。通常，驱动程序的操作系统驻留部分负责执行着色器编译。

4. Post compilation, are shader programs stored in GPU's(shared) memory or are processor caches big enough to hold many shaders?

两者都有。程序存储在全局内存中，如果可能的话，存储在每个处理器的指令高速缓存中，该指令高速缓存为几千字节。这取决于着色器的大小和缓存的大小，但通常应该适合一些。缓存在运行时以 LRU 方式填充。