GLX redirection extension

Felix Bellaby felix at
Thu Jul 20 14:22:09 PDT 2006

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.


More information about the xorg mailing list