我之前在处理超大OpenGL纹理时也碰到过几乎一模一样的NVIDIA驱动栈溢出问题，分享几个亲测有效的排查和解决思路：

• 先确认显卡的实际支持能力与驱动状态
  首先用glGetIntegerv(GL_MAX_TEXTURE_SIZE, &maxSupportedSize)获取显卡真正支持的最大纹理尺寸——虽然16384是很多现代显卡的标称值，但部分中低端或旧型号显卡在结合3D模型渲染的实际场景中，可能存在隐性的资源限制。另外，一定要把NVIDIA驱动更新到官网最新的Game Ready版本，旧驱动对大纹理的栈内存处理经常存在已知bug，更新后大概率能解决这类驱动内部的崩溃。

• 优化纹理数据的存储与加载逻辑
  栈溢出本质是驱动处理大纹理时栈空间不足，你可以从这几个方向优化：

  • 绝对不要在栈上创建大尺寸的纹理数据缓冲区，把纹理数据移到堆内存（比如用malloc/new分配，而非栈上的静态数组），减少你的程序自身对栈空间的占用，给驱动留出更多余量。
  • 尝试拆分大纹理：如果场景不需要同时绑定16384级别的纹理，考虑动态加载/卸载，或者把单张大纹理拆分成多个小纹理进行拼接，这种方式能直接绕过驱动的栈限制。
  • 改用压缩纹理格式：比如BC1（DXT1）、BC3（DXT5）这类硬件支持的压缩格式，压缩后的纹理数据量能减少75%以上，驱动处理时的栈压力会显著降低，还能节省显存空间。

• 调整OpenGL上下文的创建参数
  部分窗口库（比如GLFW、SDL）在创建OpenGL上下文时，支持调整栈相关的配置参数；如果是用原生Windows API创建上下文，可以尝试修改像素格式描述符中与栈大小相关的选项。不过这个方法兼容性较差，不同驱动的支持程度不一，建议作为备选方案。

• 启用OpenGL调试上下文深挖问题
  创建调试版的OpenGL上下文并开启调试输出，虽然崩溃发生在驱动内部，但调试上下文可能会输出驱动处理大纹理时的警告信息（比如内存分配失败、纹理格式不兼容等），这些信息能帮你区分到底是驱动的原生bug，还是你的代码存在隐性的参数错误导致驱动异常。

• 临时降级或更换渲染策略
  如果以上方法都无法解决，作为临时方案，可以把最大纹理尺寸降到8192，或者改用纹理数组（Texture Array）替代单张大纹理——纹理数组的内存布局更规整，驱动处理时的栈压力通常比单张大纹理小很多。

内容的提问来源于stack exchange，提问作者user1961169