Hacker News 中文摘要

RSS订阅

macOS 15.8.2 致 OpenGL 失效 -- macOS 15.8.2 Breaks OpenGL

原文链接 | HN讨论 | 2026-10-19 11:03:36

把一台 MacBook Pro（M1 Pro）从 macOS 15.8 升级到 15.8.2 发布候选版（24H219）后，所有绑定到窗口的 OpenGL 上下文都失去了默认帧缓冲。NSOpenGLView 和 -[NSOpenGLContext setView:] 都会受到影响，用这两种方式绘制的内容只会显示空白窗口。已提交编号 FB25133383 的反馈，其中附有最小示例、内核日志与调用堆栈。

正文

把一台 MacBook Pro（M1 Pro）从 macOS 15.8 升级到 15.8.2 发布候选版（24H219）后，每个附加到窗口的 OpenGL context 都没有默认 framebuffer。NSOpenGLView 和 -[NSOpenGLContext setView:] 都受影响，因此用这种方式绘制的任何内容都显示为空白窗口。我提交了 FB25133383，附带了最小示例、内核日志和调用回溯。

症状

  • kCGLCPHasDrawable 为 0，glCheckFramebufferStatus(GLFRAMEBUFFER) 返回 GLFRAMEBUFFERUNDEFINED（0x8219），glClear 触发 GLINVALIDFRAMEBUFFEROPERATION（0x506）。
  • 每次尝试附加时，内核都记录：(IOGPUFamily) IOGPUGLDrawableUserClient::set_surface(sIOGPUGLDrawableClientSetSurfaceData *): Invalid surface ID = N
  • CGLSetSurface 返回 kCGLBadDrawable（10005）。单步跟踪发现，CGSBindSurface 成功，随后 IOGPU user-client 调用以 kIOReturnBadArgument 失败。

仍然可用的部分

  • 同一 context 中的离屏 FBO。
  • 同一进程中的 CAOpenGLLayer 和 NSOpenGLLayer 能正确渲染。只有 window-surface 路径坏了。

最小示例（仅公共 API）

// clang -fobjc-arc -Wno-deprecated-declarations -framework Cocoa -framework OpenGL repro.m -o repro && ./repro#define GL_SILENCE_DEPRECATION 1#import <Cocoa/Cocoa.h>#import <OpenGL/OpenGL.h>#import <OpenGL/gl.h>#import <OpenGL/glext.h> @interface ReproView : NSOpenGLView@end@implementation ReproView- (void)drawRect:(NSRect)dirtyRect { NSOpenGLContext *ctx = [self openGLContext]; [ctx makeCurrentContext]; GLint hasDrawable = -1; CGLGetParameter(ctx.CGLContextObj, kCGLCPHasDrawable, &hasDrawable); GLenum status = glCheckFramebufferStatus(GL_FRAMEBUFFER); glClearColor(0, 1, 0, 1); glClear(GL_COLOR_BUFFER_BIT); GLenum err = glGetError(); printf("hasDrawable=%d status=0x%x glError=0x%x\n", hasDrawable, status, err); fflush(stdout); [ctx flushBuffer];}@end int main(void) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; NSWindow *win = [[NSWindow alloc] initWithContentRect:NSMakeRect(200, 300, 240, 240) styleMask:NSWindowStyleMaskTitled | NSWindowStyleMaskClosable backing:NSBackingStoreBuffered defer:NO]; NSOpenGLPixelFormatAttribute attrs[] = { NSOpenGLPFADoubleBuffer, NSOpenGLPFAAccelerated, 0 }; NSOpenGLPixelFormat *pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs]; [win.contentView addSubview:[[ReproView alloc] initWithFrame:NSMakeRect(20, 20, 200, 200) pixelFormat:pf]]; [win makeKeyAndOrderFront:nil]; [app activateIgnoringOtherApps:YES]; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{ [app terminate:nil]; }); [app run]; } return 0;}

预期：出现一个绿色方块，并打印 hasDrawable=1 status=0x8cd5 glError=0x0。在 24H219 上：没有绘制任何东西，并打印 hasDrawable=0 status=0x8219 glError=0x506。

