Introduction to the XGL Product

The XGL product is a foundation graphics library that provides geometry graphics support for Solaris^(R)-based applications. The XGL library has two sets of interfaces: an application programming interface (API) and a graphics porting interface (GPI).

The XGL API provides application developers with immediate-mode rendering, a rich set of graphics primitives, view and modeling transforms, and separate, complete 2D and 3D rendering pipelines. Standard features include 2D and 3D primitive support; depth cueing, lighting, and shading; non-uniform B-spline curve and surface support; and direct and indirect color model support. Advanced features include transparency, antialiasing, texture mapping, stereo, and accumulation buffer for motion blur and other special effects. Application developers and developers of other graphics APIs can port their applications to XGL and take advantage of Solaris dynamic linking to provide portable shrink-wrapped applications that run on any graphics device supported in the Solaris environment. The XGL API is provided as part of the Solaris Developer's Kit; for more information on the XGL API, see the XGL Reference Manual and the XGL Programmer's Guide.

The XGL GPI is a device-level interface that defines the mapping of XGL device handlers to underlying hardware. Hardware vendors that write XGL device handlers can build graphics devices that support any binary XGL application. The XGL architecture provides open, well-defined interfaces that facilitate the task of implementing device handlers.

Solaris Dynamic Linking

The Solaris 2.x operating system includes support for dynamic linking of shared libraries. A shared library is a library that can be dynamically linked during the running of the application. Under dynamic linking, the contents of the shared library are mapped into the application's virtual address space at runtime. References by the application to the functions in the shared library are resolved as the program executes.

The Solaris environment provides mechanisms to dynamically load both kernel device drivers and user process shared libraries. These facilities allow a hardware vendor to incorporate a new graphics accelerator into the Solaris environment by providing a dynamically loadable kernel device driver and an XGL device handler.

XGL Loadable Interfaces

The XGL GPI consists of three layers of device pipeline interfaces. Each layer defines a set of rendering tasks that must be accomplished before proceeding to the next layer in the pipeline. More complex operations, such as transformations, lighting, and clipping, are performed in the uppermost layer; less complex operations, such as scan conversion, are performed in the lower layers. You can implement GPI functions at varying layers to tailor a port for your device.

The XGL GPI includes a complete software implementation of the top two layers of the pipeline for most primitives. The lowest layer, which is responsible for writing pixels to the device, is device dependent and has not been included in the software implementation.

You can choose a layer for your device handler based on the functionality of your device and let the XGL software implementation handle the rendering of functionality not accelerated by the device. The selection of the interface layer to port to can be made for each graphics primitive. Before each layer calls the layer below it, a device handler has the opportunity to either interpose its own code for a particular primitive or let the XGL-supplied software implementation perform the rendering tasks. Thus, for each primitive, a device handler can be called at the layer for which it is best adapted.

The functions comprising the software implementation and the device-dependent functions that replace them are grouped into separate dynamically loadable libraries. The set of device-dependent functions is called the device pipeline. The complete software implementation is called the software pipeline. At runtime, when an application program calls a primitive, the XGL device-independent code decides whether to render using the software pipeline or the device pipeline. This decision depends on the capabilities of the hardware and on the current XGL primitive and the current graphics state as defined by XGL's attributes.

Loadable Interface 1 (LI-1)

The topmost layer is called Loadable Interface 1, or LI-1. This layer is directly below the XGL API. An LI-1 device handler is responsible for all aspects of drawing an XGL primitive, including transformation, clipping (view and model), lighting, and depth cueing. Devices that port to this layer for some or all of the XGL primitives are responsible for all operations required for rendering, including scan conversion and rendering of pixels. Although this is the most difficult layer to port to, a port to LI-1 enables full acceleration on a graphics device.

Loadable Interface 2 (LI-2)

The second layer, LI-2, is responsible primarily for scan converting more complex primitives like polygons and polylines. Porting to this layer assumes some responsibility for rendering (especially if the hardware supports scan-conversion of primitives) but leaves the processing of the geometry (transformation, clipping, and so on) to the XGL software version of the layer above.

Loadable Interface 3 (LI-3)

The lowest layer in the device pipeline, LI-3, is responsible for rendering pixels and vectors individually, or in spans. If you port to this layer, you need only implement vectors, span, and dot renderers. All other operations needed to process an API primitive and reduce it to this level are provided by XGL's default software implementation.

Because writing pixels to the frame buffer is device dependent, the software pipeline does not implement the LI-3 layer. Device handlers for new devices must implement LI-3 functions. To assist you with an LI-3 port, XGL provides utilities that perform pixel operations. You can call these utilities in place of writing a device-specific LI-3 layer.

Figure 1-1 illustrates the layers of the device pipeline and software pipeline as well as some of the components of the XGL device-independent code.

Figure 1-1

As mentioned above, the decision as to which layer to port to can be made on a per-primitive basis. For example, if a particular hardware device can render polylines but not polygons, a device handler for that device might implement the polyline primitive at LI-1 and let the XGL software pipeline render the polygons. At any time, a device handler can override the default software

interface provided by XGL. This choice is dynamic and is flexible enough to permit a variety of hardware devices to fully utilize their capabilities to draw XGL primitives.

---

Note - Currently, the XGL graphics porting interface is unstable. It is possible that this interface could change in the future in ways that could require changes in device pipelines.

---