Forum Discussion
LibOVR DX12 is half broken ( with tinyroom code patch to repro )
Hello,
At first everything was fine, i packed my two eyes in a single surface, then i tried to use one swapchain per eye and LibOVR cross the streams... :( After that only the left eye display something that is in that the right eye, the other is black, after messing around and turning mad on very weird behaviors, i tried to repro in OculusRoomTinyDX12 and yes, i am not crazy, two line changes and i get the same behavior. And of course the two line changes are absolutely legit in regards to DX12, of course.
So in MainLoop function, at the for loop over the two eyes, you just have to move "DIRECTX.SetActiveContext(eye == 0 ? DrawContext_EyeRenderLeft : DrawContext_EyeRenderRight);", remove the eye test and just pick a context. And at the end of the loop, move "DIRECTX.SubmitCommandList(DIRECTX.ActiveContext);" just after the for loop.
Technically, it means that you are rendering the full frame in a single CommandList ( much like DX11 immediate context ), it is absolutely legit, all the barriers remains intact, the OVRCommit is called prior ExecuteCommandList so nothing has change here too.
At first everything was fine, i packed my two eyes in a single surface, then i tried to use one swapchain per eye and LibOVR cross the streams... :( After that only the left eye display something that is in that the right eye, the other is black, after messing around and turning mad on very weird behaviors, i tried to repro in OculusRoomTinyDX12 and yes, i am not crazy, two line changes and i get the same behavior. And of course the two line changes are absolutely legit in regards to DX12, of course.
So in MainLoop function, at the for loop over the two eyes, you just have to move "DIRECTX.SetActiveContext(eye == 0 ? DrawContext_EyeRenderLeft : DrawContext_EyeRenderRight);", remove the eye test and just pick a context. And at the end of the loop, move "DIRECTX.SubmitCommandList(DIRECTX.ActiveContext);" just after the for loop.
Technically, it means that you are rendering the full frame in a single CommandList ( much like DX11 immediate context ), it is absolutely legit, all the barriers remains intact, the OVRCommit is called prior ExecuteCommandList so nothing has change here too.
2 Replies
- hi,
I don't think you can just change these two lines: Without synchronization only one constant buffer will be active when rendering. I haven't debugged, but probably that way you just render the same image twice.
On the other hand, I completely agree that the design of oculus SDK DX12 render path is questionable. The old DX11 way of more or less just providing a texture seemed much more easy to fit to any engine design. Now for DX12 we have to use the oculus generated swap chain which IMO made using it much more complex than it has to be. I was really close to just living with the old D11over12 design and stick with my own swapchain and RTVs. But that felt also bad - not with regards to performance, only design-wise. I ended up introducing a lot of conditional coding that uses my own swapchain only in non-VR mode and the oculus SDK provided swapchain when VR rendering is turned on. - They don't have any fencing between the original two command list so what so ever happen to their constant buffer should be correct.
And the bug behavior match my problem too, my sample is definitely doing things right here.
I have little to say about the interface now. It would have been nice to expose a way to alias the swapchain resource for dynamic resolution or gpu feed the tracking data (still have to try my late cpu wakeup from gpu thing), and the waitable for the swapchain to need a new frame, to move the vsync wait from submitframe to the begining of the update, a win for latency.
