[modeless]

Rendering the scene twice has overhead, so it would take extra time even if it was the same number of pixels total. But that's far from the only reason VR requires more power.

Due to the distortion caused by the lenses the scene must be rendered at about 1.4x the normal resolution. Then there's a warping step that performs the inverse of the lens distortion, which is an additional cost. Also, good VR requires rendering at 90 Hz, not 60 Hz, so that's another 1.5x. Furthermore, frame tearing artifacts and FPS hiccups are much worse in VR, so you need extra headroom to eliminate them even in worst-case scenarios.

[jo_]

I remember being surprised that the bottleneck for some modern devices (like cell phones) wasn't the number of vertices one could push, but rather the fill rate and number of draw calls. Do consoles these days hit performance bounds as a function of the number of draw calls rather than the number of polygons/vertices?

I ask because I can completely understand how doubling the number of draw calls could be problematic in a VR situation.

[modeless]

Mobile devices are often limited by memory bandwidth, and by OpenGL driver overhead. Consoles have very little driver overhead, so number of draw calls is not as big a problem, but state changes are still costly, so doubling the number of state changes hurts performance. I could imagine some clever techniques to avoid doubling the number of state changes (perhaps a geometry shader that duplicates triangles to render both eyes at once) but I don't know how well that would work. VR rendering is still mostly unexplored!

[sbierwagen]

  Also, good VR requires rendering at 90 Hz

The DK2 can only do 75 Hz. Anything more than that is wasted.

[modeless]

DK2 isn't good enough. That's why it isn't the consumer version already. Palmer has said in interviews that the consumer version will be higher resolution and higher frame rate. The higher frame rate is required to enable low enough persistence without flickering.