VR MultiGPU CPU
From Virtools Wiki
Contents
|
Issues about using Multi GPU/CPU
Sometimes you may want to use all the power of a single PC :
- Lots of new PCs have Dual Core CPUs,
- Your graphics card has two outputs, so why not drive two projectors ?
- You may be able to put more than one graphics card inside the PC
Here are information you should be aware of when making a purchase decision.
The bottom line
Buy a cluster of single CPU/GPU PCs rather than creating a monster that is difficult to maintain, (very) difficult to use, expensive and with lots of constraints. Certainly using an Nvidia Quadro_Plex will give you better density, and enable SLI Frame rendering which can't be achieved with a PC cluster unless you use an Orad solution or other hardware compositing systems
One GPU, one CPU, one VRPlayer, one output, multiple views
You can configure the VRPack to draw multiple viewports. For example :
C:\Program Files\Virtools\Virtools 4.0\VRPack\SystemConfig\ReferenceSamples\VRDisplaySASCubeSimul.cfg View_0_0 none FrontCamera 300 0 300 300 View_0_1 none FloorCamera 300 300 300 300 View_0_2 none LeftCamera 0 0 300 300 View_0_3 none RightCamera 600 0 300 300
This will draw 4 viewports using 4 different cameras, using only one behavior loop. This means the behavior graph will be evaluated only once for the 4 renderings. The side effect is that you can't do different renderings for each view, for example display a different 2d text on each view. You can just specify a different camera, the scene content will be exactly the same.
The "Get Active Camera" BB will only return once for the 4 views (remember, only one behavior loop is done). Moreover, the VR Player ignores the "Set Active Camera" BB because it uses the camera names provided in the configuration files (unless the '-' sign is used).
You can't use the "VR Get HostID" BB either, since it will return the same ID for all the views (only one behavior loop and anyway only one vrplayer).
This first issue here is of course a pure performance problem :
- the single CPU might not be enough to do 4 different culling [what else?].
- the single GPU might not be enough to render the 4 views fast enough [transform rate...]
One CPU, One GPU, One VRPlayer, Multiple Outputs
You have several options to activate the multiple outputs of your graphic card. Horizontal/Vertical Span, Dual View ... The best option is to set the desktop to horizontal/vertical span. Dual View bad, slow! (other?)
The best is to draw one (or more) viewport(s) that spans across the two outputs. If you're in horizontal/vertical span, there should be no overhead appart from the fill rate. (more overhead source?)
[why would we want 2 vrplayers, one for each output?]
Multiple GPUs
You have to make sure that the BIOS is compatible with the use of multiple GPUs in a single computer.
Here's a compatibility chart for the QuadroFX 4500x2 : http://www.nvidia.com/object/quadro_fx_4500_x2_mobo.html
The Plex also have a compatibility chart : http://www.nvidia.com/page/quadroplex_certified_platforms.html
For more infos about using the nVidia Quadro Plex, Read Quadro_Plex article.
Multiple CPUs, one GPU? One CPU, Multiple GPUs ?
Multiple CPUs/GPUs
GPU Considerations
Overhead in spanning accross all GPUs? Need to be absolutely in Dual View for each GPU ?
The ideal here is to have one VR Player per CPU (only way to be multipipe right now with the vrpack). But then you have to clusterise your composition (easy with vrpack), and be in OpenGL :
- DirectX needs to be in fullscreen ( which is different than a maximised window) to get the best performances (you won't have a regular framerate in windowed mode).
- Windows allows only one window to be in fullscreen
-> You can't have two DirectX windows in fullscreen, so you'll get poor perfomances.
OpenGL doesn't need to be in fullscreen, its performances are good also in windowed mode.
So you can have two (or more) OpenGL windows, one for each GPU.
Note: Godji says that DX performances on the secondary monitor are slower. Dom says: By default yes. But if you use SPAN modes offered by the drivers (instead of Dual Views) then not. NVIDA has this feature for long and it's stable. Last time I tested this for ATI it was brand new (end 2005?) and it was not useable. Should be good now after such a long time ;)
CPU Considerations
By default, each VRPlayer will run on every CPU. For best performances you have to lock each VR Player to a different CPU. The easiest way to do this is to use the follwing VR configuration token [only available as a beta feature for now, contact us for more infos]:
ProcAffinity Auto
On some multi GPU/CPU architecture, like the HP XW9300, each graphic card is assigned to a given CPU. If you lock a VRPlayer on a given CPU, you have to make sure that that CPU corresponds to the GPU you're rendering on. Normally, the first GPU is assigned to the first CPU, etc. Here's how to lock a VRPlayer on a given CPU :
Hosts sas1 sas1 sas2 sas3 ProcAffinity 0 1 0 2
The first VRPlayer on sas 1 will be locked to processor 0, the 2nd will be on processor 1. The player on sas2 will be locked on processor 0, and the player on sas3 will be on processor 2.
ProcAffinity <procForHostId0> <procForHostId1> …
The players that are not assigned to a given processor will be handled by the default OS mechanism.
What about SLI ?
Only output on one card (max 2 outputs). Need the fastest PCI express ports for each card (x16).
What about a cluster of simple PCs ?
Drawbacks:
- your composition must be clusterised, but that's easy with the vrpack.
Advantages:
- easier to maintain > can prepare a spare pc, cluster back online in a couple of minutes
- easier to configure
- scalable; if you need more perfomances, projectors, pixels density, simply add PCs !
