D3DERR_OUTOFVIDEOMEMORY while D3DXCreateTextureFromFileEx()
-
this is what i'm doing:
m_pD3D = Direct3DCreate9( D3D_SDK_VERSION )
...
D3DPRESENT_PARAMETERS d3dpp;
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;
m_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING,
&d3dpp, &m_pd3dDevice )...
D3DXCreateTextureFromFileEx(m_pd3dDevice, pSrcFile.c_str()
,D3DX_DEFAULT,
D3DX_DEFAULT ,
D3DX_DEFAULT,
D3DUSAGE_RENDERTARGET,
D3DFMT_A8R8G8B8,
D3DPOOL_DEFAULT,
D3DX_FILTER_NONE,D3DX_DEFAULT,0,NULL,NULL,
&(pStatData->m_Texture)))after about 300 hundred textures from files it this returns
D3DERR_OUTOFVIDEOMEMORY. sizes are: I check the height (which is rounded to power of 2) of the returned texture at surface level 0. first 100 textures of varying sizes, often small, 32 or 64 height on avergae. then 200 textures all with 256 height. I make sure torelease()unused textures anddirectXresources and not making memory leaks in general. The answer can be: 1. I should set some flag to make this all work. 2. I should load big textures with multiple images in them. 3. I'm passing some hard limit and I must cut down in the size of image resources. -
this is what i'm doing:
m_pD3D = Direct3DCreate9( D3D_SDK_VERSION )
...
D3DPRESENT_PARAMETERS d3dpp;
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;
m_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING,
&d3dpp, &m_pd3dDevice )...
D3DXCreateTextureFromFileEx(m_pd3dDevice, pSrcFile.c_str()
,D3DX_DEFAULT,
D3DX_DEFAULT ,
D3DX_DEFAULT,
D3DUSAGE_RENDERTARGET,
D3DFMT_A8R8G8B8,
D3DPOOL_DEFAULT,
D3DX_FILTER_NONE,D3DX_DEFAULT,0,NULL,NULL,
&(pStatData->m_Texture)))after about 300 hundred textures from files it this returns
D3DERR_OUTOFVIDEOMEMORY. sizes are: I check the height (which is rounded to power of 2) of the returned texture at surface level 0. first 100 textures of varying sizes, often small, 32 or 64 height on avergae. then 200 textures all with 256 height. I make sure torelease()unused textures anddirectXresources and not making memory leaks in general. The answer can be: 1. I should set some flag to make this all work. 2. I should load big textures with multiple images in them. 3. I'm passing some hard limit and I must cut down in the size of image resources.Your description suggests an unidentified memory leak. Look for something that's not being freed. Maybe delete needs to be called for one of these objects. If you can't find it, you can try the Signal Flare debugging pattern: Here, for one statement that allocates something, temporarily replace it with a loop that allocates 50 of them. Free the 50 where you were originally freeing the single object. Then run your program and count how many textures it takes to run out of memory. If it's 300, that statement isn't the memory leak, so go on to the next one. If it runs out of memory after 6 textures (300 / 50), you've found the leak.
-
this is what i'm doing:
m_pD3D = Direct3DCreate9( D3D_SDK_VERSION )
...
D3DPRESENT_PARAMETERS d3dpp;
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;
m_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING,
&d3dpp, &m_pd3dDevice )...
D3DXCreateTextureFromFileEx(m_pd3dDevice, pSrcFile.c_str()
,D3DX_DEFAULT,
D3DX_DEFAULT ,
D3DX_DEFAULT,
D3DUSAGE_RENDERTARGET,
D3DFMT_A8R8G8B8,
D3DPOOL_DEFAULT,
D3DX_FILTER_NONE,D3DX_DEFAULT,0,NULL,NULL,
&(pStatData->m_Texture)))after about 300 hundred textures from files it this returns
D3DERR_OUTOFVIDEOMEMORY. sizes are: I check the height (which is rounded to power of 2) of the returned texture at surface level 0. first 100 textures of varying sizes, often small, 32 or 64 height on avergae. then 200 textures all with 256 height. I make sure torelease()unused textures anddirectXresources and not making memory leaks in general. The answer can be: 1. I should set some flag to make this all work. 2. I should load big textures with multiple images in them. 3. I'm passing some hard limit and I must cut down in the size of image resources.It seems you are trying to acquire the video memory more than that actually available, even though you are making sure to release the unused textures, still the required texture may requires more memory. you need to have an algorithmn to make sure reasonable number of textures which is most used by tracking the available video memory and remaining texture to be loaded to video memory whenever needed by releasing the least used one. That you need efficient direct3d resource management alogorithmn. see [Automatic Texture Management ^] say if you load all the textures at once 50 * 32 * 32 * 4 + 50 * 64 * 64 * 4 + 200 * 256 * 256 * 4 = 50 MB, while reasonable video memory of GPU is 64 MB, 50 MB is huge size only for textures. BTW, do you need this D3DUSAGE_RENDERTARGET flag, it is used if you want to render to texture.
-
Your description suggests an unidentified memory leak. Look for something that's not being freed. Maybe delete needs to be called for one of these objects. If you can't find it, you can try the Signal Flare debugging pattern: Here, for one statement that allocates something, temporarily replace it with a loop that allocates 50 of them. Free the 50 where you were originally freeing the single object. Then run your program and count how many textures it takes to run out of memory. If it's 300, that statement isn't the memory leak, so go on to the next one. If it runs out of memory after 6 textures (300 / 50), you've found the leak.
-
It seems you are trying to acquire the video memory more than that actually available, even though you are making sure to release the unused textures, still the required texture may requires more memory. you need to have an algorithmn to make sure reasonable number of textures which is most used by tracking the available video memory and remaining texture to be loaded to video memory whenever needed by releasing the least used one. That you need efficient direct3d resource management alogorithmn. see [Automatic Texture Management ^] say if you load all the textures at once 50 * 32 * 32 * 4 + 50 * 64 * 64 * 4 + 200 * 256 * 256 * 4 = 50 MB, while reasonable video memory of GPU is 64 MB, 50 MB is huge size only for textures. BTW, do you need this D3DUSAGE_RENDERTARGET flag, it is used if you want to render to texture.
Thank you. I made an experiment with calling
D3DXCreateTextureFromFileEx()on 10 PNG images of size 8192X8192 and received no error code.Rajkumar R wrote:
say if you load all the textures at once 50 * 32 * 32 * 4 + 50 * 64 * 64 * 4 + 200 * 256 * 256 * 4 = 50 MB, while reasonable video memory of GPU is 64 MB, 50 MB is huge size only for textures.
This should be about 260 MB so it doesn't seem like actual GPU mem is a concrete limit on the texture memmory size. Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (
m_pSprite->Draw()) which is the only thing I do with the textures. Another thing is trying to load 290 of those giant textures (maybe 300 is some strange number of resources limit).Rajkumar R wrote:
BTW, do you need this D3DUSAGE_RENDERTARGET flag, it is used if you want to render to texture.
I changed to
D3DUSAGE_DYNAMIC. Loading textures still stopped at the same image in the series (actually exactly 1 image less), BUT, some error relating toID3DXFont(using`ID3DXFont::DrawText()`suddenly draw some wacky straight scribbles that resemble the actual text) that I had and had a reason to believe happened because of my "texture loading abuse" was fixed. -
Thank you. I made an experiment with calling
D3DXCreateTextureFromFileEx()on 10 PNG images of size 8192X8192 and received no error code.Rajkumar R wrote:
say if you load all the textures at once 50 * 32 * 32 * 4 + 50 * 64 * 64 * 4 + 200 * 256 * 256 * 4 = 50 MB, while reasonable video memory of GPU is 64 MB, 50 MB is huge size only for textures.
This should be about 260 MB so it doesn't seem like actual GPU mem is a concrete limit on the texture memmory size. Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (
m_pSprite->Draw()) which is the only thing I do with the textures. Another thing is trying to load 290 of those giant textures (maybe 300 is some strange number of resources limit).Rajkumar R wrote:
BTW, do you need this D3DUSAGE_RENDERTARGET flag, it is used if you want to render to texture.
I changed to
D3DUSAGE_DYNAMIC. Loading textures still stopped at the same image in the series (actually exactly 1 image less), BUT, some error relating toID3DXFont(using`ID3DXFont::DrawText()`suddenly draw some wacky straight scribbles that resemble the actual text) that I had and had a reason to believe happened because of my "texture loading abuse" was fixed.Hanan888 wrote:
Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (m_pSprite->Draw()) which is the only thing I do with the textures.
Some interesting stuff: the 8192X8192 is probably scaled down to 2048X2048. This I suspect from checking the surface level 0 description. Also, from easy to see differences when drawing a portion of the texture. When changed the size of image to 2048X2048, the part drawn looked similar to the original file.
-
Hanan888 wrote:
Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (m_pSprite->Draw()) which is the only thing I do with the textures.
Some interesting stuff: the 8192X8192 is probably scaled down to 2048X2048. This I suspect from checking the surface level 0 description. Also, from easy to see differences when drawing a portion of the texture. When changed the size of image to 2048X2048, the part drawn looked similar to the original file.
Hanan888 wrote: Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (m_pSprite->Draw()) which is the only thing I do with the textures.
Hope this is of any interest to you :) * I've
g_pSprite->Draw()on a 225X225 portion of the 2048X2048 texture, 10,000 times during myrender(). Firstrender()took 4-5 milisec, next ones 1-2 milisec. no error ever happened. * but I noticed my system start to sweat after 100draw()forrender(). which is great. * when offseting outside of original & surface level 0 source rectangle ( I mean wehre they are equal as in the 2048X2048 case) (ID3DXSprite::Draw(pTexture,RECT(4000,4225,4000,4225),..)) no error returned and some unrelated yet consistent pattern is shown (which was some khaki color). when doing this using the 8192X8192 some other unrelated pattern shown (that one was a little darker). And bottom line I must know the size that will show my images 'as is'. -
Thank you. I made an experiment with calling
D3DXCreateTextureFromFileEx()on 10 PNG images of size 8192X8192 and received no error code.Rajkumar R wrote:
say if you load all the textures at once 50 * 32 * 32 * 4 + 50 * 64 * 64 * 4 + 200 * 256 * 256 * 4 = 50 MB, while reasonable video memory of GPU is 64 MB, 50 MB is huge size only for textures.
This should be about 260 MB so it doesn't seem like actual GPU mem is a concrete limit on the texture memmory size. Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (
m_pSprite->Draw()) which is the only thing I do with the textures. Another thing is trying to load 290 of those giant textures (maybe 300 is some strange number of resources limit).Rajkumar R wrote:
BTW, do you need this D3DUSAGE_RENDERTARGET flag, it is used if you want to render to texture.
I changed to
D3DUSAGE_DYNAMIC. Loading textures still stopped at the same image in the series (actually exactly 1 image less), BUT, some error relating toID3DXFont(using`ID3DXFont::DrawText()`suddenly draw some wacky straight scribbles that resemble the actual text) that I had and had a reason to believe happened because of my "texture loading abuse" was fixed.Hanan888 wrote:
I changed to D3DUSAGE_DYNAMIC
this also not needed in your case, simply put 0 (zero).
-
Hanan888 wrote: Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (m_pSprite->Draw()) which is the only thing I do with the textures.
Hope this is of any interest to you :) * I've
g_pSprite->Draw()on a 225X225 portion of the 2048X2048 texture, 10,000 times during myrender(). Firstrender()took 4-5 milisec, next ones 1-2 milisec. no error ever happened. * but I noticed my system start to sweat after 100draw()forrender(). which is great. * when offseting outside of original & surface level 0 source rectangle ( I mean wehre they are equal as in the 2048X2048 case) (ID3DXSprite::Draw(pTexture,RECT(4000,4225,4000,4225),..)) no error returned and some unrelated yet consistent pattern is shown (which was some khaki color). when doing this using the 8192X8192 some other unrelated pattern shown (that one was a little darker). And bottom line I must know the size that will show my images 'as is'.you just use the DirectX cap viewer to check the maximum texture size, MaxTextureWidth, MaxTextureHeight of [D3DCAPS9 Structure^], it should be some thing like 2048 X 2048, so the texture creation more than this dimension is ignored i think, so the total size is 10 * 2048 * 2048 *4 = 40 MB, not 260 MB (8192X8192). you just try a texture size of 1024x1024* 50 PNG = 200 MB. You cannot create texture more than the max texture size in D3DCAPS9.
Hanan888 wrote:
I've g_pSprite->Draw()
PS: use ID3DXSprite::Begin and end also otherwise every call to Draw() internally calls begin and end.
Hanan888 wrote:
* but I noticed my system start to sweat after 100 draw() for render().
Do you mean CPU temperature and CPU usage goes high, if so you are rendering in a tight loop, reduce the framerate to the reasonable framerate.
-
Hanan888 wrote:
I changed to D3DUSAGE_DYNAMIC
this also not needed in your case, simply put 0 (zero).
-
Thanks. Changing to zero was behaving, as far as I could see, like in D3DUSAGE_DYNAMIC. I need to find out how to make
D3DXCreateTextureFromFileEx()be equivalent toD3DXCreateTextureFromFile().