HDR Submits

...or is this even possible? I got the impression from the PCSDK talk at Connect 5 that you could submit in non OVR_FORMAT_R8G8B8A8_UNORM_SRGB formats but perhaps that is not the case?

"... can't get anything beyond the sample OVR_FORMAT_R8G8B8A8_UNORM_SRGB types to work... "
Could you give a bit more detail about the issues you're seeing?

Which rendering API are you using? If you're doing something invalid, you should get an error code back from the SDK with a brief explanation, and hopefully an error message in the render API as well. DX11 & 12 are usually better about giving error descriptions when using the DEBUG flag on device creation.

Several apps and engines (Unity, UE4) have been using the 11:11:10f format for a while now, and we've been supporting it for over 2 years now.

Cheers

Thanks for the reply. I'm using our custom engine (DX12) with the PC SDK. When creating the eye texture swapchain I'm setting the format descriptor to OVR_FORMAT_R11G11B10_FLOAT and using DXGI_FORMAT_R11G11B10_FLOAT to create the resources. There are no error messages and everything runs fine except the display in the headset just hangs on the "loading" panel...the headset still tracks and I can look around. It was suggested I use OVRManager.eyeTextureFormat to set the format however I'm not using Unity...I suspect this simply sets the eye texture format descriptors as I'm doing manually? I guess what I was wondering is if there was somewhere else that the session needed to be told of the input format and as a result it's default was still expecting OVR_FORMAT_R8G8B8A8_UNORM_SRGB. 

Thanks for the reply. I'm using our custom engine (DX12) with the PC SDK. I'm setting the eye texture description using OVR_FORMAT_R11G11B10_FLOAT and creating the swapchain resources with DXGI_FORMAT_R11G11B10_FLOAT...a simple modification to the OculusEyeTexture structure in the samples. The system runs fine and does not throw any errors except the display in the headset hangs on the "loading" panel although the headset is still tracking and I can look around in the loading 'room'. It was suggested that I use  OVRManager.eyeTextureFormat however I'm not using Unity and I suspect that it's just doing the same thing as setting the formats manually? What I was wondering is if there's somewhere/somehow else that I need to let the session know that I'm submitting a OVR_FORMAT_R11G11B10_FLOAT format and it's hanging because the default is expecting OVR_FORMAT_R8G8B8A8_UNORM_SRGB?  

There are a good deal of tweaks you'd have to do to make sure 11:11:10f works with the ORT DX12 sample. For example, you'd need to remove the typeless flag which is incompatible with that format and make sure anywhere you see the 8-bit format being used to change as well while also correcting for the sRGB gamma. Also you'd need to tweak the formats used in the Win32_DirectX12AppUtil.h file. If you query for the SDK errors, you'd see the "typeless flag not compatible" error being thrown. What's probably happening is that the swap chain is failing to be created causing the sample to not be able to submit any valid textures to the SDK. This is why it'd be "stuck" on the loading screen because there's no valid imagery coming from the sample app to show.

Suffice it to say, 11:11:10f works with the SDK. You just need to make sure your app is playing with the format nicely.

Thanks again for the feedback, I'll dig a little deeper and see how it goes. Cheers

Still no luck...I can create with OVR_FORMAT_R16G16B16A16_FLOAT no problem. When trying OVR_FORMAT_R11G11B10_FLOAT I initially get the "Typeless flag not compatible" error as suggested. Once I changed the Flag I get the following error:

After a bit of digging on my part, turns out this is a limitation in sharing textures between DX11 and DX12.

See this link: https://docs.microsoft.com/en-us/windows/desktop/direct3d11/direct3d-11-1-features#extended-support-for-shared-texture2d-resources

You'll see a number of supported formats including 16-bit float, but no 11:11:10f. Looks somewhat arbitrary that Microsoft would decide to exclude a number of formats from that list.

Thanks for finding and reporting this. We'll see if Microsoft is willing to expand their support for the ExtendedResourceSharing formats, or find a way around this limitation.

Cheers

Thank you for looking into this. I had tried using 11:11:10 even in our non-VR swapchain and was seeing the same issues, however DXGI_FORMAT_R10G10B10A2_UNORM worked just fine with DX12...

Just be aware that 10-bit is linear and will give you results that are worse than 8-bit sRGB due to how the linear nature of the format works. So I personally wouldn't recommend using it.