到目前为止，我已经发现，已经从实现图形管线各个阶段的非常专业的循环系统转变为更通用的方法。这种转换已部分以可编程着色器的形式反映在3D API上。大多数晶体管似乎专用于执行实际着色器指令的大规模并行SIMD单元。
正确。基本上，由于较旧的GPU上的功能尺寸相对较大，有效实现基本照明，抗锯齿，纹理贴图，几何图形等内容的唯一方法是使用“固定功能”管线。他们为性能而牺牲了灵活性，因为它们没有足够的芯片密度，无法使用像当前GPU这样的更通用的大规模并行SIMD架构来实现它。
是现代的GPU（认为Nvidia Fermi），基本上是一组“愚蠢”的SIMD数组，这些数组从CPU和各种缓存中获取指令和数据，并且将图形管线映射到这些指令的所有实际逻辑都在图形驱动程序中发生？
某些事情仍在硬件中完成；其他不是。例如，ROP仍在最后阶段用于将像素数据推入VGA芯片组。注意我在这里使用“ VGA芯片组”作为通用术语，指的是将视频信号传输到显示器的机制，无论它在任何方面是否都是真正的“ VGA”。
总的来说，目前的GPU架构（如Nvidia Fermi和AMD Southern Islands）在很大程度上是大规模并行CPU，它们具有自定义指令集，并且每个“核心”都非常薄弱，但是一整个许多核心（有时几千个）。但是那里仍然有特定于图形的硬件：
硬件视频解码通常使用固定功能芯片来完成。当涉及DRM（数字限制管理）时，尤其如此。有时，“硬件”视频解码实际上意味着一组固件指导的指令，这些指令被用作SIMD核心的常规旧任务。真的要看
除了很少的特定于计算的Nvidia板（Tesla）外，几乎所有“通用SIMD” 图形卡都具有用于视频输出的完整硬件阵列。视频输出与渲染不同；固定功能输出元素包括LVDS / TMDS / HDMI / DisplayPort编解码器，HDCP，甚至音频处理（基本上是一个DSP），因为HDMI支持音频。
“图形内存”仍与GPU一起存储在板上，因此它们不必遍历闲聊和相对高延迟的PCIe总线来命中系统RAM，它比更昂贵的系统本身更慢且响应时间更长，更高质量，更快的图形内存（例如GDDR5），其容量比系统内存小，但速度更高。将内容存储在图形内存中并从那里检索到GPU或CPU的过程仍然几乎是固定功能操作。某些GPU拥有自己的“ IOMMU”类型，但是此内存管理单元与CPU不同（独立）。但是，对于最近集成到其处理器中的Intel GPU（Sandy和Ivy Bridge）而言，情况并非如此，内存架构几乎完全是“一致的” 系统内存）和图形内存中的读取对于CPU而言，价格与对GPU一样便宜。
还是在GPU的某处有一些控制单元，将传入的高级指令和数据流（编译的着色器程序，顶点数据和属性以及纹理）转换为实际的SIMD指令，并负责同步，内存分配等工作？
SIMD的“本机”语言几乎总是由软件中的驱动程序生成，而不是由GPU自身的固件生成。对于DirectX 9 / OpenGL 2.x级别的功能尤其如此。驱动程序最终会通过敲打某些寄存器并执行所需的PCIe箍，以便通过计算和/或渲染的批处理缓冲区发送，最终由驱动程序以高级语言（例如HLSL，GLSL或OpenGL ARB着色器汇编器）编写的着色器转换为GPU指令。命令。
诸如硬件细分（DirectX 11 / OpenGL 4.0）之类的东西又以固定功能的方式被推入硬件，类似于它们过去用于几乎所有事情的方式。这又是因为，性能限制再次要求执行这些计算的最有效方法是为其配备专用电路，而不是让固件或驱动程序对SIMD进行“编程”。
我怀疑现实是介于这两个极端之间，答案会相当冗长，并且基于很多猜测（某些GPU供应商有理由拒绝在其产品上发布任何文档，更不用说驱动程序了。源代码...），但朝着正确方向和有用资源的任何提示将不胜感激。
AMD和Intel公开发布了有关其最近GPU的非常强大的文档，以及用于Linux的完全可用的开源图形驱动程序（请参阅Mesa和Direct Rendering Manager项目）。如果您查看这些驱动程序中的某些代码，您会大笑，因为图形驱动程序编写者实际上必须在“软件”中实现诸如绘制各种形状或图案之类的几何图形（但是要使用硬件命令来提交实际的硬件的日常工作），因为不再存在GPU固件或固定功能的东西，无法在硬件中对其进行全面处理：）在新版本上支持OpenGL 1.x / 2.x所做的事情真是有趣硬件。
演变过程如下：
- 很久以前（在认为可以进行实时3D渲染之前）：对于非实时渲染，CPU上的光线跟踪是正常的。对于您在Windows早期版本中看到的简单图形，CPU足够快，可以绘制简单的形状（矩形，字体字符，阴影图案等），而无需固定功能的硬件，但是它不能绘制太复杂的东西。
- 很久以前（OpenGL 1.x）：几乎所有东西都由固态硬件实现；即使在基本操作中，“电气”固定功能也是常态
- 不久前（OpenGL 2.x）：已经开始向使GPU更具可编程性的过渡。使用了5年的硬件上的“片段着色器”（又名像素着色器）几乎可以像CPU一样执行任意计算，但是它受到体系结构的限制，该体系结构仍然非常适合于图形。因此，OpenCL / DirectCompute在此硬件上不可用。
- 最近（OpenGL 3.x）：到通用GPU的过渡已基本完成，但它们已针对包含批量提交的大量数据（例如线性代数）的工作负载进行了优化，而不是针对可在其上有效运行的CPU进行了优化。很小数据的长序列（依次为1 + 1、2 * 4、5 * 6等）可通过OpenCL，CUDA等获得通用计算，但硬件仍不是完整的“ SIMD协处理器”因为（a）您仍然必须锤击特定于硬件的寄存器才能使用GPU功能；（b）由于PCIe总线开销，从GPU VRAM读取非常慢（在当前体系结构上从GPU读取的优化不是很强）；（c）内存和缓存体系结构与CPU不协调；许多遗留的固定功能硬件仍然存在。
- 当前（OpenGL 4.x）：摆脱了许多传统的固定功能硬件。稍微改善了GPU读取延迟。IOMMU允许在VRAM和系统内存之间进行（翻译）硬件辅助的映射。还介绍了硬件细分，使固定功能的元素重新出现。
- 未来（HSA）：GPU基本上是协处理器。它几乎完全与CPU集成在一起，即使在PCIe总线上的专用GPU上，GPU和CPU之间的阻抗也很小（用于读/写）。完全一致的内存体系结构-“ mi memoria es su memoria”（我的内存就是您的内存）。用户空间程序可以从“ VRAM”中读取，就像它们从系统内存中读取时一样，没有驱动程序填充，并且硬件会处理它。您拥有用于少量数据处理的“串行”处理（执行此操作，然后执行该操作，然后执行此操作，然后执行该操作）的CPU，并使用GPU进行“并行”处理（在此庞大的数据集上执行此操作并将其除以（您认为合适）。GPU所在的板上可能仍然具有ROP，HDMI编解码器等，但这对于显示输出是必需的，