View source for 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.

[[Image:GRADD-Fig1.png]]

''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.

==Translation Layers==
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==
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.

==Summary==
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.

[[Category:Developer Connection News]][[Category:OS/2 Warp PowerPC Edition]]