cancel
Showing results for 
Search instead for 
Did you mean: 

Eye-per-frame mode in 0.6

jherico
Adventurer
One optimization technique I've used in ShadertoyVR is the ability to turn on eye-per-frame mode, where each frame renders to one eye buffer only, alternating between left and right. This relies on the use of timewarp to reorient the remaining eye and still present a reasonable scene. For some shaders this is perfectly sufficient to produce a good user experience.

Some of the shaders will bring the GPU to it's knees, so you end up having to lower the resolution using dynamic framebuffer scaling. By allowing users to turn on eye-per-frame mode, you're able to effectively double the resolution at which a heavyweight shader can run and still achieve 75 FPS.

But so far I haven't been able to implement eye-per-frame mode in the new SDK. The submit function provides both textures to the compositor which effectively locks them so I can no longer use them. Simply failing to increment the swap texture set CurrentIndex on the eye I didn't render doesn't seem to work properly.

I was going to try blitting each eye as I rendered it into the next texture in to FBO, but this doesn’t seem to work as any attempt to make an FBO out of a texture that isn’t referred to by CurrentIndex generates and error when you try to use it. I’m going to assume what’s happening has something to do with the way you’re calling wglDXLockObjectsNV and wglDXUnlockObjectsNV. It seems like what might be happening is that you’re only locking the item you anticipate will be the next texture written to (i.e. you lock the first texture in a swap on creation, then unlock it on submit and lock the next one).

I would consider the fact that I can’t create a valid FBO with an arbitrary color texture in the swap texture set after creation to be a bug. If you intend to maintain that design, you should probably also take responsibility for manipulating CurrentIndex on the call to submit, if you're going to make assumptions about how it will be manipulated anyway.

So right now the only way I can see to do eye-per-frame would be to create two texture swap sets, both big enough to contain both eye views, and then use framebuffer blitting to copy individual eye views between the two, and switch off which one I send in each submit call. This seems needlessly costly (certainly in memory). Is there any possibility of adding functionality to the submit call that tells the rendering system to simply use the last submitted frame for one of the eyes?
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
1 REPLY 1

DeanOfTheDriver
Protege
Is there any possibility of adding functionality to the submit call that tells the rendering system to simply use the last submitted frame for one of the eyes?


That exists today. There's no requirement that one needs to update all texture sets per frame. You can even call SubmitFrame having not updated any of the texture sets.