2
\$\begingroup\$

I'm considering a Direct3D9 texture streaming solution, but my company will eventually be going to D3D11 in the future.

I wanted to make my solution as forward compatible as possible, so I was hoping that someone could give me some feedback on exactly what D3D11's capabilities were and what I should be looking for when preparing such a migration?

For reference, here's what I'm considering on D3D9:

  • Load low res mip maps for all meshes at load time
  • Create bounding boxes around each of my objects and detect when I'm inside any given bounding box
  • For any bounding box that I'm inside of I will load the high res portion of the mip map
  • Any bounding box that I've left I'll unload the texture from
  • I've also got to cook up some scheme to manage fragmentation of the GPU memory, initially I'll probably just cycle the GPU memory whenever the camera and my objects are still
\$\endgroup\$
  • 1
    \$\begingroup\$ GPU memory, as it is presented to you in high-level graphics APIs (yes, I consider D3D/OpenGL high-level in this respect), is far too virtualized for you to be able to effectively tackle memory fragmentation issues yourself. You never know the address range your texture occupies in GPU memory (or when it is actually in GPU memory for that matter). The best approach to this would be to use a texture atlas and pack multiple textures into one large surface. \$\endgroup\$ – Andon M. Coleman Jan 7 '14 at 2:03
4
\$\begingroup\$

Direct3D10 and Direct3D11 are very similar in terms of their API design, but 10 is a significant break from D3D9. No matter what you do you're going to have quite a bit of work ahead of you, because not only does the API surface change drastically, so to do many of the fundamental basics become more involved.

The best way to protect yourself against such a migration is to try to isolate your D3D9 code as much as possible: minimize the number of places you touch the actual D3D9 API itself, and expose higher-level concepts than D3D does from your own rendering API. By this I mean, if your rendering API is basically a 1:1 mapping to the underlying D3D types... so you expose vertex buffers, index buffers, shaders, textures, et cetera... then you will have a harder time dealing with D3D10's notion of a shader input layout, which you now have to expose and weave through all your code. If you exposed a higher level "drawable" object that encapsulated most of those concepts within it, you may not need to touch as much code.

Fortunately for you, Microsoft has documented several of the high-profile concerns that will occur when migrating between D3D9 and D3D10. I suggest you peruse that document, and the follow-up for D3D11 which is less intense but still useful.

\$\endgroup\$
  • \$\begingroup\$ So the texture streaming module of the renderer would be distinct from the rest of the renderer, with the exception of having access to renderer's texture pointers. But the streaming module would still need to make DX9 calls to swap those textures out. I was just hoping that I could get some information on any streaming specialized calls DX11 might provide for swapping textures out. \$\endgroup\$ – Jonathan Mee Jan 6 '14 at 18:06
  • \$\begingroup\$ That's a higher-level concern than D3D really deals with. \$\endgroup\$ – Josh Jan 6 '14 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.