2.3 功能级别FeatureLevels——老显卡跑新代码的契约
2.3 功能级别 Feature Levels——老显卡跑新代码的契约
本节摘要：功能级别是微软给硬件能力划的版本号：请求 11_0 级别，硬件必须整组提供该级别的全部特性。它把第一章那个"逐项查标志位"的碎片化时代送进历史，是现代 DirectX 处理设备碎片的基石机制。
从碎片化的旧伤说起
回忆第一章 1.1 节的能力检测代码：查纹理标志、查混合矩阵数、查像素着色器版本……那个时代每份渲染代码都长满能力分叉，QA 矩阵爆炸。微软给出的解药是把散落的特性打包成组，每组一个版本号——这就是功能级别（Feature Level）。请求某个级别，硬件要么整组满足，要么创建失败，没有"半个级别"这种灰色地带。一行字概括它的价值：把 N 项独立能力的 2 的 N 次方种组合，坍缩成一条有序的阶梯。
阶梯长什么样
功能级别以 Direct3D 版本命名（9_1、9_2、9_3、10_0、10_1、11_0、11_1、12_0、12_1、12_2），越往上能力越强，且高级别严格包含低级别。几个关键台阶值得记住：
- 11_0：Direct3D 11 的基准线，计算着色器、纹理数组等现代特性从此可用；主流独显与较新的核显都在线内。
- 9_3 及以下：为老移动设备与入门硬件保留的底线，着色器模型停留在 2.0/3.0 时代，很多 11 代 API 特性不可用，写代码时要按 9 代的规矩来。
- 12_0 及以上：D3D 12 时代的分水岭，硬件必须支持相应的资源绑定与着色器模型；许多十年内的游戏要求 11_0 以上作为启动门槛。
用代码验证能力，风格与第一章的标志位查询天差地别——变成一次性的级别协商：
// 逐级试探：从高到低找到硬件支持的最高功能级别 const D3D_FEATURE_LEVEL levels[] = { D3D_FEATURE_LEVEL_12_1, D3D_FEATURE_LEVEL_12_0, D3D_FEATURE_LEVEL_11_1, D3D_FEATURE_LEVEL_11_0, D3D_FEATURE_LEVEL_10_1, D3D_FEATURE_LEVEL_10_0 }; D3D_FEATURE_LEVEL achieved{}; ComPtr<ID3D11Device> device; D3D11CreateDevice(nullptr, D3D_DRIVER_TYPE_HARDWARE, nullptr, 0, levels, ARRAYSIZE(levels), D3D11_SDK_VERSION, device.GetAddressOf(), &achieved, nullptr); // achieved 即硬件达到的最高级别，后续代码按它分档
注意请求列表从高到低排列：运行时取硬件能吞下的最高档。achieved 值落在哪里，决定了后面哪条渲染路径可以启用。
图1 功能级别能力阶梯
与 D3D 12 的关系：门槛而非补丁
一个常见误解是"功能级别是 D3D 11 的事"。正相反，D3D 12 时代它更吃重了：12 的初始化第一参数就是要求的功能级别——硬件至少 11_0 才谈得上手动挡（回顾 2.1 节创建设备代码里的 D3D_FEATURE_LEVEL_12_0）。对 D3D 12 而言，级别是上车的门票；对 D3D 11 而言，级别是档位调节器——同一份代码可以在不同档位上运行。两代用法不同，机制同一。
案例实战：一款网游的支持线决策
背景：某长线运营网游要升级渲染管线，同时不能把大量老机器玩家挡在门外。操作：团队拉出玩家硬件分布统计（显卡型号与驱动版本），映射成功能级别分布；结论是主流玩家聚集在 11_0，9 档与 10 档合计仍有可观占比但逐年萎缩。决策：新渲染特性按 11_0 基准开发；对 10 档保留一条简化的老路径；对 9 档仅维护不新增。结果：升级版本上线后，兼容性工单集中在 9 档玩家，且随硬件迭代自然消退；团队借一次大版本把 9 档路径整体退役，代码库瘦身。解读：功能级别给了这场决策清晰的坐标——支持线不是感觉，是"哪一档的玩家占比跌破维护成本"的量化问题。变式：竞技类项目可以激进划定 11_0+ 以换取更现代的特性红利；休闲分发类项目则倾向把支持线放低、用画质选项而非 API 档位做区分。
三个易踩的坑
其一，级别不是性能档：11_0 与 11_1 的差别是特性（如某些指令），不是快慢——想靠"请求更高级别"提速是缘木求鱼；反过来，低级别也不必然省电，性能由硬件与负载决定，与协商出的档位无关。其二，WARP 软件渲染也有级别：远程桌面或驱动崩溃兜底时，系统可能落到 WARP（软件适配器），它报告的级别会误导你以显卡的逻辑判断能力；生产代码应显式排除软件适配器（2.1 节的过滤逻辑）。顺带把它写进冒烟测试：远程桌面环境是 WARP 的高发场景，测试清单里加一行"远桌面跑通主路径"，能替你拦住一整类环境工单。其三，别把级别查询当设备能力查询：级别是粗档，档内仍有可选项（如各向异性过滤上限、特定格式支持），精确能力仍要查 CheckFormatSupport 一类接口——粗档管架构决策，细查管运行时分支，两层各司其职。其四，协商结果必须落日志：achieved 落在哪一档，是玩家工单归因的第一现场——"我这卡为什么特效少"的提问，答案就藏在启动日志那行级别里。把档位、适配器名、驱动版本三件套一并打进日志，支持线类工单的处理时间能从一轮往返邮件缩短为一次转发。
常见疑问：功能级别与着色器模型是什么关系
这两个概念经常被混为一谈，值得专门掰开。着色器模型（Shader Model，SM）描述的是着色器指令集与编译目标的版本——你的 HLSL 代码编译成哪一代字节码；功能级别描述的是整块硬件的最低能力包——管线配置、资源规格、着色器代次一起打包。两者的对应关系大致是：11_0 档要求硬件支持 SM 5.0，11_1 档对应 SM 5.1 的若干增强，12_0 及以上则要求硬件具备 SM 6 代的指令能力。所以选定了功能级别，你就同时锁定了着色器能用的指令集上限——写 HLSL 时用了一条高档指令，编译目标却对准低档硬件，链接期就会报错，这类报错在玩家机器上复现率极高，因为开发机几乎总是高档卡。
实战上有一条顺手的纪律：把着色器的编译目标跟功能级别档位绑在同一份配置里管理，别让渲染程序员在效果代码里随手指定编译目标。另一个容易忽略的点是编译器本身的演化：从 SM 5 时代的传统编译器到 SM 6 时代基于 DXIL 的新工具链，指令集与验证规则都有变化——第三章 3.3 节讲 HLSL 时会沿着这条线展开。此处先记住因果：级别定档，档定指令集，指令集定着色器写法，三层是单向决定关系。
本节要点回顾
- 功能级别的本质：特性打包成有序档位，一次协商替代满屏标志位查询。
- 协商规则：列表从高到低，运行时取最高可达档；同档特性整组有无，无灰色地带。
- 两代用法：11 里是档位调节器，12 里是上车门票（最低 11_0）。
- 实战守则：按玩家硬件分布定支持线，渲染路径按档分三档即可，低于底线要给人话报错。
底盘三章讲完：焊点（COM）、发动机（设备）、变速箱档位（功能级别）都在位。第三章点火——那个三角形已经等在起跑线上了。