Direct access to slave processing by unprotected application using context saving and restoration

Abstract

A computer system provides multiple unprotected applications direct access to a slave processor. The host processor issues context switching requests to save and restore partially completed unprotected requests in the slave processor.

Claims

I claim:

1. A computer system providing a plurality of user applications concurrently running on a host processor direct access to a slave processor comprising:

an input buffer including a separately addressable nonprotected buffer and protected buffer, such that it is the nonprotected buffer and not the protected buffer into which communications from any of the plurality of user applications are written;

an output buffer;

means for sending a context save request to the protected buffer of said input buffer when processing in the host processor switches from one of the plurality of user applications to another of the plurality of user applications;

means, in said slave processor, for writing in said output buffer a save frame of data words representing partially completed requests sufficient to describe the internal dynamic state of the slave processor for the user application currently communicating with the slave processor upon recognizing the context save request in the protected buffer of said input buffer; and

means, in said slave processor, for restoring the internal dynamic state of the slave processor by loading the save frame for a next user application to communicate with the slave processor into said input buffer and executing the data words in the save frame.

2. The computer system of claim 1 wherein the slave processor comprises a graphics processor.

3. The computer system of claim 1 wherein said means for writing further includes means for writing a word count in said output buffer to indicate the number of data words in the save frame for a given user application.

4. The computer system of claim 1 wherein said output buffer is a FIFO.

5. A computer system providing a plurality of applications concurrently running on a host processor direct access to a slave processor comprising:

an input buffer;

an output buffer;

means, in said host processor, for sending a context save request to said input buffer when processing in the host processor switches from one of the plurality of applications to another of the plurality of applications;

means, in said slave processor, for writing in said output buffer a save frame of data words representing partially completed requests sufficient to describe the internal dynamic state of the slave processor for the application currently communicating with the slave processor upon recognizing the context save request in said input buffer; and

means, in said slave processor, for restoring the internal dynamic state of the slave processor by (a) loading the save frame for a next application to communicate with the slave processor into said input buffer and (b) executing the data words in the save frame.

6. The computer system of claim 5 wherein the slave processor comprises a graphics processor.

7. The computer system of claim 5 wherein said means for writing further includes means for writing a word count in said output buffer to indicate the number of data words in the save frame for a given application.

8. The computer system of claim 5 wherein said output buffer is a FIFO.

9. A computer system providing a plurality of user applications concurrently running on a host processor direct access to a slave processor comprising:

an input FIFO including a separately addressable nonprotected FIFO and a protected FIFO, such that it is the nonprotected FIFO and not the protected FIFO into which communications from any of the plurality user of applications are written;

an output buffer;

means for sending a context save request to the protected FIFO of said input FIFO when processing in the host processor switches from one of the plurality of user applications to another of the plurality of user applications;

means, in said slave processor, for writing in said output buffer a save frame of data words representing partially completed requests sufficient to describe the internal dynamic state of the slave processor for the user application currently communicating with the slave processor in response to recognizing the context save request in said input FIFO; and

means, in said slave processor, for restoring the internal dynamic state of the slave processor by loading the save frame for a next user application to communicate with the slave processor into said input FIFO.

10. The computer system of claim 9 wherein the slave processor comprises a graphics processor.

11. The computer system of claim 9 wherein said means for writing further includes means for writing a word count in said output buffer to indicate the number of data words in the save frame for a given user application.

12. The computer system of claim 9 wherein said output buffer is a FIFO.

13. The computer system of claim 9 wherein said means for restoring further includes executing the data words in the save frame for the next user application.

Description

RELATED APPLICATIONS

Disclosure generally pertinent to the context of the present invention is contained in the following related applications, all filed on the same day as the application herewith, and having the same assignee as the present application: "Apparatus and Method for A High-Performance Video Controller," Ser. No. 08/432,106, for an invention of William Steve Pesto, Jr.; "Vertex List Management System," Ser. No. 08/432,314, for an invention of Jeffrey J. Holt; "Video Stream Data Mixing for 3D Graphics Systems," Ser. No. 08/431,821, for an invention of David W. Young and Jeffrey J. Holt; "Graphics Processing with Efficient Vector Drawing," Ser. No. 08/432,029, for an invention of Jeffrey J. Holt; "FIFO Logical Addresses for Control and Error Recovery," Ser. No. 08/431,313, for an invention of Jeffrey J. Holt and David W. Young; and "System and Method for Controlling A Slave Processor," Ser. No. 08/432,272, for an invention of David W. Young and Jeffrey J. Holt. These related applications are hereby incorporated herein by reference.

BACKGROUND OF THE INVENTION

