RenderTarget9::RenderTarget9's device->CreateRenderTarget returns D3DERR_INVALIDCALL

[GoogleCodeExporter]

This looks similar to issue 199.

https://bugzilla.mozilla.org/show_bug.cgi?id=847714

I'm hitting this assert when testing some resize-from-too-large-webgl-buffer 
patches for Firefox:
Assertion failed: (((HRESULT)(result)) >= 0), file 
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\gfx\angle\src\libGLESv
2\renderer/d3d9/RenderTarget9.cpp, line 101

This is as part of a series of calls creating very large 4xMSAA GLRenderbuffers.
Requests which complete without error:
50x50 4-sample RB
16384x12 4-sample RB

Causes D3DERR_INVALIDCALL:
16384x16384 4-sample RB

These are the reported limits:
mMaxTextureSize: 16384
mMaxRenderbufferSize: 16384
mMaxViewportDims: 16384x16384
mMaxSamples: 8

It seems that this code should anticipate the possibility of getting 
D3DERR_INVALIDCALL here, and throw a GL_OOM.

Original issue reported on code.google.com by jda...@gmail.com on 6 Aug 2014 at 1:07

[GoogleCodeExporter]

So stuff's moved around considerably since this was filed, but it looks like we 
still only check for OUTOFMEMORY errors on CreateRenderTarget(View) calls in 
both DX9 and DX11.

We should probably either add the INVALIDARG/INVALIDCALL case, or be doing 
checks against the max supported render target dimensions before they reach 
CreateRenderTarget. That D3D is returning INVALID errors on these calls implies 
that they expect us not to pass out-of-caps values here. (Would be interesting 
to determine whether the response differs between DX9 and DX11.)

(Semi-relatedly-- it looks like we don't even check for OOM conditions after 
render target creation in the swap chain classes. It might be prudent to add 
checks there.)

Original comment by shannonw...@chromium.org on 29 Jan 2015 at 11:18

• Changed state: Accepted