RandR future proposals
aritger at nvidia.com
Fri Feb 16 13:14:02 PST 2007
Thanks for raising these points, Keith.
wrt the pan-and-scan thing, yes, it's straightforward to implement
(though there are a few behavioral questions to debate). The "panning
domain" TwinView stuff in the NVIDIA driver isn't widely used, but I
have received feedback from power users that appreciate it. I think
it's most commonly used when you have dissimilar sized CRTC rectangles,
and you want to pan the smaller one to access otherwise dead regions.
For interfacing RandR with Xinerama-classic, a 'GPU' object would be
a good thing to expose. However the layer between the CRTC and the X
screen may be better served as a "framebuffer" or "physical X screen".
Some of the drivers today support having multiple X screens on one GPU;
while this is often less efficient than TwinView/MergedFB, it does serve
- you can advertise different capabilities on each X screen (e.g.,
stereo, overlays, etc)
- you can overcome hardware size limitations that you run into with
TwinView/MergedFB (e.g., 2 2560x1600 30" panels side-by-side exceed
4k pixels; if your hardware cannot render to larger than 4k buffers,
then users can instead configure two separate X screens, one to
drive each of the 30" panels) and optionally enable Xinerama-classic
- if you don't want the outputs driven by a GPU to be physically
contiguous within your larger virtual Xinerama-classic X screen;
e.g., a common 3-headed powerwall config is something like this:
| a) | b) | c) |
| | | |
| | | |
where b) is expected to be where most of the interesting rendering
happens and has one dedicated GPU, while a) and c) are driven by
a second GPU. You'd want a) and c) to have separate buffers,
even if they're driven by the same GPU.
So I think it would be useful for RandR to have a notion of what "buffer"
each CRTC is scanning from, but that should probably be distinct from
the notion of a GPU, though a buffer could belong to a GPU. If there
were multiple buffers on the GPU, maybe you should even be able to swap
which buffer (on the same GPU) a CRTC is reading from.
After the RandR 1.2 work wraps up, I would be happy to take a stab at
(or atleast help with) the spec language for some of this stuff.
On Thu, 15 Feb 2007, Keith Packard wrote:
> While we're busy finishing up the RandR 1.2 work, I wanted to make sure
> we didn't lose the good ideas that have been floating around for a few
> days on IRC and from XDC.
> During XDC, we chatted about issues of RandR with Xinerama-classic and
> other multi-GPU environments. Right now, with RandR 1.2, you get
> multiple X screens, one per-GPU, each of which can have multiple
> monitors connected. With the goal of having only one X screen, we
> discussed re-using the existing Xinerama implementation to merge
> multiple GPUs into one X screen.
> To let clients know what the underlying configuration in the X server
> was, we talked about exposing a new RandR object, the 'GPU'. A GPU would
> present another layer between the X screen and the CRTCs. It would
> represent a collection of CRTCs and Outputs, and would have geometry.
> The CRTCs would be required to be placed within the geometry of the
> related GPU. GPU size and position would be controlled through the
> Yesterday, Fredrik Höglund asked on IRC about pan-and-scan mode where
> the position of the CRTC is controlled by the mouse. Right now, RandR
> pretty much eliminates this as CRTC position is controlled only through
> the protocol. Aaron Plattner mentioned that the nVidia closed-source
> driver has an extra rectangle for each CRTC; CRTCs are allowed to
> pan-and-scan within that rectangle, instead of the whole screen.
> I think this idea makes some sense, and seems easy to add to RandR; a
> simple rectangle-per-CRTC which confines the pan-and-scan boundaries. By
> default, this would be set to the extents of the CRTC itself whenever
> the CRTC mode was set. We'd still report CRTC changes through the RandR
> protocol, so clients could even tell what parts of the screen were
> currently visible. I imagine the Xinerama information would report the
> pan-and-scan rectangle rather than the CRTC rectangle.
> Neither of these ideas will be incorporated into RandR 1.2, but I'd like
> to see if other people have ideas about what else might go into a RandR
> 1.3 version.
> keith.packard at intel.com
More information about the xorg