The present invention relates to a host computer running multiple unprotected applications concurrently. Typically, when multiple unprotected applications are running on a computer, they must act through the system software to access a slave processor, such as a graphics processor. In this manner, the system software can coordinate requests to the slave processor. The system software builds the requests for each application and sends the requests in orderly fashion to the slave processor for processing. If applications were to send requests directly to the slave processor, confusion may readily arise in the processor particularly with respect to multiple word requests. After the first data word of a request, the slave processor will be expecting and will interpret the next data word as the second data word in the request. If the next data word were to come from another application competing for use of the slave processor, the slave processor would not know how to interpret that data except as the second data word in the original request. To avoid confusion in the slave processor, typically all communications with the slave processor are directed through the system software. It is an object of the present invention to relieve the system software of some of the processing requirements in dealing with multiple unprotected applications running concurrently and desiring access to a slave processor. Moreover, the still further object of the invention is to provide direct access for applications to a slave processor.

SUMMARY OF THE INVENTION

The present invention is directed to a computer system providing a plurality of unprotected applications concurrently running on a host processor with direct access to a slave processor. In particular, the slave processor is a graphics processor. An input buffer includes a separately addressable nonprotected buffer and protected buffer. Communications directly from any of the plurality of applications are directed to the normal buffer. When the host processor switches from one of the plurality of applications to another of the plurality of applications, a context save request is sent to the protected buffer by the host processor. The slave processor responds to a context save request by saving data words into an output buffer sufficient to describe the internal dynamic state of the slave processor for the particular application that was in communication with the slave processor at the time the context save request was received. A next application to provide requests to the slave processor is preceded by restoring of the internal dynamic state of the slave processor from the output buffer for that application. Thus, in accordance with the embodiment of the present invention, the host processor controls context saving and restoring in the slave processor as the host switches from running one application to the next. Even if the switching happens in the middle of a request to the slave processor, by saving the context and restoring it the next time the application is running, it appears to the application that it has uninterrupted direct access to the slave processor. Rather than bundling requests from the applications and maintaining total control over communications with the slave processor, the host processor only needs to control the context switching operation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of showing modules of a video graphics processor-controller in accordance with a preferred embodiment of the present invention;

FIG. 2 is a block diagram of a graphics processor system in accordance with a preferred embodiment of the present invention;

FIG. 3 is a block diagram of a frame buffer system in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

I. Architecture

A preferred embodiment of the present invention has been implemented in a graphics controller-processor having the general structure shown in FIG. 1. This embodiment is suitable for use with computers, such as those utilizing the Intel family of 80X86 processors (including the Pentium), running an operating system such as Microsoft Windows NT, designed to communicate over a PCI (Peripheral Component Interchange) Local Bus, pursuant to the PCI Local Bus Specification version 2.0 (Apr. 30, 1993) published by PCI Special Interest Group, M/S HF3-15A, 5200 N.E. Elam Young Parkway, Hillsboro, Ore. 97124-6497, which is hereby incorporated herein by reference. However, the embodiment may also be configured, for example, to operate in an X-windows Unix environment, and on other buses, such as VL (VESA local bus). There are different implementations of this embodiments architecture that may have reduced functionality and/or plane sets.

The architecture can be broken down into six basic subsystems. Of these two are optional. The basic system has a graphics engine 12 that accepts requests via a FIFO buffer 11. These requests are broken down by the graphics engine 12 into pixel requests, which are written over a wide high speed bus 17 to a set of resolvers 13, which in turn control reading and writing of the frame buffer 14. The back end subsystem 18 reads the frame buffer and displays it on the screen of a suitable monitor.

The texture processors 15 and roam processor 16 are optional subsystems. The roam processor subsystem includes its own resolvers 161 and roam frame buffer 162.

FIGS. 2 and 3 are more detailed block diagrams of a graphics processor system and a frame buffer system in accordance with the embodiment of FIG. 1 and are referred to in the discussion below. The rendering subsystem includes the PCI buffer 202, which is an ASIC, the DMA ASIC 211, graphics FIFO 21, and graphics engine ASIC 22. Rendering is the process of drawing triangles, lines, and line strings. The rendering subsystem also performs region fill operations, but expands, and blit operations. Software on the host processor performs the necessary 3D transform and lighting calculations. These calculations result in vertex data which consists of coordinate (X,Y,Z) and color information (R,G,B,A). The host computer typically sends the vertex data to a buffer in main memory.

The vertex data enters the rendering subsystem through the PIC bus interface in the PCI buffer ASIC 202. The PCI buffer 202 ASIC provides an internal FIFO to allow PCI bus burst transfers. It also provides an interface to the expansion cable.

