This section describes the development plan from approximately June 2001 through July 2003.
To allow for rapid development of the DMX server by multiple developers during the first development stage, the problem will be broken down into three tasks: the overall DMX framework, back-end rendering services and input device handling services. However, before the work begins on these tasks, a simple framework that each developer could use was implemented to bootstrap the development effort. This framework renders to a single back-end server and provides dummy input devices (i.e., the keyboard and mouse). The simple back-end rendering service was implemented using the shadow framebuffer support currently available in the XFree86 environment.
Using this bootstrapping framework, each developer has been able to work on each of the tasks listed above independently as follows: the framework will be extended to handle arbitrary back-end server configurations; the back-end rendering services will be transitioned to the more efficient Xnest-style implementation; and, an input device framework to handle various input devices via the input extension will be developed.
Status: The boot strap code is complete.
An X server (including the front-end X server) requires two core input devices -- a keyboard and a pointer (mouse). These core devices are handled and required by the core X11 protocol. Additional types of input devices may be attached and utilized via the XInput extension. These are usually referred to as ``XInput extension devices'',
There are some options as to how the front-end X server gets its core input devices:
The following options are available for implementing local input devices:
kdriveX server in XFree86 has built-in drivers that support PS/2 mice and keyboard under Linux. The mouse driver can indirectly handle other mouse types if the Linux utility
gpmis used as to translate the native mouse protocol into PS/2 mouse format. These drivers could be adapted and built in to the front-end X server if this range of hardware and OS support is sufficient. While much simpler than the XFree86 drivers, the
kdrivedrivers were not used for the DMX implementation.
Although extended input devices are not specifically mentioned in the Distributed X requirements, the options above were all implemented so that XInput extension devices were supported.
The bootstrap code (Xdmx) had dummy input devices, and these are still supported in the final version. These do the necessary initialization to satisfy the X server's requirements for core pointer and keyboard devices, but no input events are ever generated.
Status: The input code is complete. Because of the complexity of the XFree86 input device drivers (and their heavy reliance on XFree86 infrastructure), separate low-level device drivers were implemented for Xdmx. The following kinds of drivers are supported (in general, the devices can be treated arbitrarily as "core" input devices or as XInput "extension" devices; and multiple instances of different kinds of devices can be simultaneously available):
The output of the DMX system displays rendering and windowing requests across multiple screens. The screens are typically arranged in a grid such that together they represent a single large display.
The output section of the DMX code consists of two parts. The first is in the front-end proxy X server (Xdmx), which accepts client connections, manages the windows, and potentially renders primitives but does not actually display any of the drawing primitives. The second part is the back-end X server(s), which accept commands from the front-end server and display the results on their screens.
The DMX front-end must first initialize its screens by connecting to each of the back-end X servers and collecting information about each of these screens. However, the information collected from the back-end X servers might be inconsistent. Handling these cases can be difficult and/or inefficient. For example, a two screen system has one back-end X server running at 16bpp while the second is running at 32bpp. Converting rendering requests (e.g., XPutImage() or XGetImage() requests) to the appropriate bit depth can be very time consuming. Analyzing these cases to determine how or even if it is possible to handle them is required. The current Xinerama code handles many of these cases (e.g., in PanoramiXConsolidate()) and will be used as a starting point. In general, the best solution is to use homogeneous X servers and display devices. Using back-end servers with the same depth is a requirement of the final DMX implementation.
Once this screen consolidation is finished, the relative position of each back-end X server's screen in the unified screen is initialized. A full-screen window is opened on each of the back-end X servers, and the cursor on each screen is turned off. The final DMX implementation can also make use of a partial-screen window, or multiple windows per back-end screen.
After initialization, X applications connect to the front-end server. There are two possible implementations of how rendering and windowing requests are handled in the DMX system:
This solution suffers from two main problems. First, it does not take advantage of any accelerated hardware available in the system. Second, the size of the XPutImage() calls can be quite large and thus will be limited by the bandwidth available.
The initial DMX implementation used a shadow framebuffer by default.
This solution suffers from two main drawbacks. First, protocol requests are sent to all back-end servers -- even those that will completely clip the rendering primitive -- which wastes bandwidth and processing time. Second, state is maintained both in the front- and back-end servers. These drawbacks are not as severe as in option 1 (above) and can either be overcome through optimizations or are acceptable. Therefore, this option will be used in the final implementation.
The final DMX implementation defaults to this mechanism, but also supports the shadow framebuffer mechanism. Several optimizations were implemented to eliminate the drawbacks of the default mechanism. These optimizations are described the section below and in Phase II of the Development Results (see appendix).
Status: Both the shadow framebuffer and Xnest-style code is complete.
Initially, the Xnest-style solution's performance will be measured and analyzed to determine where the performance bottlenecks exist. There are four main areas that will be addressed.
First, to obtain reasonable interactivity with the first development phase, XSync() was called after each protocol request. The XSync() function flushes any pending protocol requests. It then waits for the back-end to process the request and send a reply that the request has completed. This happens with each back-end server and performance greatly suffers. As a result of the way XSync() is called in the first development phase, the batching that the X11 library performs is effectively defeated. The XSync() call usage will be analyzed and optimized by batching calls and performing them at regular intervals, except where interactivity will suffer (e.g., on cursor movements).
Second, the initial Xnest-style solution described above sends the repackaged protocol requests to all back-end servers regardless of whether or not they would be completely clipped out. The requests that are trivially rejected on the back-end server wastes the limited bandwidth available. By tracking clipping changes in the DMX X server's windowing code (e.g., by opening, closing, moving or resizing windows), we can determine whether or not back-end windows are visible so that trivial tests in the front-end server's GC ops drawing functions can eliminate these unnecessary protocol requests.
Third, each protocol request will be analyzed to determine if it is possible to break the request into smaller pieces at display boundaries. The initial ones to be analyzed are put and get image requests since they will require the greatest bandwidth to transmit data between the front and back-end servers. Other protocol requests will be analyzed and those that will benefit from breaking them into smaller requests will be implemented.
Fourth, an extension is being considered that will allow font glyphs to be transferred from the front-end DMX X server to each back-end server. This extension will permit the front-end to handle all font requests and eliminate the requirement that all back-end X servers share the exact same fonts as the front-end server. We are investigating the feasibility of this extension during this development phase.
Other potential optimizations will be determined from the performance analysis.
Please note that in our initial design, we proposed optimizing BLT operations (e.g., XCopyArea() and window moves) by developing an extension that would allow individual back-end servers to directly copy pixel data to other back-end servers. This potential optimization was in response to the simple image movement implementation that required potentially many calls to GetImage() and PutImage(). However, the current Xinerama implementation handles these BLT operations differently. Instead of copying data to and from screens, they generate expose events -- just as happens in the case when a window is moved from off a screen to on screen. This approach saves the limited bandwidth available between front and back-end servers and is being standardized with Xinerama. It also eliminates the potential setup problems and security issues resulting from having each back-end server open connections to all other back-end servers. Therefore, we suggest accepting Xinerama's expose event solution.
Also note that the approach proposed in the second and third optimizations might cause backing store algorithms in the back-end to be defeated, so a DMX X server configuration flag will be added to disable these optimizations.
Status: The optimizations proposed above are complete. It was determined that the using the xfs font server was sufficient and creating a new mechanism to pass glyphs was redundant; therefore, the fourth optimization proposed above was not included in DMX.
The DMX X server keeps track of all the windowing information on the back-end X servers, but does not currently export this information to any client applications. An extension will be developed to pass the screen information and back-end window IDs to DMX-aware clients. These clients can then use this information to directly connect to and render to the back-end windows. Bypassing the DMX X server allows DMX-aware clients to break up complex rendering requests on their own and send them directly to the windows on the back-end server's screens. An example of a client that can make effective use of this extension is Chromium.
Status: The extension, as implemented, is fully documented in "Client-to-Server DMX Extension to the X Protocol". Future changes might be required based on feedback and other proposed enhancements to DMX. Currently, the following facilities are supported:
The XInput, XKeyboard and Shape extensions are commonly used extensions to the base X11 protocol. XInput allows multiple and non-standard input devices to be accessed simultaneously. These input devices can be connected to either the front-end or back-end servers. XKeyboard allows much better keyboard mappings control. Shape adds support for arbitrarily shaped windows and is used by various window managers. Nearly all potential back-end X servers make these extensions available, and support for each one will be added to the DMX system.
In addition to the extensions listed above, support for the X Rendering extension (Render) is being developed. Render adds digital image composition to the rendering model used by the X Window System. While this extension is still under development by Keith Packard of HP, support for the current version will be added to the DMX system.
Support for the XTest extension was added during the first development phase.
Status: The following extensions are supported and are discussed in more detail in Phase IV of the Development Results (see appendix): BIG-REQUESTS, DEC-XTRAP, DMX, DPMS, Extended-Visual-Information, GLX, LBX, RECORD, RENDER, SECURITY, SHAPE, SYNC, X-Resource, XC-APPGROUP, XC-MISC, XFree86-Bigfont, XINERAMA, XInputExtension, XKEYBOARD, and XTEST.
OpenGL support using the Mesa code base exists in XFree86 release 4 and later. Currently, the direct rendering infrastructure (DRI) provides accelerated OpenGL support for local clients and unaccelerated OpenGL support (i.e., software rendering) is provided for non-local clients.
The single head OpenGL support in XFree86 4.x will be extended to use the DMX system. When the front and back-end servers are on the same physical hardware, it is possible to use the DRI to directly render to the back-end servers. First, the existing DRI will be extended to support multiple display heads, and then to support the DMX system. OpenGL rendering requests will be direct rendering to each back-end X server. The DRI will request the screen layout (either from the existing Xinerama extension or a DMX-specific extension). Support for synchronized swap buffers will also be added (on hardware that supports it). Note that a single front-end server with a single back-end server on the same physical machine can emulate accelerated indirect rendering.
When the front and back-end servers are on different physical hardware or are using non-XFree86 4.x X servers, a mechanism to render primitives across the back-end servers will be provided. There are several options as to how this can be implemented.
These, and other, options will be investigated in this phase of the work.
Work by others have made Chromium DMX-aware. Chromium will use the DMX X protocol extension to obtain information about the back-end servers and will render directly to those servers, bypassing DMX.
Status: OpenGL support by the glxProxy extension was implemented by SGI and has been integrated into the DMX code base.