大伙来讨论一下D3D的多线程问题吧～～～

GhostCheng

LPDIRECT3DTEXTURE9 的创建与释放，是不是一定要在同一个线程内操作？

我在主线程创建纹理，然后有一个辅助线程检测长期不使用的纹理并释放，结果在Release纹理的时候，发生异常。

后来我在创建IDirect3DDevice9的时候，指定了参数D3DCREATE_MULTITHREADED。
结果是大部分在辅助线程中Release纹理的操作正常了，但是时不时仍然有异常。

另外，如果仅仅在线程中Release处于D3DPOOL_SYSTEMMEM中的表面，则没有任何问题。

我查了DX9的SDK，其中说IDirect3DDevice9的创建与释放，必须在同一线程，但是LPDIRECT3DTEXTURE9 确没有关于多线程的描述（可能是我没找到）。

请问有这方面经验的高手们是怎么解决的呀？
难道真的要全部在同一个线程中释放纹理吗？对于图片量相当大的2D游戏来说，这个不太现实哎～～

congy

由于d3d是com接口形式，在multithread情况下要遵守com的线程规范，而com的线程规范又很复杂，每个线程都要初始化com才能使用，所以建议不要再多线程环境下使用d3d。更何况多线程并不能带来多大的性能提升，使用不当反而会降低性能，在每祯里检查是否使用纹理也是一样的。

GhostCheng

线程启动时，我已经初始化过COM了，没有什么效果，感觉不仅仅是需要初始化的问题，在线程中使用另一线程创建的COM对象，应该还需要一些别的操作～～

熟悉的朋友，请指点一下阿～～

congy

你初始化com时选择那种的同步方式？

XiaoP

      在渲染方面，DX是不推荐使用多线程的，MSDN明确指出在各种Device相关的操作中如果使用多线程，最好情况也是造成性能降低，更不说异步复杂性为你带来的麻烦了（COM??初始化??设备共享??※×（……％Help!!!!）。

      其实多线程一般使用在资源管理、网络读取等I/O模块上，为什么需要用在纹理的创建和释放上面呢？事实上对单CPU独占或同步方式的操作（包括分配内存），多线程又有什么性能优势呢？

bigbook2000

为什么要选择多线程？

多线程的目的是因为我们有多个任务要去处理，而每个任务处理的速度、大小都不一样，而且互相之间没有必然的资源冲突。

我们常常总是会想，游戏是多好的多线程例子，用一个线程去渲染，用一个线程处理数据。但是大家都有没有想过这两个线程之间的资源冲突？

对于游戏这种资源众多复杂，实时性高，设备依赖严重的程序，我们如何万无一失的保证资源没有冲突？

如果大家对COM线程模型有所了解的话，就会知道，COM的线程模型和我们应用程序的多线程安全是两码事，根本不是一个概念，它是针对多个实例的线程处理方式，而不是一个对象的线程冲突处理。我从没有看到微软的相关资料说明DX的对象是线程安全的，我倒是看到很多侧面的东西描述他不保证所有线程安全。

大家可以想象，你在生成纹理的时候，一个线程正在往显卡的内存写数据，二这时你的另外一个线程却要去把它送到渲染管道进行渲染。怎么办，那么就只有设置状态，添加锁等等。无形之中增加了系统负担，降低了效率。还不如一开始就在适当的时候把数据准备好，然后再去渲染。

同时由于多线程，很多数据变的不那么可靠，对象都需要通过异步事件来通知，加大了开发的工作量，代码的效率也降低了。

所以，我们看到微软所有提供的游戏示例和技术文档，基本上没有关于多线程的描述。当然，我们期待微软能在这个方面有所突破，等到真正有一天DX能完完全全支持多线程。

z16304607

学习了

GhostCheng

哎～看来的确没什么好办法解决，我现在的解决方案是在辅助线程中postmessage到窗口，然后由主线程释放纹理了。～～
多谢 XiaoP 和 bigbook2000。

冰峰传奇

的确如此，多线程比较繁琐。
目前的一个cpu肯定有额外的消耗。
而且对device的操作必然要锁定。
不过双核的出现，也肯定意味着这是早晚的一个趋势。
只是目前看似还太早点。

xjyhust

没有必要用多线程的
显卡的几何流水线都是几百上千级
用多线程反而会降低原本很自然的过程