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
kei...@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.pack...@intel.com
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
