The material presented here focuses on how the coming transition to 64-bit in the workstation world affects X programmers coding in C or C++. The transition to 64-bit will be much easier if you are aware of how 64-bit systems affect the X Window System and the X code you write. Even if you have no immediate plans to use 64-bit systems, the code you write today may be ported to future 64-bit systems. If written correctly, the necessary porting effort can be greatly eased.
This article is structured in three sections. The first section explains the options and advantages for using 64-bit systems. In particular, how a 64-bit programming model changes the sizes of fundamental C data types is discussed. Then, the second section explores the kinds of general portability problems introduced by 64-bit data types. The last section details how 64-bit systems affect the X Window System and how to avoid 64-bit portability pitfalls specific to X programming interfaces.
This article provides an overview of the changes from X11 Release 5 (provided with IRIX 5.1 and IRIX 5.2), and X11 Release 6 (provided with IRIX 5.3, IRIX 6.0, and IRIX 6.0.1). The information provided in this article was largely obtained from the X Window System, Version 11, Release 6 Release Notes from the X Consortium, May 16, 1994.
The following sections will briefly describe how SGI has implemented (or not implemented) the new X Consortium standards in X11R6.
This document is based on the release notes accompanying the X11R6
release for the X Consortium. The original text is annotated with
italics (like this) explaining how X11R6 is supported for IRIX 6.0
and 5.3.
The main difference between IRIX 6.0 and 5.3 versions of X11R6 is
the existence of the 64-bit X shared libraries in /usr/lib64 in
IRIX 6.0. Otherwise, the two operating system releases will be
largely identical in the X11R6 support.
Because IRIX 5.3 will release after IRIX 6.0, it should be expected
that IRIX 5.3 will have further bug fixes. As an X Consortium member,
Silicon Graphics is privy to official bug fixes from the
X Consortium. Reported bugs in the public X11R6 release are likely
to be resolved in the IRIX 6.0 and 5.3 releases.
All the X programs supplied with IRIX 6.0 and 5.3 will be 32-bit. This
of course includes the X server.
Abstract:
Consider the dual pressures toward a more tightly integrated workstation window system: 1) the need to efficiently handle high bandwidth services such as video, audio, and three-dimensional graphics; and 2) the desire to achieve the under-realized potential for local window system performance in X11.
This paper proposes a new window system architecture called D11 that seeks higher performance while preserving compatibility with the industry-standard X11 window system. D11 reinvents the X11 client/server architecture using a new operating system facility similar in concept to the Unix kernel's traditional implementation but designed for user-level execution. This new architecture allows local D11 programs to execute within the D11 window system kernel without compromising the window system's integrity. This scheme minimizes context switching, eliminates protocol packing and unpacking, and greatly reduces data copying. D11 programs fall back to the X11 protocol when running remote or connecting to an X11 server. A special D11 program acts as an X11 protocol translator to allow X11 programs to utilize a D11 window system.
A set of 71 showcase slides from the SGI Software Seminar Series, focusing on:
There are many misconceptions surrounding multi-pipe systems. This article will provide a list of multi-pipe systems that are currently supported by SGI, and attempt to clear up some of the confusion with regard to other SGI products. It will then explain some restrictions inherent in the X window system that end users may encounter, as well as the different configurations possible with a multi-pipe system that a system administrator might find useful. Finally, some multi-pipe IRIS GL programming caveats will be discussed for the benefit of the SGI developer.
Abstract: Window systems have evolved to be an extremely complex component of workstation system software, rivaling the operating system in complexity. At Silicon Graphics, the past has been a (bumpy) migration towards increased window system standardization with a greater emphasis on 2D and window management performance.
Our present window system supports a host of features to provide the infrastructure for a feature-rich, high performance desktop environment. Most notable is the tight integration between OpenGL and the window system. Other features include a flexible, low latency input subsystem; a non-frame buffer (NFB) porting layer for fast hardware bring up; support for multiple colormaps and visuals; layered frame buffer support for overlays and underlays; dynamic loading of heavy-weight X extensions and device-dependent software; PEX; Display PostScript; and a shared memory transport. My hope is to provide enough information so engineers can appreciate and effectively utilize these features.
For the future, I consider trends in window system design. How will high-bandwidth, interactive services like 3D, imaging, video, and audio, change the way we build window systems? What can we learn from the way we build window systems? What can we learn from the way competitors like Microsoft design window systems? I sketch a proposal for a next-generation window system that reinvents the client-server X model for improved performance.
Abstract: To support OpenGL(TM) and PEX rendering within the Silicon Graphics X server without compromising interactivity, we devised and implemented a scheme named "multi-rendering". Making minimal changes to the X Consortium sample server's overall structure, the scheme allows independent processes within the X server's address space to perform OpenGL rendering asynchronously to the X server's main thread of execution. The IRIX operating system's process share group facility, user-level and pollable semaphores, and support for virtualized direct access rendering are all leveraged to support multi- rendering. The Silicon Graphics implementation of PEX also uses the multi-rendering facility and works by converting rendering requests into OpenGL commands. Mutli-rendering is contrasted with other schemes for improving server interactivity. Unlike co-routines, multi-rendering supports multi-processing; unlike multi-threading, multi-rendering requires minimal locking overhead.
A Three Color Cursor for X describes how, with SGI hardware supporting three color cursors, one can generate such cursors using X. An explication is given of how to implement the previously undocumented XSGIMiscSetThirdCursorColor routine, which allows the third color of an X cursor to be specified via the use of SGI's proprietary SGI-SUNDRY-NONSTANDARD extension. This interface is the same mechanism used by the IRIS GL's internal cursor management routines to implement three color cursors in the GL. OpenGL developers are already aware that X is how non-3D rendering tasks are performed. This means OpenGL developers should anticipate using X the generate three color cursors. This mechanism is not part of the X standard and is only supported on Silicon Graphics X servers. But it is easy to query if a given X server supports it or not so programs can be written to use three color cursors if available. And if not, programs can fall back to use two color cursors for less capable X servers.
Abstract: Incorporating layered windows into the X server is a non trivial task, which has been attempted repeatedly in the past, with varying lack of success. We present our criteria for the proper behavior of layered windows. We show that the assumptions built into the DIX windowing code prevent the proper implementation of layered windows, proving that the current windowing code is inherently device-dependent. We propose a restructuring of the sample server, moving much of the windowing code to DDX. We show how the sample windowing model can be extended to clip layered windows, and what changes are required to other parts of the server which depend in part on knowledge of the current window tree.
Abstract: Overlay planes provide an alternate set of frame buffer bitplanes which can be preferentially displayed instead of the normal set of bitplanes. Overlay planes have been common in high-end graphics systems for some time. Recently, work has been done by Silicon Graphics to integrate overlay plane support into the X Window System. A standard convention proposed and implemented by Silicon Graphics allows X client writers to create windows in the overlay planes. This article describes how to write programs to utilize overlay planes.
Abstract: The MIT X11 Sample Server is the starting point for nearly all X11 server implementations. Most server vendors add value beyond the sample server. Silicon Graphics has done extensive work to enhance the performance and functionality of its X server implementation. The server supports X across Silicon Graphics' entire line of high-performance graphics hardware. This article describes six important areas of enhancement made to the Silicon Graphics server: integration with the IRIS GL graphics library, a high performance input subsystem, the non-frame buffer porting layer, support for specific hardware features, the dynamic linking of hardware support, and the Display PostScript extension.
OR, ...
