DX12 Support?

Hoping for this too because I'm developing a new graphics engine and jump straight into D3D12. Well, OpenGL works anyway.

It's definitely on the radar, but I have no specific plans to share. Thanks.

what would really separate the oculus from all the other competitors who would eventually sell the same device is.. superior proprietary software that works directly with the graphics card companies maybe

kind of like how mac is with games with the same hardware but in Windows is far superior due to better support

"cybereality" wrote:
It's definitely on the radar, but I have no specific plans to share. Thanks.

Hope you also are working on Vulkan support as drivers are coming this year..
Would be nice Oculus supports D3D12/Vulkan ASAP..

"lamour42" wrote:
Hi,
Probably using the D3D11On12 device is the way to go, but I would very much like to have confirmation by Oculus that this will work, before I invest a lot of time into this.

For the record, i was also curious if this could work, because their no point to waste time on d3d11 anymore ! I manage to get my d3d12 render on the oculus with d3d11on12, but it is kind of tricky, below the finale montage. Flatten your belt :)

1. Create a d3d12 device and everything you need to render whatever you want (obviously).

2. One of my d3d12 resource is my final framebuffer, RTV+SRV capable, at the resolution the rift is setup with ovr_CreateSwapTextureSetD3D11

2. Use D3D11On12CreateDevice to create the fake ID3D11Device proxy and his immediate context and query the extra interface ID3D11On12Device from that device too.

3. Use CreateWrappedResource on the ID3D12Resource from (2), the states for bind, prev and next is all set to shader resource in my case.

4. Create a regular ID3D11Device, because the proxy does not work with ovr_CreateSwapTextureSetD3D11, and use it to create the TextureSet. Set the MiscFlags to D3D11_RESOURCE_MISC_SHARED.

5. Query the IDXGIResource interface from each texture2d in the TextureSet, and obtain their shared handle with GetSharedHandle

6. Use the fake D3D11 device and call OpenSharedResource to create a ID3DTexture2D from the Ovr texture2d share handle you got in (5).

7. We are almost done, to transfer the content, all you need now is :
7a. AcquireWrappedResources on (3)
7b. Call CopyResource on the fake11ImmediateContext to copy from the wrapped resource to the shared resource from (6)
7c. ReleaseWrappedResources on (3)

8. Call Flush on the fake11ImmediateContext, this is a requirements of shared resources.


If i did not make a mistake at writing the steps, and if you understand everything that i wrote, then you are all set.


So at the question "Is it possible?", the answer is yes, is it practical ? Until a real support for d3d12, it is better than nothing, but i fear that the Flush for example may introduce bad queue serialization in the driver.

You should be able to just use DX12 as you want, and generate compatible DX11/DX12 texturehandles via DXGI and just use them with the DX11 SwapTextures from the SDK (or get DX12 handles from those and render to them). Basically this is just a complicated form casting. Sometimes it becomes as complex as galopin decribed, but I guess there is an easyer way to do it. For example the CopyResource should be possible from the DX12 context as well ;)

Hey galopin,

well done indeed! Many thanks for that! As soon as the port of my DX11 code to DX12 is in a state where I want to (re-)introduce Rift support, I will try to follow your instructions.

Of course it would be better if Oculus would provide us with official DX12 support, but as you wrote, it is better than nothing. I wonder if the final SDK version will have DX12 support. If I take the almost non-existing official info for that matter as indication I am almost sure that the 1.0 SDK will come without DX12 support. Your infos might be worth a lot in that case!

Hi lamour,

No problem man. I did it for me in the first place. I tried to simplify, but it looks like it is really the simplest form possible to get it to work.

The thing is DX12 give far more freedom to the developers, high priority queues, fences, transition barriers, and this will definitely require a thinner interface to the oculus to let developers inline it into their pipeline.

What is really the thing that everyone working on a big VR project should consider is the control over multi gpu environment, to manually render each eye on a different gpu to save time. This is a big addition of dx12, explicit multi gpu.