CreateRenderTarget returns 0x80070057 in big surface resolution

Question

I have created the SLI merged desktop of three 1920x1680 monitors, so the desktop resolution is 5760x1080.

There is a 0x80070057 error, while calling CreateRenderTarget to create the RT_Surface:

IDirect3DSurface9* _render_surface;
HRESULT hr = _device->CreateRenderTarget(
        _desktop_width * 2,
        _desktop_height + 1,
        D3DFMT_A8R8G8B8, 
        D3DMULTISAMPLE_NONE, 
        0,
        TRUE,
        &_render_surface, NULL);

It works OK with desktop resolution 1024x768, and the total resolution is 3072x768.

In http://msdn.microsoft.com/en-us/library/windows/desktop/bb174361(v=vs.85).aspx, it says

If the method succeeds, the return value is D3D_OK. If the method fails, the return value can be one of the following: D3DERR_NOTAVAILABLE, D3DERR_INVALIDCALL, D3DERR_OUTOFVIDEOMEMORY, E_OUTOFMEMORY.

and no description about 0x80070057.

HRESULT: 0x80070057 (2147942487)
Name: E_INVALIDARG
Description: An invalid parameter was passed to the returning function

Somebody please help me.

---

I tried to check MaxTextureWidth and MaxTextureHeigh in D3DCAPS9 structure as @mh01 indicated, and got the value 8192 both. And what I trying to create is 11520x1080.

So, my question is what effects the value of MaxTextureWidth and MaxTextureHeigh? VideoCard model or some setting in the BIOS?

---

I got the below information as @RayDey said, while turn on the debug level:

Direct3D9: (INFO) :======================= Hal HWVP device selected
Direct3D9: (INFO) :HalDevice Driver Style b
Direct3D9: :Subclassing window 000d0612
Direct3D9: :StartExclusiveMode
Direct3D9: (INFO) :Using FF to VS converter
Direct3D9: (INFO) :Using FF to PS converter
Direct3D9: (INFO) :Enabling multi-processor optimizations
Direct3D9: (INFO) :DDI threading started
D3D9 Helper: Warning: Default value for D3DRS_POINTSIZE_MAX is 2.19902e+012f, not 9.2074e-316f. This is ok.
Direct3D9: :WM_ACTIVATEAPP: BEGIN Deactivating app pid=00000c9c, tid=00000728
Direct3D9: :DoneExclusiveMode
Direct3D9: :INACTIVE: 00000c9c: Restoring original mode (1680x1050x22x120) at adapter index 0
Direct3D9: :* Active state changing
Direct3D9: :WM_ACTIVATEAPP: DONE Deactivating app pid=00000c9c, tid=00000728
Direct3D9: (ERROR) :Failed to create driver surface
Direct3D9: (ERROR) :Error during initialization of surface. CreateRenderTarget/CreateDepthStencil failed
Direct3D9: (ERROR) :Failure trying to create render-target
D3D9 Helper: IDirect3DDevice9::CreateRenderTarget failed: E_INVALIDARG

Answer 1

The GPU is telling you it can't create textures larger than 8192 in either dimension, and you're trying to create one that's 11520 wide. It's not going to work. This is likely to be a limitation of the GPU itself, not something you can work around with some hackery or a different driver. For instance, the GPU's texture units might only have enough bits in their address registers to store texture coordinates up to 8192.

Answer 2

A good (also widely used) workaround to this problem is to create multiple render targets of a size that your GPU supports, render your scene in pieces, and assemble on your back buffer(s). The downside to this is, you'll effectively render your scene N times (where N is your # of render targets), but with proper scene preprocessing, this may not be as bad as it sounds.

Answer 3

Check MaxTextureWidth and MaxTextureHeight in your D3DCAPS9 (using IDirect3D9::GetDeviceCaps or IDirect3DDevice9::GetDeviceCaps) - the most likely cause is that your MaxTextureWidth is 4096.

Even if it's larger it's still possible for a Create* call to fail - you may not have enough video RAM, or your driver may not be allocate a large enough region of video RAM. I wouldn't expect an E_INVALIDARG from that though.

You can specify D3DCREATE_DISABLE_DRIVER_MANAGEMENT in your CreateDevice call which stipulates that "Direct3D will manage resources instead of the driver. Direct3D calls will not fail for resource errors such as insufficient video memory." What exactly happens if you do run out is another matter though, so it may be a bit risky. Plus, as I indicated above, this is most likely not a case of running out, so it's not really relevant.