影响范围

  • arm64 和 Rosetta 下的 x86_64 结果相同，无论是否 layer-backed，也无论在主线程还是后台线程。
  • 在我的 Mac 上受影响的应用：Sony Imaging Edge Desktop Viewer（NSOpenGLView）、DJI Studio（Qt 6，NSOpenGLContext）及其 Quick Look 扩展。
  • 24H219 上有相同症状的公开报告：kitty #10645、Alacritty #9067、Godot #124311、Bambu Studio #12530（都在 GitHub）。它们覆盖 M1、M4、M4 Pro 和 M4 Max，且 Alacritty 的报告称 15.8.1 是正常的。

问题

  1. 这是 15.8.2 RC 中的已知问题吗？会在 15.8.2 发布前修复吗？
  2. 有人在 macOS 26.7.2 RC 或 27.2 beta 上遇到吗？

开发者目前的临时绕过方法：渲染到 IOSurface 支持的 FBO，并在 CALayer 中呈现该 surface，或直接使用 CAOpenGLLayer。

感谢提交 FB25133383 并附上最小复现器、内核日志和调用回溯，也感谢把复现器发到这里。我无法评论已知问题，也无法评论修复是否或何时发布，你的报告是处理该问题的正确渠道。随着新构建发布，请重新测试并将结果补充到 FB25133383。如果你能拿到 macOS 26.7.2 RC 或 27.2 beta，这些构建的测试结果也属于该报告。若报告里还没有，请附上复现后立即采集的 sysdiagnose。

在一台 MacBook Pro（Apple 芯片）上，升级到 macOS 15.8.2（构建版本 [24H219 —— 请确认你的]）后也复现了。

我用只使用 Apple 框架的最小 Swift 测试得到同样结果：所有 NSOpenGLView 变体（legacy 和 core profile，作为 contentView 或 subview，有无 wantsLayer）都没有 drawable。glCheckFramebufferStatus 返回 0x8219，glGetError 返回 0x506。同一进程中的 CAOpenGLLayer surface 返回 0x8CD5 并能正确绘制。

这影响通过 NSOpenGLView 绘制的音频插件 GUI（在 Ableton Live 12 中见到）。最后一次正常是在更新之前。Apple Diagnostics 报告没有硬件故障。

我提交了反馈 FB25171330，关联了这个帖子和 FB25133383。

对我来说有效的绕过方法是通过 CAOpenGLLayer 绘制。

谢谢，也谢谢 carlosbucci 的独立确认和提交 FB25171330。

今天在 15.8.2 RC 2（24H225） 上重新测试：没有变化。

  • 上面的示例仍然打印 hasDrawable=0 status=0x8219 glError=0x506，原生和 Rosetta 下都一样。
  • NSOpenGLView 和 -[NSOpenGLContext setView:] 仍然是空白；CAOpenGLLayer 和 NSOpenGLLayer 仍能渲染。
  • 内核仍然记录 IOGPUGLDrawableUserClient::set_surface(...): Invalid surface ID = N。
  • IOGPUFamily（104.6.6）、AGXG13X（329.2）和 IOSurface（372.5.4）报告的版本号与 24H219 上相同；只有内核构建变了。

我已把这些补充到 FB25133383，并附上在 24H225 上复现后立即采集的 sysdiagnose。

我没有运行 26.7.2 RC 或 27.2 beta 的 Mac。如果谁有的话，首帖里的示例跑起来只要一分钟，任一构建的结果都会有帮助。

在 macOS 15.8.2 构建 24H225（24H219 之后的构建）上仍然复现，测试于 2026 年 10 月 14 日：NSOpenGLView 变体（legacy 和 core，作为 contentView 和 subview，有无 wantsLayer）仍然返回 glCheckFramebufferStatus 0x8219 和 glGetError 0x506。CAOpenGLLayer 返回 0x8CD5 并正确绘制。

