PIX抓帧失败因着色器缺失/Zi和/Qembed_debug；NSight Graphics需启用VK_LAYER_KHRONOS_VALIDATION层；PIX中UAV写入不可见因未显式屏障至UNORDERED_ACCESS状态；NSight中vkCmdDraw耗时低但GPU利用率高，实为同步等待导致。

PIX 在 Windows 上抓帧失败：ID3D12Device::CreateGraphicsPipelineState 返回 E_INVALIDARG

常见现象是启动游戏后 PIX 显示“Capture failed”，或帧捕获中途断掉，日志里反复出现 E_INVALIDARG。根本原因不是代码写错，而是 PIX 要求所有着色器编译时必须带 /Zi（调试信息）和 /Qembed_debug（内嵌调试数据），且不能用 strip 工具清理 PDB。Release 构建默认关掉这些，所以即使功能正常，PIX 也抓不到。

• VS 项目中右键着色器文件 → “属性” → “HLSL 编译器” → “调试信息格式”选 Embedded，勾选“生成调试信息”
• CMake 用户需在 add_shader() 或 dxil_compile() 调用中显式传入 /Zi /Qembed_debug
• 避免在构建后期用 llvm-strip 或 Windows 的 editbin /DELETE 清理 DXIL blob —— PIX 靠里面的调试节定位常量缓冲区布局

NSight Graphics 抓不到 Vulkan 渲染帧：VkInstance 创建时漏了 VK_LAYER_KHRONOS_VALIDATION

NSight Graphics 依赖 Vulkan 层注入来拦截 API 调用，如果初始化时没启用验证层（哪怕只是开发机），它就收不到任何命令缓冲区提交信号，界面显示“Waiting for application…” 永远不动。这不是驱动问题，也不是 NSight 没装对。

• 创建 VkInstance 前，确保 enabledLayerCount ≥ 1，且 ppEnabledLayerNames 包含 "VK_LAYER_KHRONOS_VALIDATION"
• Linux 下还需确认 VK_LAYER_PATH 环境变量指向 NSight 安装目录下的 share/vulkan/explicit_layer.d/
• 若用 vkCreateInstance 失败，检查 vkEnumerateInstanceLayerProperties 是否真返回了该层名 —— 某些打包脚本会删掉 layer JSON 文件

PIX 中看不到 UAV 写入结果：Resource State 显示 COMMON 但实际是 UNORDERED_ACCESS

渲染帧里明明写了 RWTexture2D，但在 PIX 的 Resource History 里查不到写入记录，State 列始终是 COMMON。这是因为 D3D12 要求 UAV 访问前必须显式屏障到 D3D12_RESOURCE_STATE_UNORDERED_ACCESS，而 PIX 只跟踪显式状态转换，不猜你“本意想干嘛”。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 检查对应 ResourceBarrier 调用：目标 Subresource 必须是 D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES，StateBefore/StateAfter 必须明确设为 D3D12_RESOURCE_STATE_UNORDERED_ACCESS
• 不要依赖 COMMON 自动转态 —— PIX 不把 COMMON 当有效状态，它只认你亲手写的屏障
• 如果用了 DiscardResource，PIX 会清空历史记录，UAV 写入直接不可见

NSight Graphics 时间线里 vkCmdDraw 耗时异常低，但 GPU 利用率却高

看起来绘制调用很快，但帧时间卡在 GPU 上，NSight 的 GPU Trace 显示大量空闲间隙。真实瓶颈往往不在 draw call 本身，而在前面的资源同步点：比如一个 vkQueueSubmit 等待上一帧的 vkAcquireNextImageKHR 完成，或者 vkWaitForFences 阻塞了整个队列。

立即学习“C++免费学习笔记（深入）”；

• 打开 NSight 的 “Synchronization” 视图，重点看 vkQueueSubmit 和 vkWaitForFences 的等待时间，而非单个 draw
• 检查是否误用 VK_TRUE 作为 vkAcquireNextImageKHR 的 timeout 参数 —— 这会导致无限等待而非超时返回
• 多帧复用同一块 staging buffer？未加 VK_BUFFER_USAGE_TRANSFER_SRC_BIT 或未 vkFlushMappedMemoryRanges，会让驱动在 submit 时隐式同步，时间计入 GPU 空档

调试渲染问题最耗时间的从来不是看不懂工具界面，而是搞不清哪一层在吞掉你的帧 —— 是驱动在等 CPU、CPU 在等 GPU、还是你忘了给资源打标记。PIX 和 NSight 都只忠实地报告你让它们看到的东西，不多猜，也不补全。