The DMA ASIC 211 is a multichannel, Direct Memory Access (DMA) engine capable of burst transfer for lengths of up to 4 MB. The system software uses the DMA ASIC to transfer vertex data from main memory of the host computer to the graphics FIFO 21.

Graphics Engine

The graphics engine ASIC 22 is the main graphics processor and the core of the rendering subsystem. It takes vertex data from the graphics FIFO 21 and produces rendered spans of pixel data. The graphics engine ASIC 22 sends the data to the frame buffer subsystem over a high speed pixel path called the Image/Z (IZ) bus 27.

The graphics engine uses for major logic blocks to perform the pixel rendering. They are: (1) request handler, (2) slope calculation, (3) span generation, and (4) pixel interpolation.

Request Handler. The request handler monitors the output of the graphics FIFO 21 for data. When data arrives, the request handler analyzes it and writes it to an appropriate processing block. The request handler routes vertex data for triangles and lines to the slope calculation block. Drawing requests (other than vertex data for triangle and lines) such as blits, fills, and bit expands, bypass the slope calculation and span generation blocks. The request handler routes this data directly to the pixel interpolation block.

Slope Calculation. The slope calculation block performs the slope calculation part of the rendering process for triangles and lines. Floating-point math ensures the accuracy of triangle edges. The slope calculation block calculates color derivatives, depth derivatives, and edge slopes. It also adjusts the vertex data to a pixel center for the topmost vertex. The slope calculation block converts all data to a fixed-point format and routes it to the span generation block.

Span Generation. The span generation block performs the span calculation part of the rendering process for triangles and lines. The span generation block determines the leftmost x and y coordinates for each scan line in a triangle. It also calculates the initial color and depth value for each scanline, and routes the data to the pixel interpolation block.

Pixel Interpolation. The pixel interpolation block is common for all graphics drawing requests. For triangle meshes, the pixel interpolation block expands the data from the span generation block to pixel data by successively adding the x-derivative value to the initial color and depth values (z) for each span. The pixel interpolation block also maps the (x,y) address to a linear address before sending the address and pixel data to either the frame buffer or texture subsystem 250 over the IZ bus. The IZ bus 27 is a 64 bit, 256 MB per second bus with a pixel span protocol to facilitate high data throughput. This protocol allows burst transfers of pixel data to occur between the rendering subsystem and the frame buffer subsystem. The maximum burst size is 4096 pixels.

The graphics engine 22 is thus an ASIC that receives requests from a host processor via the PCI system bus 201. Requests are written to graphics FIFO buffer 21 and are read, decoded and executed by the graphics engine 22. Requests include graphic primitives (points, lines and triangles), rectangular fill, get/put pixel data, blits, and control requests.

These requests are broken down into "span" requests--requests to read or write a horizontal sequence of adjacent pixels. The span requests are written to the "IZ" bus 27. For requests which require read back data, such as register read or frame buffer read requests, an output FIFO is provided. Both the input and output portions of FIFO 21 are accessible by programmed or DMA transfers. DMA controllers 211 are provided on board.

The graphics engine also supports a second FIFO interface which can connect to a boardset enabling fast JPEG decompression and display to the frame buffer.

Graphics FIFO

The graphics FIFO buffer 21 is implemented in an unusual way on the input side to permit efficient control and error recovery. Although there is only a single physical FIFO used to receive requests, there are three logical FIFO addresses, all mapping to the same physical FIFO. The three logical FIFOs are normal, protected, and sync. The normal FIFO is used for handling drawing onto the display screen. Whereas system level code has access to all three logical FIFOs, the user via the application can utilize only the normal FIFO.

The graphics FIFO 21 is implemented as 4.times.9 bit input FIFOs, giving a 36 bit bus between the PCI bus interface and the graphics engine. The low 32 bits of this bus correspond to the 32 bits of request code and/or data and are as defined in the section on requests. The 4 extra bits generated by the bus interface logic are defined as follows: ##STR1##

The P bit will be set if the data was written to one of the two protected logical FIFOs. This indicates to the graphics engine that it is OK to perform the request if it is one of the protected requests. The S bit will be set if the request was written to the sync FIFO address. This bit is monitored while flushing the FIFO. Note that the S bit is ignored unless the P bit is also set.

For diagnostic purposes the two FIFOs can be turned around by setting FIFO.sub.-- TURN.sub.-- H in the CSR. In this mode all 36 bits of the input FIFO are read out and written to the output FIFO. As the output FIFO is read, the S and P bits above are latched and may be read back as the FF.sub.-- SYNC.sub.-- H and FF.sub.-- PROT.sub.-- H bits in the SSR.

