2
\$\begingroup\$

I have an OpenGL application that uses a lot of texture memory. While the texture is stored in the system memory, that texture memory is not part of my application process memory.

When this application is ported to D3D and the textures are uploaded to the D3DPOOL_MANAGED pool, the process memory increases proportional to the texture memory and the application crashes due to running out of memory (while in OpenGL, even though the overall system memory utilization has greatly increased, the process memory is still low)

I don't want to have to switch to D3DPOOL_DEFAULT, since the I would have to reload all textures when the device is reset. Is there a workable solution to get my D3D9 application to put the system texture memory somewhere else beside my process, similar to OpenGL?

EDIT: So I just learned about IDirect3DDevice9Ex. Turns out using this interface instead of IDirect3DDevice9 make DirectX work exactly like opengl in terms of texture memory (system memory goes up proportional to my texture usage, but not the process memory). So this is an option for me. However I would still like to know if there are any options since IDirect3DDevice9Ex doesn't work on XP.

\$\endgroup\$
3
  • \$\begingroup\$ What metrics are you using to profile the memory usage of your projects? The task manager doesn't show you everything by default (and OpenGL can store texture data in system memory). \$\endgroup\$
    – user1430
    Dec 4, 2013 at 21:15
  • \$\begingroup\$ I'm using the task manager. I agree that OpenGL is storing texture data in system memory. In the opengl application, the system memory goes way up by gigabytes, but not the process. In the dx9 app, both system memory and process apps go up by gigabytes. \$\endgroup\$
    – default
    Dec 4, 2013 at 21:19
  • \$\begingroup\$ You're probably not looking at the right memory metric in the task manager then. OpenGL and D3D probably do use different places in memory for system-backed resources, but you probably won't see anything in the task manager until you enable the correct column. But this is a bit of digression from your real question I guess. \$\endgroup\$
    – user1430
    Dec 4, 2013 at 21:21

3 Answers 3

3
\$\begingroup\$

If you don't want your textures backed by system memory, don't use D3DPOOL_MANAGED. Use some other member of the D3DPOOL enumeration (and change your code accordingly).

Generally this means choosing D3DPOOL_DEFAULT and handling device resets. You don't really have many other options, that's just how D3D9 works. If you can tolerate IDirect3DDevice9Ex, that will change your lost device behavior (see here and here), but also note that you cannot use D3DPOOL_MANAGED at all with IDirect3DDevice9Ex.

You might also consider the more drastic step of moving to D3D 10+ (but that will also cost you XP support).

\$\endgroup\$
3
\$\begingroup\$

If you're okay with using D3D9Ex which is Vista+ only then you should have absolutely zero reasons not to just using D3D11 (don't bother with 10; there are no systems that support 10 that don't support 11 if up-to-date service packs are installed). You can use a lower feature level in D3D11 so your game will still run on older hardware.

Note that according to the Steam Hardware Survey, only around 6.4% of users are even running XP (it confusingly also states that 14% of users have a DX10/11 capable GPU and are running on XP). XP can be considered a relic if you're targeting North America. Some other markets still have much higher XP installation rates but they also tend to have older hardware.

So far as actually answering directly your question: no. D3D requires that memory be managed in your process space or not at all. If it's not managed then you must deal with lost device.

For what it's worth, even with D3D10/11/GL you should still deal with removed device issues. Lost device is a relic of XP (back when the OS tried to stick to giving a process total control of the GPU and might have to wrench it back). Removed/reset devices can include driver crashes and restarts. If you handle removed devices, you're going to have to deal with reloading resources. This is one of the nicer features you can provide a user; I recall Borderlands managing to cause my GPU to lock up frequently due to a hardware issue, Windows would detect the locked GPU and then reset it (turning the screen black and freezing the system for a few seconds), and then Borderlands would continue like nothing had even happened. Most other games are just dead and all progress lost.

Note that GL has no standard way to detect removed/reset devices, owing possibly to the fact that most every GL implementation will just crash your kernel on such problems (this is one of the many reasons for users to prefer games written in D3D on Vista+: the system will be more stable). Mobile platforms tend to add in some way to know that the device has been reset owning to their limited resources and multi-tasking model (it's basically the D3D9 lost device situation; gone on the PC but alive and kicking on phones, albeit under vendor proprietary APIs).

The absolute best idea is to just update your engine to be able to deal with the need to reload assets on demand. Then you can on any platform or API (aside from desktop GL) deal with any variation of lost device or removed/reset device on almost.

\$\endgroup\$
2
\$\begingroup\$

First thing to consider is: is XP support really that important? Have you actually profiled your potential customer base and determined that XP support is something you need? Or is this just based on a gut feeling? Unless you have the numbers to back it up, losing XP support could be something you could easily afford to do.

If you're running out of process address space (and I'm assuming this means that you're building a 32-bit app) then your program already has quite heavy hardware requirements. There's a reality you're going to need to face here, and that's the fact that most people still on XP machines will also be on older hardware. This hardware may just not be able to support your program's requirements. Some vendors may not even have XP drivers available for the kind of hardware your program needs (e.g AMD appear to no longer do XP drivers for HD6000 series notebook cards). You need to get realistic about your requirements here.

Based on this, I'm suspecting that your wish to continue supporting XP is an artificial limitation you're placing on yourself. I'd urge you to reconsider this, and at least do the research (which you may already have done, but it's not coming across in your question) to determine if it's something you even need.

Regarding OpenGL vs D3D memory usage, my guess (and it's just a guess) is that D3D is storing the system memory backup in user space, whereas your GL driver is storing it in kernel space.

I made a point of saying "your GL driver" above because that leads me into the second thing: because a GL driver is fully implemented by the hardware vendor, different GL drivers may behave differently. Your driver may be OK with the amount of memory you're using, a user of your program may have different hardware from a different vendor with a different driver that may not be OK.

What I'm saying here is that you have a bigger problem on your hands than this difference between GL and D3D on your own machine. You have a problem that may also prevent your program from working on other people's machines under GL.

The underlying cause here is that large amount of texture memory you're using. There are standard approaches for dealing with this: using compressed textures, using lower resolution textures in low memory scenarios, unloading textures that aren't needed any more, implementing texture streaming. As well as reconsidering the XP requirement, that's something that you may need to work on.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .