http://www.x.org/wiki/XDC2007Notes#head-b6d8966522f55d527c81882e2ac5d3a3e1f8ec31

Why would you want to use multiple GPUs? Solve larger problems, throw more power at large problems. SLI is one technique for splitting the scene among multiple GPUs. Xinerama is another technique for big desktop. The two are not mutually exclusive.

SLI allows multiple GPUs to render one X screen. Multiple modes: alternate frame rendering, scan line interleaving, and SLI + antialiasing.

Xinerama means two things. One is the protocol, which defines the "screen" layout. The internal implementation is the code that splits the protocol requests among multiple hardware drivers.

Unofficial terminology: the "physical" X screen is a video memory buffer in a single GPU, the "logical" X screen is the object as visible through the protocol to clients.

Use cases: Powerwalls. Caves. Large desktop. Multiple logical X screens.

What do we have today? TwinView/MergedFB, where two display devices are connected to one physical X screen (vram buffer). Multiple X screens per GPU, sort of the classic X "Zaphod" mode; allows you to advertise different capabilities per screen. Xinerama, where you have multiple physical X screens glued together into one logical X screen. RANDR 1.2 operates on a logical X screen, basically allows dynamic reconfig of MergedFB/TwinView.

What's nice about the existing Xinerama? Transparent to X drivers, and mostly works today. What's bad? Lots of resource duplication, which causes performance issues. What does it mean to redirect windows with multi-GPU X screens? RANDR and Xinerama (implementation) are mutually exclusive.

Ideas: Post RANDR 1.2, expose physical X screen in the RANDR protocol, which would allow the combination of the two. Apply DMX lessons and work to the Xinerama implementation for optimization. Expose ways for compmgrs to control what GPU receives the allocation for a redirected pixmap.

Nothing solid yet. Think about how to address these issues.

Reply via email to