Proposal for per-CRTC pixmaps in RandR

[Andy Ritger]

Hi Keith, sorry for the slow response.

Interesting proposal.

I can see how a per-scanout pixmap would overcome scanout constraints if
a scanout engine can accept a buffer the size of the pixmap, but cannot
accept a buffer the size of the X screen.

However, you also mention overcoming rendering engine buffer size
constraints.  This proposal seems unrelated to the size of the buffer
being rendered to (I imagine we need something like shatter to solve that
problem?)  E.g., the redirected window is still going to have a backing
pixmap the size it had prior to this proposal, unless I misunderstood.

Also, if part of the goal is to overcome scanout buffer size constraints,
how would scanout pixmap creation and compositing work during X server
initialization?  The X server has no knowledge during PreInit/ScreenInit
that a composite manager will be used, or whether the composite manager
will exit before the X server exits.

If the initial X server configuration requested in the X configuration
file(s) specifies a configuration that is only possible when using
per-scanout pixmaps, would the X server implicitly create these pixmaps
and implicitly composite from the X screen into the per-scanout pixmaps?


More comments below:


On Mon, 1 Mar 2010, Keith Packard wrote:

>
>
> 		Per-CRTC pixmaps in RandR
> 		   RFC Version 0.1
> 		      2010-03-01
> 		     Keith Packard
> 		   keithp at keithp.com
>
> Target problem scope:
>
> 1) Driving multiple monitors where the desired screen geometry
>    exceeds the capacity of the rendering and/or scanout engines.
>
> 2) Integrating compositing with projective transformation into
>    a single operation.
>
> 3) Eliminating visual artifacts during rotation by eliminating
>    all modeset operations in this path.
>
> 4) Along the way, provide an atomic multi-mode-set operation to
>    reduce the number of visual operations required to achieve
>    the desired configuration.
>
> Outline of the proposed solution:
>
> 1) Add a request to create a pixmap that can be used for scanout
>    purposes. The parameters to this would be the geometry of the
>    pixmap (WxHxD) and the set of desired hardware rotations to be
>    supported (for hardware which has the ability to scanout in
>    different orientations).
>
> 2) Add a request to set a window's pixmap. Composite provides a way
>    to get the window's pixmap, this adds the ability to set the
>    same. This isn't strictly necessary for X to perform the desired
>    operations, but I think it will make GL happy to have a window as
>    a double buffered target.
>
> 3) Add a new 'multi mode set' request that takes a whole pile
>    of outputs, crtcs, modes and scanout pixmaps and mashes them
>    all together.

Hallelujah! :)

While we're doing that, we should probably also add a mechanism for
clients to query if the 'multi mode' is valid.  This would let savvy
user interfaces do more intelligent presentation of what combinations
of configurations are valid for presentation to the user.


> 4) Add a new request that changes the projective transform used to
>    convert screen coordinates to monitor coordinates when displaying
>    the pointer sprite. I'd suggest that we also include a transform
>    to convert the sprite image.

In the case that the pointer sprite is transformed, I assume this would
still utilize the hardware cursor when possible?


> 5) Add suitable 'query' operations to discover the capabilities of
>    the scanout engines in terms of maximum geometry and rotation.
>
> How would this work:
>
> The compositing manager would allocate one scanout pixmap per
> non-overlapping crtc, it would then create a window for each pixmap
> and set the window's pixmap to the per-crtc scanout pixmap. At that
> point, it can draw whatever it likes to the scanout pixmap using
> regular GL operations. An application window which spans two monitors
> will be drawn to both scanout pixmaps.

Creating a window the size of the scanout pixmap and then plugging
the scanout pixmap in as the window's backing pixmap feels a little
backwards, sequentially.  If the intent is just to give the scanout
pixmap double buffering, you should be able to create a GLXPixmap from
the scanout pixmap, and create that GLXPixmap with double buffering
through selection of an appropriate GLXFBConfig.  However, the GLX spec
says that glXSwapBuffers is ignored for GLXPixmaps.

However, a more flexible solution would be to provide a mechanism to
create a scanout window (or maybe a whole window tree), rather than a
scanout pixmap.  The proposed scanout window would not be a child of
the root window.

A composite manager could then optionally redirect this scanout window
to a pixmap (or, even better, a queue of pixmaps).  The pixmaps could
be wrapped by GLXPixmaps for OpenGL rendering.  If we also provided
some mechanism to specify which of the backing pixmaps within the queue
should be "presented", then an implementation could even flip between
the pixmaps.

Composite manager pseudocode:

     // Create the scanout window tree
     Window scanoutWin = XCreateScanoutWindowTree(dpy, screen, crtc);

     // Redirect the scanout window to a queue of 2 pixmaps.
     Pixmap scanoutBackingPixmaps = XNameWindowPixmaps(dpy, scanoutWin, 2);

     // Initial entry 0 in the array is the window's "front buffer"
     int frontPixmap = 0;

     // And that leaves the other pixmap offscreen, for us to update
     int backPixmap = 1;

     // main loop
     while (1) {
         // Do some rendering to currentPixmap
         Xcomposite(dpy, scanoutBackingPixmaps[backPixmap], ...);

         // Swap Buffers.  Note below does not take a pixmap,
         // but rather names one implicitly by referring to
         // its index in the existing queue.
         Xpresent(dpy, scanoutWin, backPixmap);

         // client-side book keeping, works for double-buffered case.
         backPixmap = !backPixmap;
         frontPixmap = !frontPixmap;
     }

I think this lines up with some of the multi-buffer presentation ideas
Aaron Plattner presented at XDC in Portland last fall.

Thanks,
- Andy


> For rotation, the compositing manager would ensure that the scanout
> pixmap could be used with the desired rotation, then it would set the
> sprite transform as needed and just start painting the window contents
> using the specified rotation. No mode set would be required, and the
> compositing manager could even smoothly animate the rotation operation.
>
> As you can see, this is just a rough sketch of an idea, but it has
> some nice properties:
>
> 1) It exposes what the hardware does, a classic X dodge to make
>    applications do all of the hard work.
>
> 2) It solves several current problems with one fairly simple
>    addition to the system.
>
> 3) It doesn't require changes to applications or direct rendering
>    libraries.
>
> I haven't even thought about what the protocol spec will look like, or
> how to code this up, I'm just looking for some early feedback about
> the design in the hopes that we can improve it now while the improving
> is easy.
>
> -- 
> keith.packard at intel.com
>
>