【问题标题】:Possible to keep bad VRAM "occupied"?可以保持坏 VRAM“被占用”吗?
【发布时间】:2014-03-24 03:40:04
【问题描述】:

我有一台 iMac,其 VRAM 似乎出现故障。在启动时,有一段时间一切都很好,但最终,随着越来越多的窗口被打开(即在 GPU 上创建纹理),我最终遇到了故障 VRAM,我得到了这些奇怪的“嘈杂”网格状图案窗户里的红色和绿色。

我有一个想法,但总的来说,我在 OpenGL 和 GPU 编程方面大多​​是新手,所以我想我会在这里询问它是否合理:

如果我编写一个小应用程序,它会在启动时运行,并且会分配 GPU 纹理(一些合理的量 - 我不知道,也许是 256K?)直到它耗尽所有可用的 VRAM(即无法分配更多纹理)。然后让它将特定模式的数据上传到每个纹理中。接下来,它将从 GPU 回读纹理,并根据原始模式对数据进行校验和。如果它签出,则释放它(供系统的其余部分使用)。如果它没有校验和,请挂在它上面(永远)。

我可以看到的缺陷:用户空间应用程序无法确定地运行所有 VRAM,因为系统会占用一些 VRAM,但实际上,我只是想从一个在这里垂死的机器,所以任何在这方面有帮助的东西都是受欢迎的。我也知道从 VRAM 读回比较慢,但我并不太关心性能——这是一项实际的努力,可以肯定。

这听起来有道理吗,还是我在这里遗漏了一些关于 GPU 的基本事实?

【问题讨论】:

  • 行不通。您上传到 VRAM 的数据不会永远留在那里,也没有办法将其保存在同一个地方。驱动程序正在管理 vram,它可以随时从其中加载或卸载任何部分(例如,当渲染不使用特定缓冲区时,它最终将从 vram 中卸载,稍后从其 RAM 上载再次使用时复制。
  • 无赖。我想我会留下这个问题,看看是否有人有任何其他热门想法,但我想是时候开始寻找新机器了......

标签: macos opengl gpu


【解决方案1】:

您的方法很有趣,但我认为如果您正在寻找快速修复或解决方法,还有其他方法可能更容易实施。如果您的 VRAM 出现问题,那么很可能是某个特定位置发生了损坏。如果您能够始终如一地确定它发生在某个时间点(VRAM 正在消耗 x 数量的内存等),那么您可以使用它。

创建 RAM 磁盘非常容易,另一种可能性是为 VRAM 分配常规内存。我知道这两个都是很有可能的,因为我已经做到了。如果有人说某事“行不通”(Pavel 无意冒犯),它至少不应该阻止你尝试。如果您对我提到的技术感兴趣,我很乐意提供更多信息,但是,这是关于您的想法,我想知道您是否可以实现它。

【讨论】:

  • 这是一个带有离散的 iMac(即不将主内存用于 VRAM)。对主内存所做的任何操作都不会对这种情况产生任何影响。
  • 所以你的意思是,如果你加载了一个自定义的 kext,它通过向其中添加额外的主内存来操纵帧缓冲区,那么对你的 VRAM 的影响为零?笔记本电脑经常做这种事情;这真的不像你想象的那么不可能,而且必须有一些入口和出口才能让记忆来回流动。
  • 这不是笔记本电脑。图形硬件未集成。 “将额外的主内存添加到帧缓冲区”对我来说听起来完全陌生。如果您对此有参考,我很乐意看到它。
  • @ipmcc,是的,我很清楚 iMac 不是笔记本电脑,无论如何我所解释的都是相关的。图形(无论是否使用板载内存)由可操作的内核扩展驱动;您认为所有 haxintosh 用户如何能够使他们的硬件正常工作?原理是一样的。
  • 我仍在等待指向实际支持您所说的内容的链接...
【解决方案2】:

如果您能够编写一个甚至在操作系统加载之前就可以在启动时运行的应用程序,那将是在引导加载程序中 - 为什么您当时不进行内存自检呢?

或者您的意思是操作系统启动登录后的用户区应用程序?用户空间应用程序将无法执行您提到的循环遍历每个地址的操作,因为每个页面都没有直接映射到用户空间。

如果您确定 RAM 有问题,您是否尝试更换 RAM?

【讨论】:

  • 你误解了这个问题。这是 GPU 上的 VRAM,对它的访问由图形驱动程序介导。
猜你喜欢
  • 1970-01-01
  • 2018-05-21
  • 2021-05-11
  • 1970-01-01
  • 1970-01-01
  • 2011-01-21
  • 1970-01-01
  • 2017-03-12
  • 2020-12-09
相关资源
最近更新 更多