使用 D3D,我是不是需要在退出流程之前调用 release?
Posted
技术标签:
【中文标题】使用 D3D,我是不是需要在退出流程之前调用 release?【英文标题】:With D3D, do I need to call release before I exit my process?使用 D3D,我是否需要在退出流程之前调用 release? 【发布时间】:2011-09-02 16:46:33 【问题描述】:我正在为 direct3d 学习的教程是这样说的:
"... 基本上,如果您创建 Direct3D,但从不关闭它,它会一直在计算机的后台运行,直到您下次重新启动,即使在程序本身关闭之后也是如此。糟糕。特别糟糕,如果你有“你的游戏中有很多资源。释放这两个界面让一切都摆脱困境,并允许 Windows 收回它的内存。” (link)
我真的不相信本教程所说的,退出进程后资源仍然会挂起......
例如,如果我的程序崩溃或者我只是在调试时按停止。资源是否仍然存在?和其他使用directx的游戏,我经常通过杀死进程来关闭它们。
如果我退出我的进程并且不调用 device->Release,操作系统是否可以释放资源?
【问题讨论】:
【参考方案1】:简单地说,不。那不是真的。当您的进程终止时,您的所有 DirectX 资源都将被释放,并且不会泄漏任何 GPU 或系统内存。
【讨论】:
【参考方案2】:虽然确实会回收与进程相关的资源,例如内存、线程、句柄等,但请记住,D3D 也在利用视频硬件上的内存和资源。根据您的具体实现,未能通知 D3D 您正在关闭可能也不会在进程退出时清除所有这些。
我看到使用托管 DX9 接口的软件中出现了一些非常有趣的渲染伪影,这些伪影在调用 EvictManagedResources 之前无法清理。这些工件出现在自动化测试套件中,是的 - 它们在同一进程的不同调用之间持续存在(作为显示/帧缓冲区上的垃圾小矩形)。
正确编码的应用仍然可以对内部异常和/或进程终止请求(WM_QUERYENDSESSION 等)做出适当反应并执行此清理。
【讨论】:
清理内存(归零)和释放内存以供进一步使用是有区别的。我怀疑后者在进程退出时没有完成。但是,是的,写入视频内存的内容在应用程序调用过程中持续存在,但这些内容随后位于下一个应用程序的视频内存中的事实表明,该内存已重新分配给新应用程序,因此没有内存泄漏。跨度> "清理" != "归零内存" 就我而言。进程系统内存被释放是正确的,但视频设备资源(内存)没有被释放,这取决于您的 [D3DPOOL 使用情况]msdn.microsoft.com/en-us/library/bb172584(v=vs.85).aspx - 此内存的设备部分与应用程序无关(并且 D3DPOOL_MANAGED 正在在我的情况下使用)。我还要指出,在第一次测试应用程序迭代之后和下一次迭代开始之前(它们持续存在),工件在桌面上是可见的,直到添加 EvictManagedResources 无论您在哪个池中分配 D3D 资源,它们都会在您的应用程序终止时自动释放并返回给驱动程序,即使它崩溃也是如此。它们不会被清零或覆盖,因此在第二个进程中使用新分配但未初始化的缓冲区可能仍会显示旧内容的失真版本。但即使您在退出前手动释放第一个进程中的每个资源指针,情况也可能如此。 再一次,我观察到的显示伪影在第一次终止后仍然存在,并且在后续调用的整个运行过程中一直存在,因此很明显,应用程序损坏了超出范围的“驱动程序内存”应用程序,直到我添加了显式的 EvictManagedResources 调用。也就是说,我已经阅读了更多指南 [msdn.microsoft.com/en-us/library/ee418784(v=vs.85).aspx],并看到退出时不需要 EvictManagedResources。损坏可能发生在其他地方,或者这只是 Managed DirectX 9 中的错误。以上是关于使用 D3D,我是不是需要在退出流程之前调用 release?的主要内容,如果未能解决你的问题,请参考以下文章
如何在从 Meteor.method 返回之前等待子流程结果
在退出 java 启动的命令行命令或 shell 脚本之前提取进程环境