Error handling in utilizing the sync FIFO is described in the last section, ERROR HANDLING below.

Resolvers

The four resolver ASICs 331-334 on the graphics processor board control the flow of data to and from the frame buffer memory. These resolvers provide a 256-bit frame buffer interface. This wide interface allows the embodiment to achieve a very high drawing bandwidth. The resolvers thus coordinate the movement of data from the frame buffer memory to the video selector and mapper (VSM) ASIC chips 381-388 and DAC 39 (digital to analog converter) in the display subsystem. The graphics engine ASIC 22 sends interpolated pixel data over the IZ bus 27 to the resolver ASICs IZ input FIFO. The pixel data consists of color (Red, Green, Blue, and Alpha--RGBA) and depth (Z) data. The resolver IZ input FIFO is 128 words deep, so that the resolver can accommodate bursts of pixel data without slowing overall system performance.

The resolver examines pixel data from the input FIFO and determines if it should write the pixel data to the VRAM on the frame buffer board. The resolver performs Z, mask and alpha tests to determine if data should be written.

The resolver may perform an Arithmetic and Logic Unit (ALU) operation on a combination of the source data (data from the graphics engine) and the destination data (data in VRAM). The operations include logical operations, Porter and Duff style alpha blend operations, and OpenGL style alpha blend operations.

The resolver performs several different types of VRAM write cycles including reads, writes, or read-modify-writes. It maximizes memory bandwidth by choosing an appropriate type. The resolver performs block write cycles to maximize performance for window clear and fill requests.

The resolvers 331-334 are thus a set of identical ASICs that accept span requests over the IZ bus 27 and read from or write to the frame buffer formed by VRAM memory chips 341-314. They also perform the following tasks:

masking

alpha test

Z buffering

frame buffer merge (read/modify/write) operations:

X windows ALU operations

alpha blend operations

Frame buffer

The basic system contains one frame buffer virtual screens are not supported but in a typical embodiment 34 MB of memory is provided by 136 VRAMs, each VRAM having 2 megabits of memory. Each pixel in the frame buffer memory in this embodiment then has 126 bits or planes, as follows:

Image planes: double buffered 24 bit RGB planes. These can be used either as 24 bit RGB color, or any of the 3 groups of 8 can be used in pseudo color mode.

WID2: 4 bit single buffered Window ID planes associated with the image planes.

Image VLT context: 3 bit double buffered Video Lookup Table context select

Overlay planes: double buffered 8 bit pseudo color planes. These planes display if the value is non-transparent (selectable as 0 or 0.times.FF), otherwise the RGB planes "below" it display.

WID1: 4 bit single buffered window ID planes associated with the overlay planes.

Overlay VLT context: 1 bit double buffered video lookup table context select

Highlight plane: double buffered 1 bit highlight plane if non-transparent (selectable 0 or 1) this will display overriding both the RGB planes and the overlay planes.

WID0: 4 bit single buffered window ID planes associated with the highlight plane.

8 bit single buffered alpha planes which are used by the resolver for alpha blend operations on the image planes

Z buffer: 32 bits single buffered. Z buffering can be enabled for writes to any of the planes.

mask planes: 6 mask planes are available. Any combination of 0 or more may be enabled for reads and/or writes. Mask plane 0 is designated as the "user mask plane" and intended for application use.

The WID bits allow window based double buffering on up to 15 different windows independently in each of the three sets of planes. They are also used to specify RGB to VLT routing for the image planes, and are used to allow roam buffer display in a window.

Most writes to the frame buffer are to a single "visual"--ie a single set of planes. For example, visual 2 is the image (RGB) set of planes, and visual 1 is the overlay set of planes.

Certain "implied" data may be written at the same time a write occurs to some visuals. The implied data comes out of a static register in the graphics engine (via the span header) and consists of the control data which is listed with the visible planes above for example a write to the image planes can also write the WID2 bits and the image VLT context bits. Implied writes may be independently enabled or disabled via write enables.

Note that different implementations of this architecture may contain a subset of the above planes.

Back end

The back end has a set of VSMs 381-388 (Video Selector and Mapper) which drive RAM DACs 39 (Digital to Analog Converters), and the video timing logic. the VSM ASIC receives pixel data from the frame buffer. It selects which buffer (front or back), and which data (image or overlay), to display. The VSM uses the video selection planes to choose a VLT mapping if it decides to display image planes. The VSM sends the mapping result to the DAC on the processor board. The VSMs thus read the appropriate planes of the frame buffer, perform lookup through one of the 8 VLTs, and send RGB to the RAMDACs.

