如果你的黑苹果装完之后,打开“关于本机”,显卡那一栏赫然写着 Intel UHD Graphics 630 7 MB,鼠标挪动像在泥里走,拖动窗口能看到明显的残影,那么恭喜,你撞上了黑苹果最经典、也最容易被新手误判的核显驱动问题。这篇文章就是记录我怎么把这块只有 7MB 显存的 UHD 630,修到 macOS 正常识别为 1536MB,并且把 H.264/H.265 硬件解码一并点亮的全过程。机器是 ThinkBook 15p 20v3,CPU i5-10300H,10代 Comet Lake-H 架构,核显正是 UHD 630。方法本身对 9 代、10 代大多数带 UHD 630 的笔记本都适用。
先说一句很多新人会踩的坑:黑苹果的核显驱动,不是像 Windows 那样去官网下载一个“Intel HD Graphics 630 驱动”装上去就行的。macOS 系统里已经内置了核显驱动,它认不出你的卡,是因为缺少一个正确“自我介绍”的环节。这个环节,就是本文要讲的缓冲帧(Framebuffer)修改。
1. 先把结论摆出来:我最后是怎么解决的
1.1 7MB 显存到底是从哪来的
macOS 的 Intel 核显驱动,并不是简简单单一个 kext 就能认卡的。它内部有一张“缓冲帧表”,表里规定了平台 ID 对应的显存大小、可用的显示器输出口、以及内存布局。如果系统识别不了你的显卡 ID,驱动就退回到一个安全模式,这个模式下显存被固定分配为 7MB,输出也基本不可用。
可以这么理解:驱动像一本说明书,核显是设备,系统拿设备型号去查说明书,查到哪一页,就按哪一页的参数来工作。Intel 核显型号那么多,macOS 里的说明书只写了它自家用过的那些组合。你的 UHD 630 如果设备 ID 不在它认识的范围里,系统查不到,那它就只能给一个兜底配置——7MB。这个兜底配置能点亮屏幕,但也仅此而已。
7MB 显存的实际表现,我相信经历过的人都懂:桌面壁纸像是被压缩过,鼠标拖窗口有撕裂感,浏览器滚动网页掉帧,任何带硬件加速的内容都几乎不能用。在线视频看 1080P 都费劲,更不用说 4K。它不是完全黑屏,而是“能用但侮辱智商”的状态。
1.2 为什么 i5-10300H 的 UHD 630 还需要伪装成 Coffee Lake
i5-10300H 是 Comet Lake 架构,核显名字叫 UHD 630。从硬件层面看,它和 Coffee Lake 的 UHD 630 几乎是一样的,但两者的 PCI 设备 ID 不同。macOS 系统里自带的内核驱动是 AppleIntelCFLFrameBuffer,它只认 Coffee Lake 的设备 ID(0x3E9B)。
如果设备 ID 对不上,驱动就不会加载。所以我们需要在 config.plist 的 DeviceProperties 里把 device-id 改成 0x3E9B,让驱动认为它面对的是一颗 Coffee Lake 核显。
这不是什么见不得人的操作,本质就是“引导系统正确加载硬件对应的驱动”。所有黑苹果核显 patch 都在做这件事,只是很多人不理解为什么 10 代 CPU 要伪装成 8 代,就是因为苹果没用过 10 代的核显,但它们的驱动代码里留着兼容路径。
1.3 我最终生效的配置长这样
以下是我在 ThinkBook 15p 上最终写入 config.plist 的参数,你们先别急着复制,后面我会解释为什么不建议死抄。
| 参数 | 十六进制值 | 作用 |
|---|---|---|
| AAPL,ig-platform-id | 07009B3E(即 0x3E9B0007) | 指定笔记本缓冲帧平台 ID |
| device-id | 9B3E0000(即 0x3E9B) | 伪装为 Coffee Lake 核显 ID |
| framebuffer-patch-enable | 01000000 | 启用缓冲帧补丁 |
| framebuffer-stolenmem | 00000008 | 将 stolen memory 调到约 64MB |
| framebuffer-fbmem | 00000090 | 设置帧缓冲大小 |
这里有几个重点:第一,plist 里的 Data 类型是字节序的,所以 0x3E9B0007 在 plist 中写作 07009B3E;第二,framebuffer-stolenmem 和 framebuffer-fbmem 是解决联想这类 BIOS 没有 DVMT 选项的机器的关键;第三,平台 ID 并不是唯一的,0x3E9B0007 不行就换 0x3EA50009,后面我会单独讲。
2. 动手之前,先搞懂几个关键原理
2.1 你为什么不能直接去改显存大小
Windows 下你想改核显显存,最多去 BIOS 里调 DVMT Pre-Allocated。但黑苹果下,显存大小不是用户设置的,而是驱动根据平台 ID 自动分配的。
macOS 对核显的显存管理方式,是把一部分系统内存划给 GPU 使用,这部分内存分为 stolen memory 和 framebuffer memory。前者是给 GPU 运算核心用的,后者是给显示输出用的。驱动通过读平台 ID,来决定划多少内存。平台 ID 对应错了,分配出来的显存自然不对。
所以“修改缓冲帧”这件事,改的不是显存本身,而是让驱动用正确的配置去分配显存。这就像你给一个打印机换了正确的驱动之后,打印分辨率才正常;你在系统设置里把打印质量拉满,但驱动不认,照样打出来一团糊。
2.2 平台 ID 到底是什么
平台 ID(ig-platform-id)是一个四字节的十六进制值,它唯一对应一套缓冲帧布局。比如 0x3E9B0007 代表的是笔记本平台,带 eDP 内屏输出、一个 HDMI 和一个 DP,显存被识别为 1536MB。而 0x3E9B0000 可能就少了一些输出接口。
对于 9 代之后的 UHD 630,笔记本上常用的是 0x3E9B0007,但在有些机器上,它会导致内屏黑屏。这时候可以试 0x3EA50009,这是 Comet Lake-U 平台常用的 ID,兼容性也不错。我认识的几个 10 代笔记本玩家里,两种都有人用,最后亮屏的那个就是正确答案。
需要注意,平台 ID 和显存大小不是一一对应的,同样的平台 ID 配合不同的 stolenmem/fbmem 参数,可能得到不同的显存占用。这就是为什么网上有人贴出来自己显存是 1536MB,有人是 2048MB,都是驱动正常工作,不必纠结数字。
2.3 为什么 BIOS 里没有 DVMT 选项也能改
联想很多笔记本的 BIOS 里根本没有 DVMT Pre-Allocated 这个选项,默认值可能是 32MB,也可能更小。macOS 的核显驱动对 stolen memory 的要求通常比这个大,如果实际分配不够,驱动就会认为这块显卡没法干活,直接退回 7MB。
这就是 framebuffer-patch-enable 和 framebuffer-stolenmem 存在的意义。WhateverGreen(以下简称 WEG)在驱动层拦截了系统对 stolen memory 的读取,强制告诉驱动“显存够了”。这个动作不依赖 BIOS,所以就算联想把 BIOS 选项锁死,我们也能绕过去。
我折腾到后面发现,很多所谓“显存 7MB 无解”的帖子,其实就卡在这一步:只加了平台 ID,但没加 stolenmem patch。平台 ID 对了,驱动认卡了,可一检查显存不够,又退回安全模式。这种症状会骗人,你以为没救,其实就是少补了一刀。
3. 具体操作:修改缓冲帧的完整步骤
3.1 准备工作:工具和备份
开始之前,你要先确认几个前提。
首先是引导环境。我建议使用 OpenCore,虽然 Clover 也有一套注入方法,但 Clover 在较新 macOS 上的兼容性已经不如 OpenCore 了,而且排查问题更麻烦。下面的步骤以 OpenCore 为准。
你需要准备这几个工具:ProperTree 或者 OpenCore Configurator,用来编辑 config.plist;Hackintool,用来查看显卡状态和生成补丁;还要有一个能启动的 U 盘版 EFI,这是救急用的,后面你会感谢自己做了这一步。
打开你的 EFI 分区,确认 Kexts 文件夹里有 Lilu.kext 和 WhateverGreen.kext,并且它们被正确添加到了 config.plist 的 Kernel -> Add 列表里。这两个 kext 是核显补丁的地基,缺一不可。顺序上 Lilu 要在 WEG 前面,版本尽量用最新的。
在改之前,把当前能开机的 config.plist 复制一份到 U 盘里存好。这一点极其重要,因为接下来你可能会改出黑屏,到时候没有备份就只能用 U 盘引导修复,或者干脆重装系统。
3.2 在 OpenCore 的 config.plist 里手动注入参数
用 ProperTree 打开 config.plist,找到 DeviceProperties -> Add 这个字典。如果原本是空的,就新建。我们需要在这个字典里,以 PCI 路径为键名,新建一个条目。核显一般在 PciRoot(0x0)/Pci(0x2,0x0) 这个位置。
结构大致是这样的:
<key>DeviceProperties</key> <dict> <key>Add</key> <dict> <key>PciRoot(0x0)/Pci(0x2,0x0)</key> <dict> <!-- 在这里添加下面的参数 --> </dict> </dict> <key>Delete</key> <dict/> </dict>然后在这个空字典里添加前面表格中的五个参数。需要特别注意的是 Data 类型的十六进制写法。在 ProperTree 里,你可以把值填成 07009B3E 这种格式,然后右键选择 Convert to Data,它会自动帮你转成 plist 标准格式。在 OpenCore Configurator 里,Data 类型也支持直接填十六进制字符串,不需要手动转 Base64。
我建议手动注入一次,不是为了炫技,而是为了让你理解这些参数的位置和格式。以后你看到别人的 EFI,一眼就能看懂对方的 DeviceProperties 在干什么,不至于拿着一个不明不白的文件到处抄。
3.3 用 Hackintool 自动生成缓冲帧补丁(推荐)
手动注入适合理解原理,真正要落地到“我这台机器”,我推荐用 Hackintool 自动生成。因为不同机器、不同 BIOS 版本、不同 macOS 版本,stolenmem 和 fbmem 的最优值可能不同,自动生成能少走很多弯路。
先打开 Hackintool,切到 Framebuffer 标签页。如果当前核显是 7MB 状态,界面上应该能看到 Intel UHD Graphics 630,显存显示 7 MB,平台 ID 可能是空的或者一个不认识的数字。
在右下角有一个 iGPU 平台 ID 下拉框,选择 0x3E9B0007。选完之后,上面的缓冲帧接口列表会刷新,显示出对应的 eDP、HDMI、DP 端口信息。接着在 Patch 标签页里,勾选 Enable framebuffer patches,把 Stolenmem 改成 64MB,FBMEM 改成 192MB,然后点 Generate Patch。
Hackintool 会把生成的补丁输出到界面里,你点一下 Copy to config.plist,它会自动写入到当前的 OpenCore 配置文件里。这个流程比手动改省心,而且生成的值是配对你当前系统的,靠谱很多。
3.4 Clover 引导的老方法也要简单提一下
如果你还在用 Clover,原理是一样的,只是入口不同。Clover Configurator 的 Graphics 选项卡里,有一个 ig-platform-id 的输入框,填上 0x3E9B0007 就行;Device 选项卡里的 Properties 可以加 device-id。但同样的参数,Clover 注入的生效方式和 OpenCore 不太一样,新版 macOS 上经常出现 Clover 注入后没反应的情况。
我个人的建议是,如果你不是守着老机器非要上 Clover,趁早迁到 OpenCore。OpenCore 的日志更清楚,排错路径也清晰,尤其是涉及核显这种底层注入,OpenCore 的 DeviceProperties 方案是目前最稳定、最直观的。
3.5 改完以后第一次开机应该是什么表现
重启之后,如果一切顺利,你会看到两个变化。第一个变化是“关于本机”里显卡那一栏变成了 Intel UHD Graphics 630 1536 MB,第二个变化是整个系统突然“滑”了起来,窗口拖动不再撕裂,桌面动画顺滑,浏览器滚动也不再掉帧。
在 Hackintool 里,显存会显示正常值,Framebuffer 标签页里也能看到正确的平台 ID。这一步成功,意味着核显驱动已经完整加载。如果显存还是 7MB,或者屏幕直接黑了,那就进入下一节的问题排查。
4. 实操过程与踩坑实录
4.1 第一次改完,显存还是 7MB
我最初改完配置重启,进入系统打开 Hackintool,显存还是 7MB。这个结果相当打击人,但排查下来其实原因很简单。
第一步,确认修改是否真的写入到了启动所用的 config.plist。有些人改了桌面上的副本,忘了改 EFI 分区里的那份,效果等于没改。第二步,清 NVRAM。OpenCore 启动界面按住空格键,会出现选项菜单,选择 Reset NVRAM,再重启。很多时候你没改错,就是旧 NVRAM 变量把新配置覆盖了。
第三步,用 -f 启动参数强制重建 kext 缓存并忽略缓存启动。这个参数能排除“缓存了旧配置”导致的问题。第四步,确认 Lilu 和 WhateverGreen 确实在加载。在 OpenCore 引导界面按空格,选择 Verbose 模式启动,看日志里有没有 Lilu 的初始化输出。
我最后的问题就出在 Lilu 上。之前升级系统时,Lilu 被某次操作搞丢了,WEG 单独一个跑,它自己没法完成缓冲帧注入,自然还是 7MB。把 Lilu 放回去,重启,显存直接变 1536MB。
4.2 显存正常了,但内屏黑屏只有鼠标
解决了 7MB 之后,我给另一台笔记本试同样参数,结果开机黑屏,只有一个鼠标指针能看见。这种症状说明 IGPlatform 已经认了卡,但缓冲帧的接口配置和机器的实际物理接口对不上。
解决办法,首先是换平台 ID。0x3E9B0007 在部分机器上会分配一个内屏不支持的接口组合,换成 0x3EA50009 往往能救回来。如果换了还黑,可以在启动参数里加 -igfxnohdmi,这个参数会让 WEG 屏蔽 HDMI 相关的输出探测,优先保证内屏工作。
还有一个容易忽略的点:如果内屏走的是 DP 通道而非 eDP,缓冲帧里的 con0 接口类型可能需要改。Hackintool 的 Framebuffer 界面里,每个端口都有类型选项,把它从 HDMI 改成 DP 或 eDP,重新生成补丁,内屏就亮了。这个操作属于按需调节,没有统一的答案,因为你机器的主板布线决定了它应该走哪个通道。
4.3 硬解验证:从 PPT 到随手拖
显存正常之后,我顺手验证了硬件解码。用的工具是 VideoProc,它有一个硬件加速检测页面,能看到 H.264 和 H.265 的硬解能力。修好之前,所有解码器都显示不可用,修好之后,H.264/H.265 都显示 Available。
最直观的变化是播放一段 4K 60 帧的演示视频。之前 CPU 占用率能飙到 80% 以上,画面还是一卡一卡的;修好之后 CPU 占用掉到了 20% 左右,画面流畅得就像在看原生 mac 上跑的一样。Hackintool 的 Video 标签页里也能看到 Quick Sync 已经开启,这说明核显的视频编码引擎也被正常驱动了。
这个改进对你的实际体验影响很大。不光是在线视频,你用 Final Cut Pro 或者剪映导出视频时,硬编码加速能省下一大半时间。7MB 显存状态下这些全都用不了,修好后这些功能才真正解锁。
4.4 内屏、HDMI、Type-C 的接口问题
ThinkBook 15p 这类机器,有一个很尴尬的现实:部分笔记本的 HDMI 口是直连独显的,而黑苹果下独显基本没法驱动,所以无论你怎么调核显缓冲帧,HDMI 都可能没信号。
如何判断你的 HDMI 走的是不是核显?可以在 Hackintool 的 Framebuffer 页面里看接口列表。如果系统能识别到一个 HDMI 接口,说明它是走核显的,你只需要把对应端口的类型设置成 HDMI,然后重新生成补丁。如果系统里根本没有这个接口,那说明它被连线直通到了独显,这种情况就别折腾核显了,考虑用 Type-C 或者雷电转接,它们通常是接在核显上的。
我自己内屏是 eDP,工作的很好,Type-C 转接也能输出,唯独 HDMI 始终无信号,后来查了主板资料,确认这台机器的 HDMI 走的独显通道。这属于硬件布线问题,不是软件能解决的,搞清楚之后反而释然了。
5. 常见问题速查表
5.1 核显驱动常见症状、原因与处理办法
我把实际操作中遇到的典型问题整理成了一张表,方便你照着排查。
| 症状 | 原因 | 处理办法 |
|---|---|---|
| 显存还是 7MB | WhateverGreen 或 Lilu 没加载 | 检查 Kexts 列表,Reset NVRAM,用 -f 启动 |
| 显存还是 7MB | DVMT 只有 32MB,缺少 stolenmem 补丁 | 补充 framebuffer-patch-enable 和 framebuffer-stolenmem |
| 开机黑屏,只有鼠标 | 平台 ID 接口配置和机器不匹配 | 换 0x3EA50009,或加 -igfxnohdmi 试 |
| 内屏花屏或闪烁 | stolenmem 或 fbmem 设置过小 | 用 Hackintool 把 Stolenmem 调大,重新生成 |
| 睡眠唤醒后黑屏或花屏 | 核显的电源状态切换不完整 | 先试在 pmset 里关掉睡眠,或设置睡眠模式为 0 |
| HDMI 无信号 | HDMI 物理上走独显,核显无法输出 | 换 Type-C/雷电转接,或确认接口类型为 HDMI |
| 升级 macOS 后又变回 7MB | 系统缓存或新系统改了缓冲帧兼容性 | Reset NVRAM,重新用 Hackintool 生成补丁 |
这张表基本覆盖了我见过的 90% 的核显问题。你可以看到,大多数问题的根源就两个:kext 没有正确加载,或者缓冲帧参数和机器不匹配。把它们分开排查,思路会很清晰。
5.2 新手最容易忽略的三个细节
第一个细节是,不要用旧的 OpenCore 配置文件去套新系统。不同 macOS 版本对 DeviceProperties 的解析细节有细微差别,同一条 AAPL,ig-platform-id,在 Catalina 下正常,在 Sonoma 下不一定生效。保持 OpenCore、Lilu、WhateverGreen 三者都是最新版,是黑苹果稳定性的基础。
第二个细节是,不要只加 AAPL,ig-platform-id,而忽略 device-id。很多人看着教程加了平台 ID,显存还是 7MB,就是因为漏掉了 device-id 伪装这一步。10 代 CPU 的核显设备 ID 不是 0x3E9B,系统不认识,即使平台 ID 写对了,驱动也不一定加载。
第三个细节是,改完 config.plist 之后一定要清一次缓存和 NVRAM。这个动作很多人嫌麻烦,但恰恰是“改完没反应”的最大原因。黑苹果的驱动缓存机制在有些版本里很顽固,不强制重建缓存,你就永远在用旧配置启动,怎么改都没用。
6. 折腾背后的几点心得
6.1 “7MB”本身就是一个非常宝贵的诊断信号
以前我看到 7MB 显存,第一反应是哪里坏了。折腾了几次之后,我反而觉得这个数字是一个非常有指向性的诊断信号。
macOS 的核显驱动在无法匹配设备时,会固定分配 7MB 显存作为兜底。所以当你看到这个数字,基本可以断定问题出在“驱动没认出显卡”,而不是显卡硬件坏了,也不是镜像有问题。这时候你该做的是检查设备 ID 伪装、平台 ID 注入、kext 加载情况,把这几条路走一遍,大概率能解决。
理解这一点,你就不会像无头苍蝇一样重装系统,也不会去下载什么“核显驱动修复工具”。黑苹果的核显问题几乎没有玄学,每一步都有明确的逻辑链,顺着链排查就行。
6.2 改 EFI 之前,一定要做最小备份环境
我在折腾过程中,至少两次把自己机器改到黑屏。如果没有那个 U 盘版 EFI,我要么用另一台电脑重新做引导,要么就只能看着屏幕干着急。
具体做法很简单:找一个小 U 盘,格式化后用 OpenCore 安装脚本做一个最简引导盘,把 EFI 文件夹复制进去,里面只放一个最基础的 config.plist,加上 Lilu 和 WhateverGreen。这样你随时插上 U 盘,就能以“刚刚装完系统但没驱动”的状态启动,把之前改坏的 EFI 分区覆盖回来。
这个习惯不光是核显折腾有用,后面你玩蓝牙、声卡、睡眠、电源管理,都会感谢这个 U 盘。黑苹果的容错率全看你备份做得够不够,备份做得好,随便折腾;备份没有,一折腾就完蛋。
6.3 给同样用 Comet Lake-H 笔记本的朋友三条经验
第一,平台 ID 优先试 0x3E9B0007,不行再试 0x3EA50009,这两个是社区验证最多、兼容性最好的组合。第二,显存参数交给 Hackintool 生成,不要自己算十六进制,你不是数字电路工程师,没必要在这里证明什么。第三,别人分享的整套 EFI 可以参考,但不要整个照搬,因为那里面还包含声卡、网卡、USB、ACPI 补丁,这些在你的机器上不一定适用。
Comet Lake-H 这一代笔记本,黑苹果能完美驱动的不多,但核显这块真的是最值得先解决的。核显正常了,系统就流畅了,你再回头去折腾其他组件,心态能好很多。
最后说点实际的。我折腾完后的体会是,黑苹果真正难的,不是下载镜像、不是安装引导,而是这种“教程只会告诉你改个参数,但没告诉你为什么要改”的细节。显存 7MB 不是终点,它背后是缓冲帧表、设备 ID 伪装、DVMT 限制这些彼此咬合的问题。把这几个点想通了,再去看别人的 EFI,你就能明白每一行 DeviceProperties 到底在干什么。如果你也在用 i5-10300H 或者类似的 Comet Lake 本子,按这篇文章的流程走,大概率一两小时就能让核显亮起来。祝你的屏幕早点变成那熟悉的 1536MB。