If you're interested in multi-GPU rendering, capabilities for DisplayLink-like devices, or NVIDIA Optimus / MUX-less hybrid graphics switching, here's some news worth reading about virtual CRTCs.
Annoucned today to DRI and fbdev developers is a patch-set that a few unknown developers have been working on for several months. This code allows DRM GPU drivers to have an arbitrary number of CRTCs, including virtual CRTCs, rather than being limited by the number of physical CRTCs on the graphics hardware.
A CRTC (Cathode Ray Tube Controller) deals with video timings and reads the frame-buffer from video RAM so that it can be outputted. This code allows virtual CRTCs to be created in the kernel drivers so that they can be used for a variety of tasks. A virtual CRTC with this code is treated just like a real hardware CRTC. This experimental code allows these virtual CRTCs to be attached to "CTD devices" (Compression Transmission and Display). Then finishing off the equation is a new kernel module, the VCRTCM (Virtual CRTC Manager), that bridges the traffic between GPUs and CTDs.
With being able to basically stream rendered data from one GPU/display to another, there's interesting possible use-cases. Here's a description from the announcement, "In one example, we use AMD/ATI Radeon GPU to do 3D rendering (accelerated, of course) and we use our code to add additional monitor heads using DisplayLink devices. In other words, we achieve accelerated 3D rendering on a DisplayLink monitor. In another example we funnel rendered pixels to userland by emulating a Video-for-Linux
device (and then userland can do whatever it wants with it). While doing all this, GPU has no idea that we are doing this, the entire DRI "thinks" that it is just dealing with a GPU that has a few "extra" connectors and CRTCs. So everything ports without the need to modify anything in the userland."
As was confirmed by the developer announcing this work, this could help in the NVIDIA Optimus / MUX-less hybrid graphics situations. The discrete GPU can be used for rendering the data and then passing the contents to the integrated graphics processor.
These developers have also written a fake driver to represent a V4L2 device as a CTD device. Drivers wishing to take advantage of virtual CRTCs require slight modifications. The developers also seem to have some other interesting plans for this work too, assuming the upstream DRM developers welcome the contributions.
Find more information in the mailing list announcement
for Virtual CRTCs.