The DAC converts pixel data from the VSM to an analog voltage and sends it to a monitor 391 for display. The integrated DAC contains a Video Lookup Table (VLT) consisting of 256 locations.times.3 colors (RGB).times.10 bits per color used for gamma correction. The DAC also provides a user definable 64.times.64 pixel hardware cursor.

For each of the three plane sets (highlight, overlay and image) the WID bits associated with those planes are used to index into one of three small lookup tables. A bit in this LUT selects which buffer is to be displayed for that plane set. The LUT associated with the image planes also is used to specify routing between the RGB planes and the VLTs. The overlay VLT context bit is used to select between VLT context 0 and 1. The image VLT context bits can select any of the 8 VLT contexts available. All VLT contexts are capable of being specified as either pseudo color or true color when driven by the image visual.

Bits in the WID tables are also provided to select the roam buffer, and disable display of the overlay and highlight planes.

Roam processor subsystem

The roam subsystem is shown in FIG. 1. (For purposes of simplicity, it is not shown in FIG. 3, but is generally analogous in structure to the frame buffer structure shown in FIG. 3.) This subsystem is effectively an additional frame buffer larger than the actual screen size. This buffer can be roamed in a toroidal fashion within a window in the static frame buffer. The frame buffer has:

image: single buffered RGB planes (24)

image VLT context (3 bit single buffered)

overlay: single buffered (8)r

overlay VLT context (1 bit single buffered)

highlight: double buffered (2)

mask planes (2)

It has a set of resolvers 161 that are configured as "roamers" connected to the IZ bus 17, the frame buffer 14 as above, and a pixel shifter followed by a set of VSMs (like 381-388) which feed into the digital RGB stream to the RAMDACs 39. Since the VLTs are in the VSMs, the roam buffer has its own set of 8 VLT contexts.

The roam buffer displays through a window defined by the WID bits in the static frame buffer. Each of the WIDs index into their lookup table in the static frame buffer VSMs, and if all three enable the roam buffer, the roam buffer will display. If any do not select roam, roam will not display. This allows static frame buffer pixels to overlay the roam buffer.

Texture processor

The texturing subsystem 250 is an optional subsystem which interfaces solely through the IZ bus 27. The texturing subsystem 250 logically lies between the rendering subsystem and the frame buffer subsystem. The texturing subsystem 250 comprises four texture processor ASICs 251-254 and 32 MB of texture memory 251a, 252a, 253a and 254a. Each texture processor ASIC performs texturing operations for a single band (red, green, blue or alpha) or texture memory.

The texture processors 251-254 receive two types of setup parameters from the graphics engine 22: one type for triangles and one type for pixel spans within a triangle. The triangle setup parameters consist of texturing control information and texture coordinate derivatives, and the pixel span setup parameters consist of initial texture coordinates. These texturing processors 251-254 correct for perspective during texture coordinate interpolation and thereby reduce image distortion.

The texture memory is capable of storing several sets of mip-mapped textures for subsequent texture mapping. In mip-mapping, multiple-sized versions of a texture are stored. Each version is filtered to account for distance from the viewer. The texture processor chooses eight texels nearest the actual texel value from the nearest two mip maps. The texture processor interpolates these eight texels to produce the actual texel value through the use of trilinear interpolation. The actual texel value replaces or blends with the Gouraud shaded pixel value generated by the graphics engine 22. Finally, the texture processors route the textured pixels to the resolvers 331-334 and the resolvers 331-334 write the textured pixels into the frame buffer 341-344.

When the graphics engine 22 receives textured requests (that is, requests which contain texture coordinates), it sends special span requests to the texturing subsystem 250 over the IZ bus 27. The texturing subsystem 250 intercepts these spans, textures the pixels within it, and then resends the span to the resolvers 331-334. Texture memory 251a, 252a, 253a, and 254a looks like frame buffer memory 341-344 to the graphics engine, and is loaded/read back by normal get/put and fill operations.

II. Implementation

Graphics Engine

The graphics engine 22 is request-based, in that it receives requests from a host processor to perform draw, data movement, and control operations affecting the frame buffer. The host processor is responsible for performing all floating point calculations, such as lighting, transformations, etc.

