Jump to content
  • Advertisement
Sign in to follow this  
Barnacle Junior


This topic is 4102 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Currently I have a thread pool/work queue/dependency manager/lru cache thing that manages different levels of cache (stream from network, read from database, decompress, etc) for an app that consumes TBs of LOD pyramid data. Since on current drivers for PCIe cards, D3DPOOL_DEFAULT doesn't really let the programmer manage resources like DX8 did, and in DX10 all resources are managed, using an LRU cache to manage default pool textures and vertex/index buffers is counter-productive, since I'm ending up with an unnecessary copy of each texture in memory that I've made a D3D texture resource for. So... In the thread pool clients that take serialized data (JPEG2000 data, compressed meshes, etc), should I decompress these things directly into managed textures and vb/ibs, or should I continue to decompress to de-interleaved arrays (saving 33% space for 3-channel textures) and when it's time for that data to get rendered for the first time, create or recycle a managed resource, interleave the data into that, free the memory that was holding the de-interleaved data and replace it with the CComPtr for the managed resource? In the article "Coding For Multiple Cores on Xbox 360 and Microsoft Windows" in the SDK it remarks on putting "streaming data decompression" on its own thread(s), like I do, but at the same time warns against using D3DCREATE_MULTITHREADED. Besides being a little less complicated, decompressing the data directly into managed resources would relieve the render thread of that work, and also prepare the resource a number of frames before it would actually have to be rendered, which the SDK claims is good practice (this is possible since when descending LOD pyramids, the system may decompress geometry when the projected error is greater than .6pixels, say, while it renders the geometry only when the projected error is greater than .9pixels). So what are your thoughts on D3DCREATE_MULTITHREADED performance impact when worker threads are creating and locking managed resources but not calling DrawPrimitive or any state-changing functions?

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!