Problems Using DXGI FORMAT R8G8B8A8 UNORM SRGB

[DougChism]

I am having a very odd issue using a swapchain in OpenXR using DXGI_FORMAT_R8G8B8A8_UNORM_SRGB. It works fine with DXGI_FORMAT_R8G8B8A8_UNORM, however I get banding on the final image which is to be expected according to the documentation.

The problem is that, both the headset and the WMR simulator will not render using DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, I get just a black screen and the controllers drawing to the screen as if the headset is not receiving images. I have simplified my application to where all I do is clear the render target to red, and it still has the problem. There is no error or failure of any sort in and of the return values, just does not work. I have verified the image in the swapchain is correct by copying it and outputting it to a desktop window before submitting, looks correct in both DXGI_FORMAT_R8G8B8A8_UNORM and DXGI_FORMAT_R8G8B8A8_UNORM_SRGB.

I have also enumerated the swapchain formats and its on the list. Any ideas on what could cause this? The WMR OpenXR sample app ( which is pretty difficult to follow I must say ) uses the SRGB swapchain and it seems to work fine, so there is some trick I am not doing.

[Dark_Photon]

@DougChism

I am having a very odd issue using a swapchain in OpenXR …

It works fine with DXGI_FORMAT_R8G8B8A8_UNORM…

The problem is that, both the headset and the WMR simulator will not render using will not render using DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, I get just a black screen and the controllers drawing to the screen as if the headset is not receiving images.

Which WMR headset and Windows 10 update version are you using?

Have you checked your app against the WMR OpenXR sRGB tips here?

• OpenXR app best practices

That is, ensured that both your Swap Chain and Render Target View are sRGB (…unless your app is doing the conversion from sRGB → RGB manually)?

@WMR OpenXR app best practices

Gamma-correct rendering

Care must be taken to ensure that your rendering pipeline is gamma-correct. When rendering to a swapchain, the render-target view format should match the swapchain format. For example, DXGI_FORMAT_B8G8R8A8_UNORM_SRGB for both the swapchain format and the render-target view. There’s an exception if the app’s rendering pipeline does a manual sRGB conversion in shader code. The app should request an sRGB swapchain format but use the linear format for the render-target view. For example, request DXGI_FORMAT_B8G8R8A8_UNORM_SRGB as the swapchain format but use DXGI_FORMAT_B8G8R8A8_UNORM as the render-target view to prevent content from being double-gamma corrected.

It’s interesting that they call out use of BGRA rather than RGBA. If that’s supported as well, you could give that a shot.

And to help others searching find this thread, I gather that you are trying to render to a Windows Mixed Reality (WMR) Headset or the Windows Mixed Reality Simulator using Direct3D using sRGB and getting a black screen. Whereas rendering with standard RGB works fine. However, with your setup, the Windows Mixed Reality OpenXR sample app displays properly when rendering to an sRGB target. And when calling xr::EnumerateSwapchainFormats(), your app has verified that DXGI_FORMAT_R8G8B8A8_UNORM_SRGB is supported.

• Windows Mixed Reality : Getting started with OpenXR
• Windows Mixed Reality : OpenXR Sample App Source Code
• Windows Mixed Reality : OpenXR app best practices
• Windows Mixed Reality : OpenXR
• Windows Mixed Reality : OpenXR Dev Tools

[DougChism]

So I was able to fix this problem and it was completely unrelated to the SRGB texture format, but for some reason the SRGB texture format highlighted the issue. The problem was a very long first frame causing a sort desynchronization with the headset. In our simulator, we do a lot of work the first frame for instance, rendering terrain height maps for the tesselator, baking low resolution shadows in the far distance, so the first rendering frame can often take 20-30 seconds. This apparently is a no-no for VR, so I just start rendering VR after the first frame when all this stuff is complete that solves the issue. I have no idea why switching to that texture type caused the problem to come to a head, or why I guess you could say it worked fine the original way. Its a shame OpenXR does not spit out some sort of error when it feels like it has desynchronized, instead of just rendering black and the controllers. Sim runs great now and no banding like before.