[linuxkernelnewbies] X.Org Wiki - XDC2007Notes

[Peter Teoh]

http://www.x.org/wiki/XDC2007Notes#head-b6d8966522f55d527c81882e2ac5d3a3e1f8ec31 Andy Ritger: Multi-GPU X Screens 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. Bart Massey: XCB mini-status It lives! 1.0 released, included in X11R7.2. Supports most of the X protocol. Team of about 6 active contributors with occasional casuals. Used for the client-side protocol libraries, but not the server (yet). XCB is XML descriptions of the protocol, with XSLT to produce the C "top half". The C bottom-half contains the transport and multiplexing code. Xlib now built on the XCB bottom-half. Conceptualised in ~2000, originally done in m4 instead of XSLT. There is minimal magic here, it's just protocol. Latency hiding is free, threading just works, error handling fixed, protocol docs are handy for other tools like wireshark or language bindings. Lets you mix and match Xlib and XCB code, which allows the transition. Make the transition short, of course. It's slightly volatile and sometimes awkward to work with, the team bandwidth is slightly low, etc. But it's a good start. Still need client libraries, XSLT cleanups, get XCB into the toolkits, to use it on the server side, and to grow the team. Question: can I handle disconnect politely with XCB? Yes, but maybe not if you're using the Xlib frontend.