Possible bug with DirectX 11 — misuse of ResolveSubresource?

[rogual]

I think bgfx might be making an illegal API call which happens to work on some hardware. I use bgfx to save myself from having learn DirectX, though, so I'm not 100% sure.

The issue happens when using BGFX_RESET_SRGB_BACKBUFFER and multisampling.

The DirectX 11 renderer is creating the backbuffer in a non-SRGB format and the MSAA render target in an sRGB format and expecting ResolveSubresource to do the gamma correction, which according to my reading of MS docs is illegal, and it fails on one of my test machines.

Full details

Non-sRGB backbuffer

In RendererContextD3D11::init, We set m_scd.format to a non-sRGB format regardless of whether BGFX_RESET_SRGB_BACKBUFFER is set. There's a comment explaining why this is OK:

/* According to https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/converting-data-color-space ,
 * it is OK to create the backbuffer with m_fmt (a non- _SRGB format), and then create the render target view into it
 * with m_fmtSrgb (the _SRGB format of same), and it will work identically as if you had created the swapchain with
 * m_fmtSrgb as the backbuffer format.
 *
 * Moreover, it is actually not desirable to create the backbuffer with an _SRGB format, because that
 * is incompatible with the flip presentation model, which is desirable for various reasons including
 * player embedding.
 */

sRGB MSAA render target

Also in init, if we're doing multisampling, we create m_msaaRt, this time with an sRGB format, and there's another comment saying why this is OK:

/* According to https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/converting-data-color-space ,
 * ONLY the backbuffer from swapchain can be created without *_SRGB format, custom backbuffer should be created the same
 * format as well as render target view.
 */

Call to ResolveSubresource

Finally, in RendererContextD3D11::submit, we call

ResolveSubresource(backbufferColor, 0, m_msaaRt, 0, m_scd.format);

This will receive:

• Our backbufferColor which we created with a non-sRGB format, and
• Our m_msaaRt which we created with an sRGB format.

This seems to be illegal according to MS docs for ResolveSubResource:

[if] Source and destination are prestructured and typed, [then] Both the source and destination must have identical formats and that format must be specified in the Format parameter.

I have one test machine on which this call works anyway, and one (with a GeForce 425 M) which errors out on this call with:

D3D11 ERROR: ID3D11DeviceContext::ResolveSubresource: The Format is not the compatible with the Source Resource's format. Source Resource format is (0x5b, B8G8R8A8_UNORM_SRGB). Resolve Format is (0x57, B8G8R8A8_UNORM). [ RESOURCE_MANIPULATION ERROR #294: DEVICE_RESOLVESUBRESOURCE_FORMAT_INVALID]
D3D11: **BREAK** enabled for the previous message, which was: [ ERROR RESOURCE_MANIPULATION #294: DEVICE_RESOLVESUBRESOURCE_FORMAT_INVALID ]

[bkaradzic]

Can you modify some existing example to create repo for this issue?

[rogual]

Sure, here's a patch to hello world:

diff --git a/examples/00-helloworld/helloworld.cpp b/examples/00-helloworld/helloworld.cpp
index 884a9ab0a..ccf59dbde 100644
--- a/examples/00-helloworld/helloworld.cpp
+++ b/examples/00-helloworld/helloworld.cpp
@@ -27,7 +27,7 @@ public:
                m_width  = _width;
                m_height = _height;
                m_debug  = BGFX_DEBUG_TEXT;
-               m_reset  = BGFX_RESET_VSYNC;
+               m_reset  = BGFX_RESET_VSYNC | BGFX_RESET_SRGB_BACKBUFFER;
 
                bgfx::Init init;
                init.type     = args.m_type;

With that patch, just run it and press F8 to turn MSAA on. For me it errors as soon as I press F8.