About the Skeleton Pipeline

The Solaris Device Developer's Kit (DDK) includes a template for an XGL^(TM) graphics handler. This template, called the skeleton pipeline, is provided partially implemented and will help you get started with your implementation of an XGL graphics handler.

An XGL graphics handler consists of a set of loadable renderers that send geometry data to the hardware, and a set of interface objects that provide communication between the XGL device-independent code and the device pipeline code. The pipeline interface objects form a framework that connects the device-independent code with the device pipeline rendering code. Figure 1-1 illustrates the basic components of the graphics handler.

Figure 1-1

The skeleton pipeline includes partially implemented files for the device pipeline interface objects; these files can expedite the implementation of your device pipeline. The skeleton pipeline also provides a simple implementation of line and polygon accelerated renderers that you can implement for your device.

Overview of XGL Architecture

The XGL library contains two primary components: an application programming interface (API) for application developers and a graphics porting interface (GPI) for hardware vendors. 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 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.

The top layer of the GPI, Loadable Interface 1 (LI-1), specifies the interface that lies directly below the XGL API. Functions in this layer take the points defining the primitive and transform, light (in the 3D case), and clip the geometry in preparation for the rendering operations in the next layer. The second layer (LI-2) is responsible for scan converting more complex primitives like polygons and polylines. The third layer (LI-3) is responsible for rendering pixels, individually or in spans on the device. The GPI includes a complete software implementation of the LI-1 and LI-2 layers of the pipeline for most primitives; however, the lowest layer, which is responsible for writing pixels to the device, is device dependent and is not included in the software implementation.

Device pipelines written at the LI-1 layer typically implement the full graphics pipeline for each primitive, including all LI-1 operations, scan conversion, and pixel rendering. Device pipelines written at the LI-2 layer call the software pipeline for LI-1 operations and then take over processing at LI-2, performing scan conversion and rendering pixels on the device. LI-3 device pipelines are responsible only for rendering pixels; a port at this layer uses the software pipeline for LI-1 and LI-2 operations. Hardware vendors can implement different GPI functions at different layers to tailor a port for a particular device.

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

Figure 1-2

For more information on the XGL architecture and for comprehensive information on implementing an XGL graphics handler, see the following manuals:

• XGL Architecture Guide
• XGL Device Pipeline Porting Guide
• XGL Test Suite User's Guide.

For information on the XGL library, see the following:

• XGL Reference Manual
• XGL Programmer's Guide

Design Considerations

Before you begin developing your graphics handler, you need to determine how you will handle several important design issues:

· What interface layer (LI-1, LI-2, or LI-3) will you port to? A graphics handler can include routines at all three layers, but usually the characteristics of the device will determine what interface layer is the primary porting layer.

· Which attributes and primitives can your hardware accelerate?

· Which attributes and primitives are needed by the kind of applications you are targeting? What features would those applications like to have accelerated?

· How will your graphics handler support multiple XGL contexts?

· How will your graphics handler support backing store?

· Do you need to port Direct Graphics Access (DGA) for your device?

For information on these issues, refer to the XGL Device Pipeline Porting Guide.

Files Provided With the Skeleton Pipeline

Table 1-1 lists the files for the skeleton pipeline and provides a brief description of these files. For instructions on editing these files to build a pixel-level graphics handler, see Chapter 3. For instructions on editing the sample renderers, see Chapter 4.

Table 1-1

File	Description
DpLibSkeleton.h DpLibSkeleton.cc	Header and source files for the XglDpLib object. This object is created at driver installation time. It creates one or more XglDpMgr objects.
DpMgrSkeleton.h DpMgrSkeleton.cc	Header and source files for the XglDpMgr object. This object manages hardware initialization and creates the XglDpDev object. Typically, there is one XglDpMgr object per hw device.

Table 1-1 (Continued)

File	Description
DpDevSkeleton.h DpDevSkeleton.cc	Header and source files for the XglDpDev object. This object corresponds to the XGL window raster and creates the XglDpCtx objects.
DpCtx2dSkeleton.h DpCtx2dSkeleton.cc DpCtx3dSkeleton.h DpCtx3dSkeleton.cc	Header and source files for the 2D and 3D XglDpCtx objects. These objects are created by the XglDpDev object once for every XGL context-raster association. The XglDpCtx objects contain the interfaces for the 2D and 3D primitives.
PixRectSkeleton.h PixRectSkeleton.cc	Header and source files for a device-specific PixRect object. Memory mapped devices do not need this object. If the device is not memory mapped, or only one buffer can be accessed at a time, this object is needed for pixel rendering.
Skeleton2dLi3.cc Skeleton3dLi3.cc	Source files that contain the rendering routines for LI-3 primitives.
Skeleton2dLi1Raster.cc Skeleton3dLi1Raster.cc	Source files that contain the LI-1 raster functions..
Skeleton2dLi2Pgon.cc	Source file for an LI-2 accelerated polygon renderer.
Skeleton3dLi1Mpl.cc	Source file for an LI-1 accelerated multipolyline renderer.