I think that I may have found a potentially useful way out of some
problems within the current compositing framework. Basically, the server
has information that the compositor would find useful.
Of course, I may be wrong ...
GLX redirection
---------------
The GLX protocol provides GL applications with the contexts and
drawables that they require to execute GL. Since the X server is
usually in charge of drawing operations on the screen real estate,
it is usually in a good position to service the GLX protocol.
However, this situation changes radically under compositing,
because the composite manager becomes responsible for all drawing
on the screen. When compositing is enabled it might make more
sense for the compositor to filter the GLX protocol.
Compositors are usually integrated into window managers that redirect
substructure requests on non-override_redirect windows. The effective
redirection of the GLX protocol would also require the redirection of
Window creation and destruction requests on all windows to provide
full parity between GLX 1.2 and GLX 1.3. The redirection of these
requests would also enable compositors to avoid making requests
on destroyed windows. These erroneous requests result in unnecessary
X errors and can crash GL under compliant GLX implementations.
The advantages of redirecting GLX to the compositor might include:
1) Support for direct GLX contexts.
2) Drawing directly into textures.
3) Avoiding texture_from_pixmap.
4) Avoiding GL crashes.
5) Reduced memory usage.
6) Improved resource sharing.
There is an expectation that many of the problems that GLX redirection
might address can be resolved within the GL drivers given time.
Whilst this might be true, it would probably be more efficient to
avoid creating the problems in the first place.
GLX redirection would need to be selected by the compositor, probably
on a command group basis.
Redirection would be limited to the X command stream. Redirection
of the GL command stream would be infeasible in direct contexts and
undesirable in indirect contexts.
Compositors would be mainly interested in requests to create and
destroy contexts and drawables. These requests should not be time
critical. Providing that X protocol Window creation and destruction
requests are redirected, then there should be no need to redirect
context switching events.
SwapBuffer requests on the current drawable do not appear in the
X command stream under the GLX specifications. However, the
redirected GLX extension might choose to copy these SwapBuffer
requests into the the X command stream when they relate to indirect
contexts. This would force a rendezvous and ensure that all drawing
was halted during the SwapBuffer request. There might be a loss of
performance as pipelines were halted and restarted, but the potential
problems of sharing drawables across processes could be avoided
by implementing the SwapBuffer request as a switch between textures.
The redirection of GLX requests should be implemented as an
extension to the X protocol within the X server. Unfortunately,
GLX redirection can not be effectively implemented within the
Xorg server, because its non-compliant GLX server implementation
is inadequate to support GL 1.2 and usually remains unused.
The Xorg/GLX server would provide a more suitable basis for
implementing GLX redirection, because it has access to a working
GLX 1.4 server implementation and it might benefit more from
improved GLX support under compositing.
Felix
_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg