Optimization of Device-Independent Operations

The XGL 4.0 release of the XGL GPI includes a number of changes aimed at improving XGL's low batching factor performance. The two main goals for the optimization effort were to minimize the device-independent overhead for each graphics primitive call and to simplify the interface between the device pipelines and the device-independent code.

XGL's architecture was changed to implement the performance improvements. The new architecture differs from the previous architecture in two major ways:

• Device-independent code uses function pointers to call the device pipeline renderers directly from the API wrapper rather than through the interface manager. The functionality provided by the interface manager in the previous releases is implemented in other ways at this release, and the interface manager object is no longer present.

• Device-independent code notifies the device pipeline of Context attribute changes immediately (non-lazily) except for transform changes (which are still lazy evaluated). As a result, the update table objects are no longer present.

Changes in Rendering Architecture

This section lists changes to the rendering architecture.

Interface Manager Removed

To simplify the interactions between the device pipeline and the device-independent code, the interface manager object has been removed from the XGL architecture. Pipeline renderers are now called via function pointers in the opsVec[] array, which is defined in the XglDpCtx object. The pipeline must set up a pipeline-specific version of the opsVec[] array to point to the rendering functions for the primitives that it accelerates. If the device pipeline does not implement a function, the opsVec[] value for that function will call the software pipeline by default. See page 44 in Chapter 3, "Pipeline Interface Classes" for information on setting up the opsVec[] array. Be sure to remove the interface manager header files from your pipelines.

Because the interface manager has been removed, the device pipelines no longer call the the interface manager to access other primitives from within a given primitive. Therefore, note the following about calling the software pipeline or another LI primitive.

• Device pipelines call the software pipeline directly. Previously, the device pipeline called the software pipeline through the interface manager in these cases:

  · If the device pipeline had not implemented a renderer, it returned a value of 0 to a rendering call.

  · The device pipeline could call the interface manager with a return value of 0 in certain cases within an implemented primitive.

  · The device pipeline could call the software pipeline for partial processing of data by calling the interface manager LI function with the software override flag set to TRUE.

A pipeline return value of 0 or a pipeline call to the interface manager with the software override flag set to TRUE caused the interface manager to call the software pipeline.

At this release, the device pipeline is responsible for calling the software pipeline directly, as:

swp->li1MultiPolyline(api_bbox, api_num_plists, api_pt_list);

• Device pipelines call other LI functions through the opsVec[] array, or they can call their own renderers directly. Previously, if a pipeline created a Gcache from within li1MultiSimplePolygon() to handle certain polygon cases, the pipeline called itfMgr->li1DisplayGcache(gcache) to render the polygons. Now, any call of itfMgr->{primitiveCall} should be changed to a call through the opsVec[] array or a direct call.

  In general, you would want to use the opsVec[] array to call other primitives, since this architecture has been set up to be advantageous to subsequent primitive calls. In some device-dependent cases, calling a primitive directly might be faster. For example, for rendering polygons with edges, calling li1MultiPolyline() directly to draw the edges may be faster for some devices than using the opsVec[] array.

  Note that when calling another XglDpCtx primitive through the opsVec[] array, the call should include an extra parameter, gen_punt = FALSE, in order for backing store to work correctly.

For instructions on setting opsVec pointers in the XglDpCtx object, see Chapter 3, "Pipeline Interface Classes".

Primitive Return Types Changed

At this release, primitives are no longer virtual functions, and LI-1 and LI-2 primitive calls no longer return values. Thus, for example,

virtual int XglDpCtx3d::li1MultiArc(XglConicData* arc_data)

has become:

void XglDpCtx3d::li1MultiArc(Xgl_arc_list* arc_list)

Note that LI-3 functions have not changed.

Primitive Arguments Changed at LI-1

The arguments to LI-1 primitives have been changed to pass the API data directly to the device pipeline rather than through the XglPrimData object. Each primitive function is called directly with the application data. For example, the application calls xgl_multipolyline() as:

xgl_multipolyline(Xgl_ctx ctx, Xgl_bbox* bbox,
                          Xgl_usgn32 numPtLists,Xgl_pt_list pl[])

The corresponding call to the device pipeline was previously:

li1MultiPolyline(XglPrimData *pd);

It now is this:

li1MultiPolyline(Xgl_bbox* bbox, Xgl_usgn32 numPtLists,
                       Xgl_pt_list* pl)

See Chapter 3, "Pipeline Interface Classes" for the current LI-1 primitive arguments.

Constructor Change

The XglDpCtx constructor calling parameters have changed. Previously, its calling parameters were:

XglDpCtx{2,3}d(context)

At this release, the calling parameters are:

XglDpCtx{2,3}d(dp_dev->getDevice(), context)

Changes in State Handling

As with the interface manager object, the update tables have been removed to optimize the internal architecture. In place of the update tables, the pipeline should create the following two functions and insert pointers to them in the opsVec[] array:

• objectSet() - Function that passes information on Context attribute changes to the device pipeline when changes occur.
• messageReceive() - Function that passes the device pipeline information on attributes changes in objects other than the Context.

You can copy these functions from the GX sample pipeline and update the XGL Context types in the switch statement with the Context types appropriate for your hardware.

As an alternative, the pipeline can retrieve Context attributes every time it renders. However, for optimized performance, the objectSet() architecture is recommended for LI-1 primitives.

Be sure to remove the update table header files from your existing renderers. In addition, remove all references to update table masks. For information on Context state handling at this release, see Chapter 4, "Handling Changes to Object State".

Derived Data Change

Derived data has the same interface at this release except for the updateTableChanged() function. Previously, a device pipeline called the udTable.updateTableChanged()function to determine whether changes to derived data occurred. Because the update tables have been removed, the view group function changedComposite() has been modified to incorporate the quick test for derived data changes that the update table provided. Therefore, viewGrpItf->changedComposite() is now the first indication that derived data may have changed. For information on the derived data mechanism, see Chapter 6, "View Model Derived Data".

Application Data Passed Directly to Pipelines

As mentioned above, the XglPrimData object is no longer used to process data from the application at LI-1. LI-1 primitive functions now receive actual API data instead of the preformatted data in the XglPrimData objects. Because of this, arguments for LI-1 primitive functions have changed. Be sure to remove all references to XglPrimData from LI-1 primitives.

Utility Arguments Changed

The calling arguments for the utilities that took XglPrimData objects as an argument have changed. Table C-1 lists the changed utilities. These utilities now take the API data in place of XglPrimData object data.

Table C-1 Changed Utilities for XGL 3.1

Changed Utilities XgliUtComputeFn XgliUtComputeFnReverse XgliUtComputeIndepTriFn XgliUtComputeIndepTriFnPl XgliUtComputeMspFn XgliUtComputePolygonFn XgliUtComputeQuadMeshFn XgliUtComputeTstripFn XgliUtComputeTstripFnPl XgliUtComputeTstarFn XgliUtComputeTstarFnPl XgliUtComputeVnReverse XgliUtMellaToPline XgliUtModelClipMarker XgliUtModelClipMpline XgliUtModelClipMspg XgliUtPdModelClipPgon XgliUtModelClipTstrip XgliUtVertexOrientation XgliUtClassifyMsp XgliUtClassifyPgon