Matrix-Game 4.0 跑在核显轻薄本上——是驱动没装好还是根本带不动？

核显轻薄本启动 Matrix-Game 4.0 失败，先不要下“带不动”的判断。按经验，集成显卡环境下更常见的是驱动版本偏旧、Vulkan 或 DirectX 运行时组件缺失、程序枚举不到可用设备，硬件算力不足反而排在后面。区分办法很直接：先看系统层面认不认这块核显，再看运行时能不能枚举到设备，最后用最小负载跑一次并记录失败停在哪个阶段。三步结果对不上，才需要谈硬件边界。

核显轻薄本上跑 Matrix-Game 4.0，判断顺序应是“系统识别 → 运行时枚举 → 最小负载启动”。驱动版本正常但运行时设备列表为空，属于运行库或 ICD 缺失，装齐组件后有机会恢复；设备能被枚举、最小负载仍卡在着色器编译或显存分配，通常是核显共享内存和特性等级不足，靠调参很难绕过。启动失败时先把原文日志留下来，再决定是修环境还是换机器，避免在两种问题之间反复试错。

查核显型号与驱动版本

这一步只回答一个问题：操作系统是否把这块核显当成一块正常工作的图形适配器。Windows 和 Linux 的读法不同，字段含义也不一样。

Windows 下用 PowerShell 读取显示适配器信息，比在设备管理器里翻属性更便于留档：

Get-CimInstance Win32_VideoController |
  Select-Object Name, DriverVersion, DriverDate, Status, AdapterRAM

Linux 下依次看 PCI 枚举、OpenGL 渲染器和 Vulkan 设备概要：

lspci -nn | grep -Ei 'vga|3d|display'
glxinfo -B | grep -Ei 'renderer|OpenGL version'
vulkaninfo `--summary` | sed -n '1,40p'

读数怎么判断：glxinfo -B 的 renderer 如果显示 llvmpipe 或 softpipe，说明当前走的是软件渲染，图形栈没有真正接上核显；vulkaninfo `--summary` 里 deviceName 应该是核显的实际型号名，deviceType 为集成 GPU 类型，apiVersion 与 driverVersion 能正常打印；如果打印 vkEnumeratePhysicalDevices 相关错误或列表为空，说明 Vulkan loader 找不到可用的 ICD。Windows 侧则看 Status 是否为 OK、DriverVersion 是否仍是系统自带的基础显示驱动版本，这种版本通常只够点亮屏幕，不足以支撑图形应用。驱动是否需要更新，建议以主板或核显厂商页面提供的版本为准，不要用第三方驱动工具批量覆盖。

查运行时是否识别到可用设备

系统识别正常但程序依然报错，多半是运行时没取到设备。这种情况要和“驱动没装好”分开：驱动在系统层已加载，缺的是运行时依赖，例如 Vulkan loader、ICD 描述文件、DirectX 运行时组件或推理后端动态库。

先做运行时自检，把设备枚举结果打出来：

Matrix-Game 4.0 跑在核显轻薄本上——是驱动没装好还是根本带不动？

vulkaninfo `--summary` | grep -E 'apiVersion|driverVersion|deviceName|deviceType'

如果 Matrix-Game 4.0 的文档里提到推理或加速后端，再补一条后端可用性检查：

python -c "import onnxruntime as ort; print(ort.get_available_providers())"

DirectX 路线可以用 dxdiag /t dxdiag.txt 导出文本，重点看 Display 段的驱动型号、Driver Model 与 Feature Levels 列表。Linux 下若怀疑 ICD 未被加载，可以临时指定 VK_ICD_FILENAMES 指向发行版提供的 icd json 再跑一次自检，用来验证 loader 是否只是找不到描述文件。

常见输出形态与对应处理方向：设备列表为空，通常是 loader 或 ICD 缺失，先补运行库；列表里只有基础渲染设备，说明系统在用软件渲染兜底，回到第一步看驱动；能列出核显型号，但程序仍然报找不到设备，问题更可能在程序侧的设备选择逻辑，可以查启动参数里是否强制指定了独显或特定后端。

用最小负载启动并记录失败位置

只改一个变量：把画质和分辨率压到最低，关掉抗锯齿、光追、后处理这类可选特性，用窗口模式启动，并把标准输出和错误输出一起重定向到文件。参数名以程序 `--help` 的实际输出为准：

MatrixGame `--windowed` `--resolution` 1280x720 `--log-level`=debug \
  `--disable-raytracing` > run.log 2>&1

跑完后在 run.log 里定位失败阶段，重点区分三种位置：

加载前：进程启动失败、动态库找不到、缺少 .dll 或 .so，日志里通常是 loader 或 import 相关报错，还没进入设备创建。
加载中：设备创建、交换链初始化、着色器或管线编译阶段失败，日志里出现设备创建接口、DXGI、vkCreateDevice、shader compile 这类字样。
运行中：已经进入渲染循环，随后因显存分配失败、贴图加载失败或驱动超时退出。

记录时要保留报错原文整行，包括级别标记、模块名和错误码，而不是只记一句“启动失败”。同一个错误码在不同驱动版本下的含义可能不同，原文是后续比对和检索的依据。如果日志里出现软件渲染设备名，说明程序降级到了 CPU 渲染路径，这通常不是性能问题，而是设备选择没有命中核显。

对照硬件能力给出结论边界

核显轻薄本能不能承担 Matrix-Game 4.0，宜按观测项对照结论，而不是凭感觉判断。可用的观测项包括：Vulkan 报告的 API 版本与驱动版本、DirectX 的 Feature Levels 列表、核显可用的共享内存上限、程序最小负载下是否成功进入主循环、以及日志中是否出现显存分配失败。

对应的结论范围可以这样划：驱动与运行时都正常、最小负载能进入主循环，说明环境侧没有阻塞，接下来是画面质量和帧率取舍问题；设备能枚举、最小负载卡在管线编译或显存分配，说明核显的共享内存和特性等级撑不住当前渲染路径，调低分辨率和关闭可选特效只是延缓，不等于解决；设备枚举失败或直接落到软件渲染，属于环境问题，装齐组件和更新驱动后才值得再评估硬件。

需要说清的边界是：核显使用系统内存，纹理和中间缓冲会与操作系统争用同一块内存，大场景加载和多层后处理在此类设备上通常不足；缺少特定图形特性或特性等级不够时，程序可能根本没有可回退路径，这类情况靠参数调优绕不过去。

留下可复现记录供换机后对比

结论要能复现，就不能依赖当时随手打开的几个窗口。建议把固定命令、启动参数和输出文件放进同一个目录，换机器或换驱动后再跑一遍相同命令做对照。

OUT=matrixgame-diag/$(date +%Y%m%d)
mkdir -p "$OUT"
lspci -nn > "$OUT/lspci.txt"
glxinfo -B > "$OUT/glx.txt" 2>&1
vulkaninfo `--summary` > "$OUT/vulkan.txt" 2>&1
printf '%s\n' `--windowed` `--resolution` 1280x720 `--log-level`=debug > "$OUT/args.txt"
cp run.log "$OUT/run.log"

Windows 下用同样的思路，把 Get-CimInstance 的输出、dxdiag.txt、启动参数和运行日志保存到同一目录。保存格式建议统一为纯文本，文件名带机器型号和日期，便于横向比对；如果程序支持输出结构化日志，优先保留原始格式，不要只截取片段。记录里同时写明驱动版本和启动参数，否则同样的报错在不同驱动下无法直接比较。