Yes I'd think the OpenVR middleware API, which SteamVR implements against, runs it in this so called Direct Mode, and many people are actually having very decent performance with this setup.
If there is an FPS hit it could come from the fact that, as we just recently found out from Mr.Brooks, Elite supersamples by default for the Vive. And since that's inherentily OpenVR, it might do so on the rift as well. To be honest it doesn't look like there's a huge diference in perceived resolution between ED and other demos on the CV1 sample I have so i've no idea..
Other than that it makes big sense that with OpenVR things are able to work

To understand why I'd have to explain what a composer is, how it's used, what data types it expects,
when it expects them* and such..
However it doesn't make sense that it's absolutely trouble-free.
And indeed in my successful attempts at using 0.8 & openVR, the CV1 sample had weird artifacts when running in this botched mode.
*I think this is where FD has the issue.
It's obtaining all the layers in the right depth order at the right time. It's an architectural thing and probably involves changing a lot of loop/observer mechanisms.
- - - - - Additional Content Posted / Auto Merge - - - - -
I wonder if "actively working with Oculus" means they have the version 1 runtime and a CV1 dev kit... or if it means they keep asking for them and Oculus laughs while waving their Eve Valkyrie contract in FD's face?
They definitely have access to the latest SDK 1.0.
Apart from that a CV1 sample shouldn't be necessary to just "get it to work". It could be used in verifying it's really fixed and/or tweak values