The types of operations performed by the graphics engine are listed below, along with some performance figures for 1.3 and 2 MPix systems:

    ______________________________________
    Request            Peak Performance
    ______________________________________
    Vectors            1.4M/s (10 pixel)-aliased
                       550K/s (10 pixel)-
                       antialiased
    BitBlits (masked)  18 MPix/s/64-planes-
    BitBlits (non-masked)
                       26 MPix/s/64-planes
    Slow Recfills      30 MPix/s
    (with masking, ALU)
    Fast Recfills      400 MPix/s
    Triangles          450K+/s (50 pixel avg.)
    Expand Bitmap      32 MPix/s
    Putblock8          32 MPix/s
    Putblock32         25 MPix/s (bus limited)
    Putblock32/Z       12 MPix/s (bus limited)
    Getblock8          32 MPix/s
    Getblock32         25 MPix/s (bus limited)
    Getblock32/Z       12 MPix/s (bus limited)
    Load VLTs          2 Contexts/vertical blank
    Save/Restore Context
                       32 words of data
    ______________________________________

    ______________________________________
    Description       planes  buffering
    ______________________________________
    Highlight         1       double
    Overlay           8       double
    Overlay VLT Context
                      1       double
    Image             24      double
    Image VLT Context 3       double
    Alpha             8       single
    WID               12      single
    Z buffer          32      single
    Mask              6       single
    ______________________________________

    ______________________________________
    Description       Planes  Buffering
    ______________________________________
    Image             24      single
    Overlay           8       single
    Highlight         1       double
    Image Vlt Context 3       single
    Overlay Vlt Context
                      1       single
    Mask planes       2       single
    ______________________________________

    ______________________________________
    bits 14:0  these bits map to bits 14:0 of the
               GE.sub.-- GCR (graphics engine graphics control
               register). Under the subhead *Vector
               Requests* in the section below entitled
               DRAW REQUESTS, is a description of the
               various graphics engine registers; there
               the function of these bits in the
               context of the GE.sub.-- GCR is explained..
    bit 15     GE.sub.-- GCR write enable
    GE.sub.-- GCR.sub.-- WE .sub.-- H
               If set then bits 14:0 above will be written
               to the GE.sub.-- GCR before the request is executed.
               The GE.sub.-- GCR will be permanently modified. If
               this bit is not set the bits currently in the
               GE.sub.-- GCR will be used. The write is subject to
               masking by the GE.sub.-- GCR.sub.-- WEMASK register.
    ______________________________________

    ______________________________________
    bit 31         0 reserved
    bit 30         0 reserved
    bit 29         1 for requests which return data
    bit 28         1 for protected requests
    bits ›27:24!   major request ID
    bits ›23:16!   vertex format for draw requests
                   request modifier/subrequest code
                   for other requests
    ______________________________________

    ______________________________________
    00       packed 16 bit for X, Y and U, V (X, U low). Z, S
             unsigned 32 bit.
    01       32 bit, signed integer for X, Y, U, V. Z, S are
             unsigned.
    10       IEEE single precision floating point
    11       IEEE double precision floating point.
    ______________________________________

    ______________________________________
    XF      DATA TYPE    Terminator
    ______________________________________
    00      integer (X, Y)
                         0 .times. 80000000
    01      integer X coord
                         0 .times. 80000000
    10      float X coord
                         NaN with exp = 255, bits
                         ›22:19! = 1
    11      double X coord
                         NaN with exp = 2047, bit 51 = 1
    ______________________________________

    ______________________________________
    GE.sub.-- GCR
    VEC.sub.-- AA.sub.-- H
                    enables antialiasing
    VEC.sub.-- SEGMENT.sub.-- H
                    vector is segments no linestrings
    VEC.sub.-- SYMB.sub.-- H
                    symbolize vector
    VEC.sub.-- DRAW.sub.-- FIRST.sub.-- H
                    draw first pixel of segments
    VEC.sub.-- DROP.sub.-- LAST.sub.-- H
                    don't draw last pixel of segments
    FIX.sub.-- VER.sub.-- H
                    fix X, Y endpoints
    SHADE.sub.-- FLAT.sub.-- H
                    each segment is constant color
    DITHER.sub.-- EN.sub.-- H
                    enables dithering
    ATST.sub.-- EN.sub.-- H
                    enable alpha test
    Z.sub.-- EN.sub.-- H
                    enables Z buffering
    BG.sub.-- WE.sub.-- H
                    enable write of "off " symbolized
                    pixels
    UMASK.sub.-- PO.sub.-- H
                    selects the polarity for plane O
                    masking
    UMASR.sub.-- PLN.sub.-- EN.sub.-- H
                    write enable for user mask plane
                    (visual 8)
    VEC.sub.-- CONTIN.sub.-- SYMB.sub.-- H
                    continue vector symbology
    STEREO.sub.-- EN.sub.-- H
                    stereo addressing mode
    STEREO.sub.-- F1.sub.-- H
                    stereo field 1 selected
    STEREO.sub.-- DITHER.sub.-- H
                    stereo dithering mode
    COORD.sub.-- OFFSET.sub.-- H
                    coordinates are offset
    OFFSET.sub.-- 4K.sub.-- H
                    offset is 4K
    WRITE.sub.-- MASK.sub.-- EN.sub.-- H
                    enables masking
    MASK.sub.-- EN.sub.-- H›5:0!
                    selects which mask planes are used
                    for masking
    GE.sub.-- GCR.sub.-- WEMASK
    Selects which bits in the GCR may be modified by the
    control part of the request word
    GE.sub.-- FGCOLOR
    this defined the data written for requests which do not
    include a color as part of the vertex data, and alpha
    for requests in which alpha is not included in the
    vertex data.
    GE.sub.-- BGCOLOR
    defines the color of "off" pixels of symbolized lines
    if BG.sub.-- WE.sub.-- H is set in the GE.sub.-- GCR.
    GE.sub.-- Z
    this defines the Z value which will be used for Z
    buffering if it is enabled, and Z is not included with
    the vertices.
    GE.sub.-- MISC.sub.-- DATA
    this defines "implied" data which will be written to
    control planes if the appropriate plane enables are
    set, and the visual is one of 0-5. See section on
    visuals for description of implied data for each
    visual.
    GE.sub.-- SYMBOLOGY
    GE.sub.-- SYMB.sub.-- CTRL
    GE.sub.-- AA.sub.-- CTRL
    controls antialiasing parameters
    GE.sub.-- WORG or: GE.sub.-- ROAM.sub.-- WORG
    GE.sub.-- SWIDTH or GE.sub.-- ROAM.sub.-- SWIDTH
    GE.sub.-- DITH.sub.-- CTRL
    GE.sub.-- TEX.sub.-- ORG
    GE.sub.-- TEX.sub.-- BCOLOR
    GE.sub.-- TEX.sub.-- CTRL
    GE .sub.-- ATST.sub.-- CTRL
    Value and function used for alpha test if enabled
    GE.sub.-- ZFUNC
    selects the Z buffer function performed if Z buffering
    is enabled
    GE.sub.-- FBFUNC
    selects the frame buffer merge function to be performed
    GE.sub.-- BUFSEL
    selects which visual is written to, plus selects which
    buffer of the visual, or roam buffer.
    GE.sub.-- IMAGE.sub.-- PLN.sub.-- EN
    plane enables for the true color visual
    GE.sub.-- OL.sub.-- PLN.sub.-- EN
    plane enables for overlay visuals
    GE.sub.-- HL.sub.-- PLN.sub.-- EN
    plane enable for highlight visuals
    GE.sub.-- MISC.sub.-- PLN.sub.-- EN plane enables for the Z buffer (if
    enabled)
    plus WID, mask, and VLT context depending on the visual
    selected.
    ______________________________________

    __________________________________________________________________________
    VEC.sub.-- AA.sub.-- H
                   must be disabled, or results are undefined
    VEC.sub.-- SEGMENT.sub.-- H
                   ignored
    VEC.sub.-- DRAW.sub.-- FIRST.sub.-- H
                   ignored
    VEC.sub.-- DROP.sub.-- LAST.sub.-- H
                   ignored
    FIX.sub.-- VER.sub.-- H
                   ignored
    SHADE.sub.-- FLAT.sub.-- H
                   ignored
    VEC.sub.-- CONTIN.sub.-- SYMB.sub.-- H
                   ignored if LOAD.sub.-- CUR.sub.-- SYMB.sub.-- H set in
                   request,
    COORD.sub.-- OFFSET.sub.-- H
                   ignored - offset is not supported
    OFFSET.sub.-- 4R.sub.-- H
                   ignored
    all other bits are supported normally
    GE.sub.-- AA.sub.-- CTRL:
                   antialiasing is not supported
    GE-TEX registers:
                   texturing is not supported
     ##STR4##
     ##STR5##
    __________________________________________________________________________

    ______________________________________
    MAJOR         major axis position of first pixel to be
                  drawn, window relative
    MINOR         major axis position of first pixel to be
                  drawn, window relative
    COUNT         Bresenham iteration count (maximum = 4k
    1)
    BRES.sub.-- ERR.sub.-- INIT
                  initial: Bresenham error-this should be
                  loaded with the error term corresponding
                  to the position of the first pixel-ie
                  at the MAJOR, MINOR position specified in
                  the request.
    BRES.sub.-- DELTA.sub.-- MAJOR
                  Bresenham error increment for a move in
                  the major axis
    BRES.sub.-- DELTA.sub.-- BOTH
                  Bresenham error increment for a move in
                  the both axes
    ______________________________________

    ______________________________________
    bits 4:0
           CUR.sub.-- SYMB 5 bit value to
                           select the first bit
                           in the symbology
                           mask to be used. 0 =
                           use bit 0, 1 = use
                           bit 1, etc. Setting
                           this bit to a value
                           greater than
                           SYMB.sub.-- COUNT in
                           GE.sub.-- SYMB.sub.-- CTRL will
                           give undefined
                           results.
    bits 7:
           reserved, MBZ
    bits 15:8
           CUR.sub.-- SYMB.sub.-- REPEAT
                           current value of the
                           repeat counter. This
                           counter counts up to the
                           value in SYMB.sub.-- REPEAT in
                           GE.sub.-- SYMB.sub.-- CTRL. Setting
                           this to a value greater
                           than or equal to
                           SYMB.sub.-- REPEAT in
                           GE.sub.-- SYMB.sub.-- CTRL will give
                           undefined results
    bit 16 LOAD.sub.-- CUR.sub.-- SYMB.sub.-- H
                           set to load the iterator
                           current symbology bit
                           select and repeat count
                           with the data in the
                           above fields. If clear
                           then the symbology will
                           either continue from the
                           current value, or be
                           reset depending on
                           VEC.sub.-- CONTIN.sub.-- SYMB.sub.-- H in
                           GE.sub.-- GCR.
    bit 17 DRAW.sub.-- FIRST.sub.-- H
                           if set, draw the first
                           pixel, if clear the first
                           pixel will not be drawn
                           (and symbology won't be
                           advanced)
    bit 18 MINOR.sub.-- NEG.sub.-- H
                           set if the delta in the
                           minor axis is negative
    bit 19 MAJOR.sub.-- NEG.sub.-- H
                           set if the delta in the
                           major axis is negative
    bit 20 MAJOR.sub.-- Y.sub.-- H
                           set if Y is the major
                           axis, clear if X is the
                           major axis
    bit 31:21
           reserved, MBZ
    ______________________________________

    ______________________________________
    fifo              request
    ______________________________________
    context switch to user 1
    P   E3SaveContext     save previous users GE context
    P   E3ReadRegister    save registers
    P   E3ReadProtRegister
                          save protected registers
    S   E3SetUserID 1
    P   E3LoadProtRegister
                          load user 1 protected
                          registers
    U   E3LoadRegister    load user 1 registers
    U   save frame        load user 1 GE save frame
    U   .
    U   .
    U   .                 .rarw. (see ERROR HANDLING
                          below)
    U   E3Tri #1
    U   E3Tri #2 (partial)
    context switch to user 2
    P   E3SaveContext     save user 1 context
    P   E3ReadRegister    save registers
    P   E3ReadProtRegister
                          save protected registers
    S   E3SetUserID 2
    P   E3LoadProtRegister
                          load user 2 protected
    U   E3LoadRegister    load user 2 registers
    U   save frame        load user 2 GE save frame
    U   user 2 requests
    U   .
    U   .
    context switch back to user 1
    P   E3SaveContext     save user 2 context
    P   E3ReadRegister    save registers
    P   E3ReadProtRegister
                          save protected registers
    S   E3SetUserID 1
    P   E3LoadProtRegister
                          load user 1 protected
                          registers
    P   UE3LoadRegister   load user 1 registers
    U   save frame
    U   E3Tri #2 (the rest)
    U   E3Tri #3
    ______________________________________

    ______________________________________
    RS.sub.-- QUAL
               Error
    ______________________________________
    1          ILLREQ     request could not be decoded
                          to a valid graphics engine
                          request.
    2          PRIV       attempt to execute a protected
                          request in the unprotected
                          fifo
    3          BADVIS     visual is illegal for graphic
                          request:
    any request to visuals 7 and
                          15
    any request to visual 6,
                          unless accessing texture
                          processor memory
    any request other than
                          E3BitBlit to visual 14
    any E3BitBlit involving the
                          texture processor, if visual
                          14 selected
    ______________________________________

• Inventors
  Young, David W.;
• Assignee
  Intergraph Corporation (Huntsville, AL)
• Published
  Aug-11-1998
• Current US Classes:
  345/522
  700/3
  712/31
  718/108
• Application #
  922419
• International Classes
  G06F 013/00
• Field of Search
  395/678 395/200.05
• Examiner
  Toplu; Lucien U.
• Agent
  Bromberg & Sunstein LLP
• US Patent References:
  5185878
  5291608
  5295246
  5303321
  5371849
  5402147
  5428779
  5434957
  5485626
  5524265
  5555244