I want to find out if it’s possible to use two GPUs for the same game and each GPU is outputting to a different device. One to the Vive the other to the PC monitor. Each will have a different viewport. The idea here is that you have the main player in the VR headset doing what they do in FPV. While the second operator on the PC is seeing things from 3rd person view or birds eye view. Each would be being totally different things and the PC operator could see the VR avatar on the PC screen.
Do to the size of the world we are working with it’s unrealist to expect a 1080 to be able to push that much content at 90fps (in the headset) and then an additional POV at 30fps on the screen.
The hardware configuration would be two identical cards like the GTX 1080s.
This sounds like its not something the engine would natively support. You’d have to mod the engine to add in support for it yourself, and this sounds like it would end up being a pretty labor intensive mod down at the DirectX API level.
The easier solution would be to have two computers running the game. The VR computer is a server, the third person camera is a networked client connected to the server.
VR SLI have this rather interesting feature, capable to render for the left eye on one card, and the right eye over the second sli card, which means separate GPU operations that share the same 3d content. This feature still not support your requirements, tho this interesting engine modification could be helpful to figuring out this separation, while managing the 3d content simultaneously on both cards.
Please note that while using the cards in SLI mode you most likely cannot output a video signal on the secondary card which makes SLI useless in your case, but the solution above can still hold some valuable information regarding numerous questions along the way, while modifying the engine renderer to suit your requirements. @Slayemin’s solution seems to be effective, by running two separate games but sharing (mirroring) the interaction and environment properties could be less invasive to implement.