Hi, I'm using the following code:

// load texture
hr = D3DXCreateTextureFromFileEx(
    pD3DDevice,
    szwFilename,
    D3DX_DEFAULT,
    D3DX_DEFAULT,
    D3DX_DEFAULT,
    0,
    D3DFMT_UNKNOWN,
    D3DPOOL_MANAGED,
    D3DX_DEFAULT,
    D3DX_DEFAULT,
    0,
    NULL,
    NULL,
    &m_pTexture);

// use texture
hr = pD3DDevice->SetTexture(0, m_pTexture);

and everything goes well, but when I lower the video memory (from the bios setup) to minimum (32 Mb, aperture 16 Mb), some sprites don't get drawn at all, not even white squares (the material color). I checked for errors, but there is no error, hr is always S_OK, so where's the problem? If I switch to fullscreen while in game, more sprites become visible as Windows allows more VRAM to the application. As far as I understand, system memory (I have a bit more then 1Gb, so it's not a problem) would be used if not enough video or local memory. The video drivers are updated. I'm also using some vertex buffers created with D3DPOOL_DYNAMIC flag which may take out some memory, but if there's space for a few textures, then all should be available through the management system (at FPS expense ofcourse), right? So why the texture management is not working?

So no one has encountered this problem before? Could it be a display driver problem after all?

When you say texture management, who is managing the textures? You just show code to load the texture then set it to the D3D Device.

Your not doing that just before you render in your render loop are you? You should not be loading a texture from a file over and over.

Why are you messing with your BIOS?

D3DPOOL_MANAGED tells the driver to manage the texture (as in swap it in and out as required, and restore it when the device is lost).

It seems odd that it wouldn't render anything. Which graphics card is it? It could always be a broken driver.

What settings are you using to run?

Anything in pool default can't be swapped out, which includes the front buffer, the back buffer, the z buffer, any dynamic vertex/index buffers, any render targets, etc. The card needs some space to command buffers, etc too. Also, the texture must fit in full in the remaining space, it can't upload only the bits it needs as it needs them.

If you're running 1280x1024x32bpp that's 15MB just for front,back,and Z buffers right there. Add in MSAA and you're looking at filling your 32MB of memory without having done anything.

Quote:Original post by LeChuckIsBack
As far as I understand, system memory (I have a bit more then 1Gb, so it's not a problem) would be used if not enough video or local memory.

That's not really true, at least not how you think it's used. Textures will be put in system memory, only to serve as a cache for the manager to page a copy in and out of video memory (whenever such memory is available and the need is there). Pre-DX10 hardware can't access system memory directly. Starting from DX10, things are a little bit different.

Thanks for answering, from what Jerax and Namethatnobodyelsetook said I thing I do this (didn't tested yet, it's messy to change hardware just for a test):

- I load all the textures (not that many), they are managed, but after the loading is completed the VRAM is full with the latest textures;

- now I try to create the non-managed stuff, but there is almost no more VRAM and textures are not getting evicted to make space for POOL_DEFAULT resources, so some vertex buffers fail to create - that would explain why I can't see untextured polygons either - and end up with half pictures :P

I guess I'll simply create the POOL_DEFAULT stuff first - not sure if this is really the problem, but thanks anyway [smile]

Allocating default pool resources first is a wise choice since it results in less memory fragmentation and helps the runtime to better manage the available memory and the residing resources. It is the preferred way of doing things and is specifically stressed out in SDK documentations.