GRADD Architecture for OS/2 for the PowerPC
by Joseph Celi
OS/2 for the PowerPC introduces a new graphics device driver (GRADD) architecture that was designed to make it easy to add support for new hardware. Independent hardware vendors (IHVs) who want to add support for a graphics adapter can write a GRADD without having to worry about learning a new operating system. In the new architecture, GRADD writers use video helper services that shield them from the operating system semantics. The only knowledge that is required is a thorough understanding of the graphics hardware and its programming interface.
The GRADD can be completely written in C. If the GRADD writers decide to write certain pieces of the GRADD in assembly language, they can. A typical GRADD, which takes full advantage of the underlying graphics hardware, can be written in about 2K to 5K lines of code. Since the GRADD consists of mainly hardware-dependent code, the complexity of programming the chip will determine the total number of lines of code that need to be written.
GRADD Architecture Overview
The GRADD model was written to be graphics-engine independent. OS/2 for the PowerPC runs under the IBM MACH microkernel. This kernel has the ability to support multiple operating system (OS) personalities running concurrently on the same system. Each OS has its own graphics engine. The GRADD architecture, being graphics-engine independent, allows one GRADD to support all of these microkernel personalities and their corresponding graphics subsystems.
The GRADD model provides a video subsystem which can be matched to any graphical user environment (GUI) running under any of the personalities. As you will see, all that is required is a translation layer that maps the graphics engine of a particular GUI to the video manager interface (VMI).
The GRADD architecture, displayed in Figure 1, consists of a GRADD, a video manager (VMAN), a software drawing library (SOFTDRAW), translation layers (GRE2VMAN and GDI2VMAN), and a virtual device driver (VVMI). PMGRE represents the Presentation Manager (PM) graphics engine, and GDI represents the Windows 3.1 graphics engine.
Figure 1. The GRADD Architecture
The GRADD model is basically a video subsystem which can be used by one or more GUIs. Figure 1 shows two graphics environments: PM and Windows 3.1. The VMI is the mechanism for video support under the GRADD architecture.
The translation layers sit between a graphics engine and the video manager. Currently, we have two translation layers: GRE2VMAN.DLL and GDI2VMAN.DRV.
GRE2VMAN.DLL translates the PM graphics engine commands into VMI commands. The PM graphics engine (PMGRE) has been enhanced so that almost no translation is required. GRE2VMAN is basically a pass-through from PMGRE to VMAN. PMGRE has also been optimized to package up the drawing commands before calling GRE2VMAN. This technique reduces the number of calls down to the video subsystem and helps overall system performance.
Seamless Windows support is accomplished in a similar manner. The Windows translation layer (GDI2VMAN) translates the Windows graphics engine (GDI) commands into VMI commands. GDI2VMAN calls VMAN indirectly via a virtual device driver called VVMI (Virtual Video Manager Interface).
The Video Manager - VMAN
VMAN is responsible for coordinating commands to a specific GRADD. VMAN exports a single entry routine, VMIEntry, which is called for all VMI commands. The function prototype for this routine is:
ULONG VMIEntry(GID gid, ULONG ulFun, PVOID pIn, PVOID pOut);
The gid field contains the ID of the GRADD to which the command is intended to be directed. Some VMI commands are handled directly by the video manager. In this case, the GID field will contain the GID_DONTCARE value.
The ulFun field contains one of the following commands that make up the VMI command set. The pIn and pOut pointers vary according to the specific VMI command. The following is a list of VMI commands:
VMI_CMD_INIT - Global initialize VMI_CMD_INITPROC - Process initialize VMI_CMD_TERM - Global termination VMI_CMD_TERMPROC - Process termination VMI_CMD_QUERYCAPS - Return capabilities VMI_CMD_QUERYMODES - Return available graphics mode info VMI_CMD_SETMODE - Set the video mode VMI_CMD_PALETTE - Set the palette or return its contents VMI_CMD_BITBLT - Bit block transfer operation VMI_CMD_LINE - Draw line operation VMI_CMD_MOVEPTR - Update the pointer position VMI_CMD_SETPTR - Set the pointer shape VMI_CMD_SHOWPTR - Change the pointer visibility state VMI_CMD_VRAM - VRAM management VMI_CMD_REQUESTHW - Request access to the hardware VMI_CMD_EVENT - Event notification VMI_CMD_EXTENSION - Extension command VMI_CMD_BANK - Switch to a specific bank VMI_CMD_QUERYCHAININFO - Return info about all GRADDs VMI_CMD_QUERYMODEINFO - Return info about current video mode VMI_CMD_EXCLUDEPTR - Register pointer exclude regions VMI_CMD_UPDATECHAININFO - Add or remove a GRADD
Figure 2. VMI commands
VMAN coordinates access to a GRADD. Therefore, the GRADD does not have to worry about serialization or multitasking issues. Because VMAN provides video helper services to the GRADDs, you can write the GRADD in an operating system-independent manner. As we migrate the GRADD model over to other operating systems, we simply port the video helper services in VMAN, which allows the GRADDs to remain unchanged.
The video manager also handles communication with the software drawing library (SOFTDRAW.DLL). A GRADD has the option to return certain commands to VMAN for simulation. In this scenario, if the command was a drawing primitive, VMAN will call SOFTDRAW. The video manager also contains full support for pointer simulation if required by the GRADD.
The Software Drawing Library - SOFTDRAW
Currently SOFTDRAW exports two functions called SDBitBlt and SDLine that VMAN uses to simulate in software bitblt and line operations, respectively. SOFTDRAW provides a generic graphics library. Given a pointer to a linear address (a VRAM bitmap or system memory bitmap), SOFTDRAW can draw the bits directly into the bitmap.
The GRADD architecture gives a GRADD the ability to take full advantage of any available graphics hardware function. This will ensure that the system is achieving the best possible graphics performance that the adapter can provide.
Allowing full hardware exploitation turns out to be a non-trivial task when dealing with graphics hardware. The past and current rate of evolution in graphics hardware is extremely hard to keep up with, from a software perspective. The GRADD architecture is able to keep up with evolution in graphics hardware because it has the built-in ability to support software extensions.
We knew from past experiences that in order to get you to write device drivers, we had make your job as easy as possible. Great measures have been taken when designing the GRADD architecture to make this happen.
A GRADD exports a single function called HWEntry that receives all of the operations from VMAN. The function prototype for HWEntry is:
ULONG HWEntry(GID gid, ULONG ulFunction, PVOID pIn, PVOID pOut);
The Graphics Hardware Interface (GHI) provides information to the GRADD in a format which is typically used by device drivers when they program the registers of the graphics adapter. All output data has been pre-clipped and points are given with respect to an origin located at the upper-left corner of the screen, which is similar to the way most graphics adapters work.
Only a small number of GHI functions are mandatory. This feature allows the GRADD writer to incrementally develop a GRADD, by selectively choosing new functions to support.
The GHI defines the various functions that can be sent to a GRADD. The full set of functions for the Base Function class is as follows:
GHI_CMD_INIT - Global initialize GHI_CMD_INITPROC - Process initialize GHI_CMD_TERM - Global termination GHI_CMD_TERMPROC - Process termination GHI_CMD_QUERYCAPS - Return capabilities GHI_CMD_QUERYMODES - Return available graphics mode info GHI_CMD_SETMODE - Set the video mode GHI_CMD_PALETTE - Set the palette or return its contents GHI_CMD_BITBLT - Bit block transfer operation GHI_CMD_LINE - Draw line operation GHI_CMD_MOVEPTR - Update the pointer position GHI_CMD_SETPTR - Set the pointer shape GHI_CMD_SHOWPTR - Change the pointer visibility state GHI_CMD_VRAM - VRAM management GHI_CMD_REQUESTHW - Request access to the hardware GHI_CMD_EVENT - Event notification GHI_CMD_EXTENSION - Extension command GHI_CMD_BANK - Switch to a specific bank
Figure 3. Graphics Hardware Interface (GHI) commands
Of these functions, only the following are mandatory:
GHI_CMD_INIT GHI_CMD_INITPROC GHI_CMD_TERM GHI_CMD_TERMPROC GHI_CMD_QUERYCAPS GHI_CMD_QUERYMODES GHI_CMD_SETMODE * GHI_CMD_PALETTE - only required if in a 256-color mode * GHI_CMD_BANK - only required if the full video aperture is not available
Figure 4. Mandatory GHI commands
If a full video aperture is available, the GRADD can pass the drawing commands back to VMAN for simulation using a return code of RC_SIMULATE. The GRADD can always return the pointer-related commands back to VMAN for simulation. VMAN has full built-in support for pointer simulation and will use the GRADD to draw the pointer to and from the screen.
GRADDs that take full advantage of the underlying graphics hardware typically handle all of these GHI commands. A fully accelerated GRADD can still pass certain GHI commands back to VMAN for simulation. For example, a graphics adapter might not have support for three-way bitblt operations. The GRADD can look at this condition and return RC_SIMULATE if it is encountered. The simulation option allows GRADD writers the ability to pick and choose what is handled at the GRADD level. With minimal effort, you can have full graphics support and spend the rest of your time optimizing the functions that best exploit your particular graphics adapter.
The GRADD architecture for OS/2 for the PowerPC provides a device driver architecture for graphics adapters. This architecture makes it easy for you to write drivers that take full advantage of your hardware's capabilities. The components that comprise the GRADD architecture ensure that all available graphics hardware assistance is used, ensuring the best possible overall system performance.