Intel GMA X3100 上令人难以置信的 Direct3D9 动态顶点缓冲区锁定崩溃/锁定后失败

发布于 2024-09-02 05:23:45 字数 1216 浏览 3 评论 0原文

首先，我是一位经验丰富的图形程序员，但众所周知，每个人都会犯错误。不幸的是，代码库有点太大，无法在这里开始抛出合理的片段，并且在孤立的 CPP/代码库中重新创建整个情况的要求太高了——对此我很抱歉，没有时间。我会尽力解释。

顺便说一句，如果有人想知道我是如何处理这个或那个的，我当然会提供特定的代码片段！

与 D3DPOOL_DEFAULT 池中的所有资源一样，当设备上下文被拿走时，您迟早必须重置资源。我已经为所有相关资源建立了一个机制来处理这个问题，该机制已运行多年；但尽管如此，自从这个错误被发现以来，我当然已经检查、断言和怀疑过任何假设。

发生的情况如下：我有一个相当大的动态顶点缓冲区，确切大小为 18874368 字节。在为其生成动态几何体（等值面相关，仅供参考）之前，每个帧都会锁定该缓冲区（并使用 D3DLOCK_DISCARD 标志完全丢弃）。这工作得很好，当然，直到我开始重置。可能需要 1 次、2 次或 5 次重置才能引发错误，该错误会导致更新资源上的 Lock() 操作返回的指针发生访问冲突简单的崩溃 - 关于有点相似的地址，但没有在第一种情况下附加到它的偏移量，因为在这种情况下我们正在写一半 - 在 D3D9 dll Lock() 调用旁边。

我已经在其他硬件上对此进行了测试，并将我的 GMA X3100 驱动程序（使用带 BootCamp 的 MacBook）升级到最新版本，但我无法在任何其他计算机上重现它，而且我不知道这里出了什么问题。我试图用类似的缓冲区重现类似的情况（我有一个与我填充的四边形相同类型的大便笺簿），并且超过一定数量的字节它开始表现类似。

我并不是在这里寻求解决方案，但我非常感兴趣是否还有其他开发人员与同一个敌人作战，或者也许有人可以为我指出一些有洞察力的方向，也许会问一些可能会有所启发的问题我可能会或可能不会忽略什么。

谢谢，非常欢迎任何更正。

Niels

p.s - 我的一位朋友提出了一个有效的观点，即它对于板载视频 RAM 来说是一个巨大的缓冲区，并且由于其动态特性，它在内部至少有双倍或三倍缓冲。另一方面，调试输出（D3D9 调试 DLL + 最大警告输出）保持静默。

ps 2 - 如果它在更多机器上进行了测试并且仍然有效 - 这可能是一个环境问题：巨大动态，内部双/三倍缓冲缓冲区，没有大量内存和驱动程序 ps 3 -刚刚

被告知（应该知道）锁定和解锁会完整复制 18MB - 这也不太聪明，但仍然:)（我确实使用了更明智的策略渲染器的通用动态 VB/IB）。

除非有人有更好的建议；我还是很想听:)

原文

For starters I'm a fairly seasoned graphics programmer but as wel all know, everyone makes mistakes. Unfortunately the codebase is a bit too large to start throwing sensible snippets here and re-creating the whole situation in an isolated CPP/codebase is too tall an order -- for which I am sorry, do not have the time. I'll do my best to explain.

B.t.w, I will of course supply specific pieces of code if someone wonders how I'm handling this-or-that!

As with all resources in the D3DPOOL_DEFAULT pool, when the device context is taken away from you you'll sooner or later will have to reset your resources. I've built a mechanism to handle this for all relevant resources that's been working for years; but that fact nothingwithstanding I've of course checked, asserted and doubted any assumption since this bug came to light.

What happens is as follows: I have a rather large dynamic vertex buffer, exact size 18874368 bytes. This buffer is locked (and discarded fully using the D3DLOCK_DISCARD flag) each frame prior to generating dynamic geometry (isosurface-related, f.y.i) to it. This works fine, until, of course, I start to reset. It might take 1 time, it might take 2 or it might take 5 resets to set off a bug that causes an access violation either on the pointer returned by the Lock() operation on the renewed resource or a plain crash -- regarding a somewhat similar address, but without the offset that it has tacked on to it in the first case because in that case we're somewhere halfway writing -- iside the D3D9 dll Lock() call.

I've tested this on other hardware, upgraded my GMA X3100 drivers (using a MacBook with BootCamp) to the latest ones, but I can't reproduce it on any other machine and I'm at a loss about what's wrong here. I have tried to reproduce a similar situation with a similar buffer (I've got a large scratch pad of the same type I filled with quads) and beyond a certain amount of bytes it started to behave likewise.

I'm not asking for a solution here but I'm very interested if there are other developers here who have battled with the same foe or maybe some who can point me in some insightful direction, maybe ask some questions that might shed a light on what I may or may not be overlooking.

Thanks and any corrections are more than welcome.

Niels

p.s - A friend of mine raised the valid point that it is a huge buffer for onboard video RAM and it's being at least double or triple buffered internally due to it's dynamic nature. On the other hand, the debug output (D3D9 debug DLL + max. warning output) remains silent.

p.s 2 - Had it tested on more machines and still works -- it's probably a matter of circumstance: the huge dynamic, internally double/trippled buffered buffer, not a lot of memory and drivers that don't complain when they should..

p.s 3 - Just got told (should've known) that the Lock and Unlock do a full copy of the 18MB -- that's not too smart either, but still :) (I do use that saner strategy for the renderer's generic dynamic VB/IBs).

Unless someone has a better suggestion; I'd still love to hear it :)

分享到QQ

分享到微博