我无法查看这些应用内部，但 FreeCAD、PrusaSlicer 和 OrcaSlicer 在 macOS 15.8.2（24H219）上都无法绘制它们的 3D 区域。

评论

多数人猛烈批评 Apple 近年软件质量断崖式下滑、连旧版本和发布候选版都破坏已有功能，且对 bug 报告态度傲慢，分歧主轴在于这究竟是 Apple 彻底堕落，还是 RC 与早已被弃用的 API 的正常现象且已被官方按流程受理。

认为 Apple 软件质量正在加速崩坏

  • 大量用户借机列举音频丢失、蓝牙断连、全新 M4 Mac 窗口闪烁等小毛病，认为 Apple 生态和软件产品已进入“千刀万剐”式的下滑，甚至单调崩塌十多年后最终连旧版本都不再可靠，有人因此转向 Linux。（较多人） > Apple 软件质量下滑已进入“千刀万剐”阶段，大量小功能就是不正常（@mosura）

抨击 Apple 对待 bug 报告敷衍，把验证工作推给开发者

  • 官方回复被指只是在让报告者继续尝试复现、在每个新版本上重测，却不肯透露是否修过相关子系统、也不给修复时间表；在提交者已经给出完美最小复现的情况下，这种做法被形容为消耗社区无偿贡献的耐心。（高赞） > 在拿到完美的最小复现后，官方却让我在每个新版本上重测、却不肯说是否碰过那个子系统，换作是我绝不会再免费提交 bug 报告（@sneak）

认为 OpenGL 早已被弃用，出问题并不意外

  • 论据：Apple 早在 2018 年的 macOS 10.14 和 iOS 12 就将 OpenGL 标记为弃用，它能继续工作已是奇迹；既然系统属于 Apple，他们没有义务维护一个已被宣布弃用的跨平台 API，意外破坏也算意料之中。（少数人） > Apple 早在 2018 年就把 OpenGL 标记为弃用，它能一直用到现在已经是奇迹，我们不该指望他们为意外破坏负责（@ryandrake）

澄清这是 RC/未发布版本的正常流程，Apple 已确认问题

  • 论据：15.8.2 其实尚未发布，原始讨论来自开发者论坛，Apple 工程师已经确认了该 bug、分配了编号并要求在新版本上复测；发布候选版本本来就是用来抓 bug 的，如果只读 HN 评论会误以为 Apple 完全无视问题。（少数人） > 15.8.2 其实还没发布，Apple 工程师已经在开发者论坛确认了 bug 并分配了编号，只读这里的评论会得到完全错误的印象（@Aurornis）

认为不必依赖 Apple 维护，用 AI 移植或干脆自建

  • 现在可以让 AI 花少量 token 把 OpenGL 代码迁移到新 API，修复遗留项目的成本已经很低；更极端的声音则认为根本不必在乎图形 API 标准，自己造一个就行。（少数人） > 谁还在乎 OpenGL 或任何 API 标准，反正有的是钱买 token，自己造一个就是了（@bergheim）

有价值的补充

  • LunarG 的 Vulkan-on-Metal 封装最近达到了 Vulkan 1.4 一致性，社区在等 Mesa 的 zink 驱动能在 KosmicKrisp 上生产就绪，从而实现把 OpenGL 跑在 Vulkan 之上。（@corysama）
  • 有用户在 macOS 26.6 上实测并未复现该 OpenGL 渲染问题，得到了预期的无错误状态，但苹果开发者论坛本身却出现了无法回复的故障。（@zimpenfish）
  • XQuartz 的性能问题已经持续数年，有人怀疑根源正是 OpenGL 相关缺陷，说明受影响的不只是单个应用。（@jd3）
  • 有人讽刺说，在“AI 时代”还出现这种回归，只能说明 OpenGL 从来就没被放进苹果的回归测试套件。（@jimmydoe）
  • 版本号相当混乱：15.8.2 其实尚未发布，讨论里还有人停留在 15.5，而同时有人已经在 macOS 26 甚至 27 上，苹果的版本命名和发布状态容易让外人误判严重性。（综合 @Aurornis、@1over137、@m3kw9）