本篇文章站在硬件角度来讲解PC上的图形渲染过程，整体的流程如所示：
图形应用App - 运行时接口SDK - 用户模式驱动（UMD）- 图形调度器 - 内核模式驱动（KMD）- 高速总线 - GPU命令处理器。
1、应用App
就是我们写的图形应用代码，比如绘制一个简单的红色三角形，通过MetalKit框架的API可以很快绘制出来，同时也是很多Bugs的来源之地。
2、运行时接口SDK
我们APP需要调用SDK来进行资源创建、状态设置、绘制调用等，比如苹果的MetalKit框架就是个典型框架，主要的职责包括：维护管线状态、参数检查、错误和连贯性检查、管理用户可见的资源（比如device， commandQueue等）、着色器代码检查和链接（OpenGL是在驱动层处理）。最后通过之后，把数据递交给显卡驱动（UMD）。
3、UMD - 用户模式驱动
用户模式驱动是跟应用运行在同一个上下文和地址空间内，主要指责包含：着色器编译（包括语法检查、旧版本着色语言转换、高层优化（循环优化， 冗余代码消除，常量展开，断言条件）、底层优化（寄存器分配、循环展开）、转换为中间层语言）、着色器优化替换、内存管理（例如创建纹理，本质上就是重新分配KMD返回的大块内存）、纹理swizzling、写命令缓冲（即DMA 传输）。
所有的状态改变和绘制操作都会被UMD转换为硬件识别的指令，还有自动完成的操作：纹理和着色器上传到显存。
4、图形调度器
此为显卡调度器，在APP之间，通过分时的机制来控制3D管线的访问；上下文切换意味着GPU端的状态改变（生成额外的命令给到命令缓冲），也可能伴随着显存里某些资源的Swap in/ out；任一时刻只有一个进程可以提交命令到3D管线。
5、KMD - 内核模式驱动
KMD是实际上跟硬件打交道的单元，可能会有很多个UMD实例运行，但是KMD只有一个；主要职责包括：物理内存分配和映射（UMD可以访问的显存页、GPU可以访问的主存页）、设置显示器显示模式、管理鼠标光标、编程硬件看门狗定时器、响应中断、内容保护等。
最重要的职责就是命令缓冲的管理，UMD的创建的命令缓冲并不是真正的命令缓冲，本质上是GPU可以访问的随机内存片，而UMD实际上完成的是：写内容到内存片、提交给图形调度器、等待调度处理、传递命令缓冲给KMD。KMD收到UMD的命令缓冲后，写入主命令缓冲（可能还需要总线把内容传输到显存，取决于GPU是否可以访问系统内存）。
主命令缓冲（GPU可以访问的主存）本质就是一个简单的环形缓冲区，包含一个读指针（GPU）和写指针（KMD），指针保存在公共的寄存器里面，KMD在提交事务时周期性更新。
6、高速总线
写入主命令缓冲操作并不是直接写到显卡，而是通过总线（PCIe、DMA传输）传输数据到显存。
7、命令处理器
这个是GPU的前端，负责读取KMD写入的命令。
版权声明：本文为CSDN博主「BoriaCao」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/cbhgreat2011/article/details/121515292
