locked
CreateTexture2D returns E_OUTOFMEMORY on Surface RT

    Question

  • We're testing our app on Surface RT and find our app crashes when rendering large texture image (3200x1600 pixels). Debugging the code reveals that the function call CreateTexture2D returns E_OUTOFMEMORY. I do not post our code in this thread as we're confident in our code that works well on a number of Windows 8 and Windows 7 x86 laptops. I guess the issue may result from the fact that Surface RT only support DirectX9 feature level. But I fail to find on the web what's maximum texture dimension supported by DirectX9. Could some one help?
    Wednesday, February 20, 2013 3:31 PM

Answers

  • Note that there's a 'minimum' required 'maximum texture size' based on device feature level, but in theory the device is free to support larger sized textures if it wants. This is why the DDSTextureLoader code in DirectXTK (and the standalone version in the DirectXTex package) will first try to use whatever size is in the DDS first before stripping it to the minimum required by the feature level.

    Surface RT is a Feature Level 9.1 part and FL 9.1 only requires a maximum size of 2048 x 2048. The NVIDIA Tegra 3 graphics part in the Surface RT in fact only supports a maximum of 2048x2048 textures.

    E_OUTOFMEMORY of course also depends on how many other resources you have active at the same time, and what format you are using.

    • Marked as answer by Leonard Thursday, February 21, 2013 9:43 AM
    Wednesday, February 20, 2013 8:15 PM

All replies

  • The Direct3D feature levels documentation includes a table with that information.

    --Rob

    Wednesday, February 20, 2013 8:05 PM
    Owner
  • Note that there's a 'minimum' required 'maximum texture size' based on device feature level, but in theory the device is free to support larger sized textures if it wants. This is why the DDSTextureLoader code in DirectXTK (and the standalone version in the DirectXTex package) will first try to use whatever size is in the DDS first before stripping it to the minimum required by the feature level.

    Surface RT is a Feature Level 9.1 part and FL 9.1 only requires a maximum size of 2048 x 2048. The NVIDIA Tegra 3 graphics part in the Surface RT in fact only supports a maximum of 2048x2048 textures.

    E_OUTOFMEMORY of course also depends on how many other resources you have active at the same time, and what format you are using.

    • Marked as answer by Leonard Thursday, February 21, 2013 9:43 AM
    Wednesday, February 20, 2013 8:15 PM
  • Thank you two. I downscale the texture image conditionally and the issue is solved.
    Thursday, February 21, 2013 9:43 AM
  • I had the same problem.

    It turned out I kept creating texture resources when I only needed one  and then update it.

    The game would run for 30 seconds then I would get an "out of memory" error message.


    n.Wright

    Friday, September 20, 2013 9:58 PM
  • I had the same problem.

    It turned out I kept creating texture resources when I only needed one  and then update it.

    The game would run for 30 seconds then I would get an "out of memory" error message.


    n.Wright

    I also had trouble with a texture buffer called buf.

    I found I had to delete it at the end end of the render routine delete[] buf;


    n.Wright


    Saturday, September 28, 2013 9:25 PM
  • I was also not releasing objects.

    I found after use I had to release the texture and the shader.

    while(pSRView->Release()!=0)
    {
    	pSRView->Release();
    	pSRView=NULL;
    }
    
    
    
    	while( pTexture->Release()!=0)
    	{
    		pTexture->Release();
    		pTexture=NULL;
    	}


    n.Wright

    Thursday, October 17, 2013 3:13 PM
  • If I remember correctly the texture max size is 8192by 8192 pixels.


    n.Wright

    Thursday, October 17, 2013 3:13 PM
  • This thread is about a Surface RT. That is a Feature Level 9.1 device which has a maximum texture size of 2048 x 2048.

    http://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx

    Saturday, October 19, 2013 8:02 AM
  • I was also not releasing objects.

    I found after use I had to release the texture and the shader.

    while(pSRView->Release()!=0)
    {
    	pSRView->Release();
    	pSRView=NULL;
    }
    
    
    
    	while( pTexture->Release()!=0)
    	{
    		pTexture->Release();
    		pTexture=NULL;
    	}


    n.Wright

    Note that your code will crash with a NULL pointer reference if ->Release() ever returns a nonzero value. What you want is something like this:

    while( pSRView->Release() != 0 );
    pSRView = NULL;
    However, you should never loop on ->Release(). You'll rip the object out from underneath any other code that holds a reference to it and your app will crash.


    • Edited by henador Sunday, October 20, 2013 3:40 PM Remove ->Release() in while body
    Saturday, October 19, 2013 12:55 PM
  • Thanks for the advice but the code always creates a texture and a shader so they wont ever be null.


    n.Wright

    Saturday, October 19, 2013 8:18 PM
  • Thanks for the advice but the code always creates a texture and a shader so they wont ever be null.


    n.Wright


    You set pSRView = NULL in the body of the loop. If the body of the loop ever gets executed (because pSRView->Release() returns a nonzero value in the while() ) then your code will crash when it loops around to test while( pSRView->Release() != 0 ) again. Don't believe me? Do an AddRef just before the while() statement and see what happens.
    Sunday, October 20, 2013 2:50 PM
  • You should never release a COM object more than you actually took ownership of it. As noted by the other poster, the loop is also invalid.

    If you don't take the time to read the material I linked to and actually understand how reference counting works, you are going to have nothing but pain trying to use COM-based APIs like Direct3D.

    Sunday, October 20, 2013 7:20 PM
  • I studied the problem a little

    If you release more than you assign then the refcount starts to become negative.

    However this didn't seem to cause a problem. But I guess eventually it will become positive and then might cause a problem.

    However, I now see the bug in my looped release code and only assign twice and release twice now.

    The code has tested fine.


    n.Wright

    Sunday, October 20, 2013 7:24 PM