Method and apparatus for performing a perspective projection in a graphics device of a computer graphics display system

[0001] This application is a continuation of U.S. utility application entitled, “A METHOD AND APPARATUS FOR PERFORMING PERSPECIVE PROJECTION IN A COMPUTER GRAPHICS DISPLAY SYSTEM” having Ser. No. 09/190,754, filed Nov. 12, 1998 now U.S. Pat. No. 6,509,905 which is entirely incorporated herein by reference.

[0002] The present invention relates to a method and apparatus for processing primitives in a computer graphics display system. More particularly, the present invention relates to a computer graphics display system operating in accordance with the window coordinate architectural model in which perspective projection is performed in the graphics hardware of the computer graphics display system rather than in the host central processing unit (CPU).

[0003] Generally, two architectural models are currently used in the three-dimensional (3-D) computer graphics industry to send graphics primitives to the graphics hardware. One of the architectural models, commonly referred to as the object coordinate, or modeling coordinate, architectural model (hereinafter “the object coordinate model”) is implemented in computer graphics display systems that are geometry accelerated. In this architectural model, the vertex object coordinates of an application, as well as any optional data, such as normals and colors, are sent directly to the graphics device (e.g., a graphics card) from the host CPU and are completely transformed by the geometry accelerator of the graphics device from object coordinates into device/window coordinates and, optionally, into eye/world coordinates. The geometry accelerator is also responsible for performing perspective projection during the transformation process, as well as for performing additional operations, such as lighting and fog calculations, for example.

[0004] The second architectural model is commonly referred to as the window coordinate architectural model (hereinafter “the window coordinate model”). In typical implementations of this architectural model, the vertex object coordinates associated with an application being executed by the host CPU are transformed by a software geometry processing pipeline being executed in the host CPU into window coordinates. The vertex object coordinates are first transformed into eye coordinates, which are then transformed into clip coordinates. Assuming that perspective projection is needed (i.e., assuming that the image being rendered is 3-D) the clip coordinates are then perspective projected into normalized device coordinates. The normalized device coordinates are then transformed into window coordinates. All of these transformations occur within the host CPU.

[0005] Once the host CPU has transformed the vertex object coordinates into window coordinates, and has completed any additional processing tasks, such as the tasks of performing lighting and clipping, the window coordinates and any optional vertex data are sent to the graphics hardware. The graphics hardware then performs vector and triangle setup and scan conversion. A known variation of this approach is to also perform vector and/or triangle setup in the host CPU so that the graphics hardware is only required to perform scan conversion.

[0006] In the window coordinate model, it is common, in the non-perspective case, for the clip coordinates to correspond directly to the window coordinates. In this case, the system CPU does not have to perform the tasks of perspective projecting the clip coordinates into normalized device coordinates and then of transforming the normalized device coordinates into window coordinates. However, in the perspective case, the clip coordinates must be perspective projected into normalized device coordinates and then the normalized device coordinates must be transformed into window coordinates, which are additional processing steps that typically involve a divide operation and several multiply operations. These are costly processing steps, particularly the perspective division operation, which must be performed by the host CPU prior to sending the window coordinates to the graphics hardware.

[0007] In another known implementation of the window coordinate model, the vertex object coordinates are transformed directly into window clip coordinates which are then perspective projected into window coordinates. Although this approach improves the computational efficiency of the transformation pipeline being executed by the host CPU, these transformations still require a significant amount of processing to be performed in the host CPU.

[0008] Some computer graphics display systems which implement the window coordinate model comprise graphics hardware which implements a floating-point cell which comprises a general-purpose divider circuit. This divider circuit is used in some of these systems to perform the tasks of vector and triangle setup. It would be advantageous to use this floating-point cell to perform perspective projection in addition to performing vector and triangle setup. However, current implementations of 3-D graphics application program interfaces (APIs), such as, for example, OpenGL™ designed by Silicon Graphics, Inc. and Direct3D™ designed by Microsoft Corporation, used in window coordinate models for performing transformation in the host CPU present window coordinates to the graphics hardware.

[0009] Therefore, the current implementations of these types of graphics APIs, among which OpenGL™ and Direct3D™ are currently the most widely used, do not enable the task of perspective projection to be performed within the graphics hardware, but rather, cause these transformation processes to be performed in the host CPU. Consequently, graphics devices currently available on the market are not adapted to perform the task of perspective projection since this task has historically been performed in the host CPU.

[0010] A need exists for a computer graphics display system which operates in accordance with the window coordinate architectural model and which allows the task of perspective projection to be performed in the graphics hardware. It would be particularly advantageous to enable the task of perspective projection to be performed in the above-mentioned floating-point cell currently implemented in the graphics hardware of computer graphics display systems currently available on the market. By off-loading the task of perspective projection from the host CPU to the graphics hardware, increased throughput can be realized and processing overhead can be reduced.

[0011] The present invention provides a method and apparatus for processing primitives in a computer graphics display system. The apparatus comprises a graphics device which receives commands and data from a host computer. The data includes clip coordinates which are perspective projected by the graphics device into window coordinates. A host computer of the computer graphics display system is programmed to execute a geometry processing pipeline which transforms object coordinates associated with a primitive into clip coordinates which are then delivered to the graphics device. The graphics device then performs perspective projection on the clip coordinates to transform the clip coordinates into window coordinates.

[0012] In accordance with the preferred embodiment of the present invention, the geometry processing pipeline being executed by the host computer transforms the object coordinates into window clip coordinates and then delivers the window clip coordinates to the graphics device. The graphics device then performs perspective projection on the window clip coordinates to transform them into window coordinates. In accordance with an alternative embodiment of the present invention, the geometry processing pipeline being executed in the host computer transforms the object coordinates into eye coordinates and then transforms the eye coordinates into clip coordinates. The clip coordinates are then delivered to the graphics device, which transforms the clip coordinates into window coordinates.

[0013] In accordance with the preferred embodiment of the present invention, the graphics device comprises an interface unit and a setup unit. The setup unit is in communication with the interface unit. The setup unit receives commands and data sent by the host computer to the interface unit and the interface unit delivers the clip coordinates to the setup unit. The setup unit comprises a floating point unit which performs perspective projection on the clip coordinates or window clip coordinates to transform them into window coordinates.

[0014] The setup unit preferably comprises a control register which contains a plurality of bits which are used by the floating point unit to control its operations. One of the bits is a perspective enable bit which is utilized by the floating point unit to inform the floating point unit as to whether or not perspective projection is to be performed by the floating point unit. In accordance with the preferred embodiment, if the perspective enable bit is asserted, the floating point unit performs perspective projection, and if the perspective enable bit is not asserted, the floating point unit does not perform perspective projection on the clip coordinates.

[0015] In some cases, perspective projection may be performed in the host computer. In this case, the host computer will deliver window coordinates to the graphics device and it will be unnecessary for the graphics device to perform perspective projection. Therefore, in this case, the perspective enable bit will not be asserted. In some cases, even though, in accordance with the present invention, the graphics device is configured to perform perspective projection, it may be unnecessary to perform perspective projection at all. In this case, the perspective enable bit will not be asserted. Regardless of whether or not perspective projection is performed, the setup unit will also perform vector and triangle setup, which are operations normally performed by setup units in graphics devices of computer graphics display systems.

[0016] Other features and advantages of the present invention will become apparent from the following description, drawings and claims.

[0023] FIG. 1 is a block diagram of a typical computer graphics display system 10 that operates in accordance with the window coordinate architectural model. The computer graphics display system 10 comprises a host CPU 12, a host memory device 14, a local bus 18, an input/output (I/O) controller device 25, an I/O bus 16, a graphics device 20, and a monitor 21 for displaying graphics information output from the graphics device 20.

[0024] The host CPU 12 executes application programs and outputs commands and data over the local bus 18 to the I/O interface controller 25. The I/O interface controller 25 formats the commands and data utilizing the protocols of the I/O bus 16 and this information is then input to the graphics device 20. The graphics device 20 then processes this information and causes graphics images to be displayed on the monitor 21.

[0025] As stated above, in the window coordinate model, the host CPU 12 normally performs the entire process of transforming vertex object coordinates into clip coordinates and, when perspective projection is required, of transforming the clip coordinates into normalized device coordinates and of transforming the normalized device coordinates into window coordinates. Once the host CPU 12 has performed these transformations, and has completed any additional processing tasks, such as the tasks of performing lighting and clipping, the window coordinates and any optional vertex data are sent to the graphics device 20 via the I/O controller 25. The graphics device 20 then performs the process of rasterization. In accordance with the present invention, the task of perspective projection is not performed by the host CPU 12, but rather, is performed by the graphics device 20, as discussed below in detail.

[0026] FIG. 2 is a block diagram of the graphics device 20 of the present invention in accordance with the preferred embodiment. The host interface unit (HIU) 32, the macro-function unit (MFU) 34, the scan converter 38, the frame buffer controller (FBC) 40 and the display controller 43 are typical components in graphics display systems. Therefore, only a cursory explanation of the functions of these components will be provided herein since persons skilled in the art will understand the operations that are performed by these components. In accordance with the present invention, the setup unit 36 of the graphics device 20 performs perspective projection. The setup unit 36 is discussed below in detail.

[0027] The host interface unit 32 fetches command data packets and texture maps from the host memory 14 via the I/O bus 16. The host interface unit 32 then provides graphics 2D information to the macro-function unit 34 and provides primitives to be perspective projected and/or to be transformed by parallel transformation to the setup unit 36. The macro-function unit 34 generates 2D vectors, text and rectangle spans. The output from the macro-function unit 34 is received by the scan converter 38. The scan converter 38 then converts this information into pixel-level information which is output to the frame buffer controller 40. The frame buffer controller 40 stores the pixel-level information in the frame buffer memory 45 via the memory controller 41. The frame buffer controller 40 causes the pixel-level image information to be read out of the frame buffer memory 45 by the memory controller 41 and output to the display controller 43. The display controller 43 then converts this information into red, green and blue (RGB) format and displays the corresponding image on the display 21.

[0028] As stated above, in accordance with the present invention, the host CPU 12 executes a software graphics transformation pipeline to transform the vertex object coordinates of an application being executed by the host CPU 12 into clip coordinates and performs any additional processing, such as, for example, lighting and clipping. The clip coordinates and any optional vertex data are then sent to the graphics device 20. A description of a typical software graphics transformation pipeline executed in a CPU will now be provided since the host CPU 12 of the present invention executes such a software transformation pipeline up to the point at which the task of perspective projection is to be performed. The task of perspective projection is then performed by the graphics device 20. In accordance with the present invention, any type of graphics API such as, for example, OpenGL™ or Direct3D™, may be used in accordance with the present invention to perform the transformations which precede perspective projection in the host CPU 12. Those skilled in the art will understand that the present invention is not limited with respect to the graphics API that is be used to create the software geometry processing pipeline which performs the transformations in the host CPU 12.

[0029] Software geometry processing pipelines designed using a graphics API, such as, for example, OpenGL™, are divided into a sequence of stages. Each stage utilizes a matrix which is multiplied by data to transform the data. These matrices are the Model-View Matrix, the Projection Matrix and the Viewport Transformation Matrix. The operations of each of these stages will now be discussed with respect to the flow chart of FIG. 3. In the first stage, the vertex object coordinates, which are termed object coordinates in the OpenGL™ Graphics System, are supplied by the application using the OpenGL™ graphics API, as indicated by block 51. The Model-View Matrix is then applied to these coordinates to yield eye coordinates, as indicated by block 52. The Projection Matrix is then applied to the eye coordinates to yield clip coordinates, as indicated by block 54. A perspective division is then carried out on the clip coordinates to yield normalized device coordinates, as indicated by block 56. A final viewport transformation is applied to the normalized device coordinates utilizing the Viewport Transformation Matrix to convert these coordinates into window coordinates, as indicated by block 58.

[0030] The equations used to perform the steps discussed above with respect to FIG. 3 will now be discussed in order to demonstrate the manner in which the various coordinate sets are transformed. Object coordinate sets, eye coordinate sets, and clip coordinate sets are four dimensional coordinate sets. Each set consists of x, y, z and w coordinates which define a vertex of a primitive being processed. The w coordinate contains the perspective information. Thus, the Model-View and Projection matrices are 4×4 matrices. Given a vertex defined in object coordinates as (x0, y0, z0, w0) and a Model-View matrix defined as M, the eye coordinates of the vertex are obtained from the following equation:
(xe, ye, ze, we)=M(x0, y0, z0, w0)  Equation (1)
where (xe, ye, ze, we) are the eye coordinates. Similarly, given a Projection Matrix defined as P, the clip coordinates of the vertex are obtained from the following equation:
(xc, yc, zc, wc)=P(xe, ye, ze, we)  Equation (2)
where (xc, ye, zc, we) are the clip coordinates. The normalized device coordinates of the vertex are then obtained from the following equation by perspective division:
(xd, yd, zd)=(xc/wc, yc/wc, zc/wc)  Equation (3)

[0031] Finally, the normalized device coordinates are mapped into window coordinates using the Viewport Transformation Matrix. The dimensions of the Viewport Transformation Matrix depend on the pixel height and width, py and px, respectively, of the viewport and on the coordinates defining its center (ox, oy). The window coordinates of the vertex, (xw, yw, zw), are then determined from the following equation:
(xw, yw, zw)=((px/2)xd+ox, (py/2)yd+oy, ((f−n)/2)zd+(n+f)/2)  Equation (4)
The variables n and f correspond to the near and far z ranges of the primitive, respectively.

[0032] Often, for computational efficiency, the Model-View Matrix, the Projection Matrix, and the Viewport Transformation Matrix are concatenated together into a single matrix, C, as demonstrated by the flow chart of FIG. 4. In this case, the object coordinates are transformed into window clip coordinates, as indicated by block 61.

[0033] This transformation is accomplished using a single matrix transformation in accordance with the following equation:
(xc, yc, zc, wc)=C(x0, y0, z0, w0)  Equation (5)
The window clip coordinates are then perspective projected into window coordinates by performing perspective division, as indicated by block 62. This transformation is accomplished using the following equation:
(xw, yw, zw)=(xc/wc, yc/wc, zc/wc)  Equation (6)

[0034] In computer graphics display systems which utilize the window coordinate model, the task of perspective projection, i.e., of transforming the clip coordinates or window clip coordinates into window coordinates, is typically performed in the host CPU 12 before the window coordinates are sent to the graphics device for subsequent rasterization. In accordance with a first embodiment of the present invention, the clip coordinates obtained from the process corresponding to equations (1), (2) and (4), i.e., to steps 52 and 54 in FIG. 3, are sent directly to the graphics device 20. The graphics device 20 then performs the task of perspective projection, which corresponds to equations (3) and (4), i.e., to steps 56 and 58 in FIG. 3, to transform the clip coordinates into window coordinates in the setup unit 36.

[0035] In accordance with the preferred embodiment of the present invention, the window clip coordinates obtained from the process corresponding to equation (5), i.e., to step 61 in FIG. 4, are sent directly to the graphics device 20. The setup unit 36 of the graphics device then performs the task of perspective projection, which corresponds to equation (6), i.e., to block 62 in FIG. 4.

[0036] Therefore, by utilizing the setup unit 36 in accordance with the present invention to perform the task of perspective projection, a considerable amount of computation is off-loaded from the host CPU 12 to the graphics device 20. Preferably, the setup unit 36 comprises a floating-point unit of the type typically utilized in geometry-accelerated graphics devices for performing vector and triangle setup. Graphics devices currently available on the market which contain such a floating point unit include, for example, HP Visualize fx 2™, HP Visualize fx 4™ and HP Visualize fx 6™. This floating point unit comprises a general purpose divider that is normally used to perform vector and triangle setup. However, it will be understood by those skilled in the art that the present invention does not require the use of one of these floating point units and that any floating point unit which comprises a divider circuit capable of transforming clip or window clip coordinates into window coordinates is suitable for this purpose. Also, persons skilled in the art will understand that it is not necessary to use a floating point unit for this purpose. Any divider circuit capable of performing these operations is suitable for use with the present invention.

[0037] Preferably, the task of perspective projection is performed in the setup unit 36 prior to the task of vector and triangle setup being performed. Once the clip coordinates have been transformed into window coordinates and vector and triangle setup has been performed, scan conversion and rasterization is performed by the scan converter 38 and by the frame buffer controller 40. Since the scan conversion and rasterization processes are typical processes performed in graphics devices, these processes will not be further discussed herein since those skilled in the art will understand the manner in which these processes are performed.

[0038] As shown in FIG. 5, the setup unit 36 preferably comprises a control register 70 which is utilized by the floating point unit 72 to determine whether perspective projection is to be performed by the floating point unit 72. The floating point unit 72 preferably is a microcode engine which utilizes and which is controlled by the values of bits stored in the control register 70. Other devices, such as, for example, a state machine, an application specific integrated circuit (ASICs), etc., or any other type of computational device capable of performing the functions of the microcode engine, can be used instead of the microcode engine for performing the functions performed by the microcode engine, as will be understood by those skilled in the art.

[0039] In accordance with the preferred embodiment of the present invention, a single bit contained in the control register 70, hereinafter referred to as the perspective enable bit, indicates whether the floating point unit 72 is to perform perspective projection on the received primitive. The host CPU 12 causes the control register 70 to be updated by the host interface unit 32. Thus, the perspective enable bit is asserted or de-asserted by the host CPU 12. Preferably, when the perspective enable bit is asserted, the floating point unit 72 performs perspective projection on the received primitive. When the perspective enable bit is not asserted, the floating point unit 72 does not perform perspective projection, but rather, performs vector and triangle setup and outputs the results to the scan converter 38. Thus, the floating point unit 72 is programmable to allow perspective projection to be performed in the host CPU 12 or in the setup unit 36.

[0040] There are several advantages to allowing the computer graphics display system 10 to perform perspective projection in the host CPU 12 or in the graphics device 20. If the graphics API being executed on host CPU 12 has been implemented to provide window coordinates to the graphics device 20, then the floating point unit 72 should not perform perspective projection because it has already been performed by the host CPU 12. In this case, the perspective enable bit will not be asserted. In some cases, the user supplies the vertex object coordinates and the w coordinate may be 1, which means that perspective projection is not to be performed (i.e., perspective division by 1 is the same as no division). In this case, the host CPU 12 will cause the perspective enable bit to be de-asserted. In some cases, it may be possible that performing perspective projection in the CPU 12 is faster than performing perspective projection in the graphics device. In this case, the perspective enable bit will be set to 0 by the host CPU 12 so that the floating point unit does not perform perspective projection.

[0041] FIG. 6 is a flow chart functionally illustrating the process occurring in the setup unit 36 when it is processing a primitive received in the setup unit 36. When a primitive is received, the floating point unit 72 determines whether the perspective enable bit is equal to 1, as indicated by block 81. If so, perspective projection is to be performed. Therefore, the process proceeds to the step represented by block 82 at which perspective division is performed. Once perspective division has been performed at block 82, the process proceeds to block 83 where vector and triangle setup operations are performed.

[0042] If the floating point unit 72 determines that the perspective enable bit is 0, thus indicating that perspective projection is not to be performed, the process bypasses the step represented by block 82 and proceeds to the step represented by block 83 where vector and triangle setup operations are performed.

[0043] The host CPU 12 determines whether perspective projection is to be performed by the setup unit 36 or by the host CPU 12 and asserts or de-asserts the perspective enable bit accordingly. The host CPU 12 can determine whether perspective projection is to be performed by either analyzing the w coordinate of the vertex object coordinate set associated with a primitive, or by looking at the values of the Model View and Projection matrices associated with a primitive. Both of these techniques are commonly used in window coordinate architectural models in order for the host CPU to determine whether or not it is to perform perspective projection. Therefore, in the interest of brevity, a detailed discussion of the manner in which host CPU 12 performs this task will not be provided herein.

[0044] It should be noted that a plurality of bits instead of a single bit may be used, if so desired, to indicate whether or not perspective projection is to be performed in the setup unit 36, although preferably only a single bit is used for this purpose, as discussed above in detail. Also, although the perspective enable bit has been referred to as having a value of 1 when it is asserted, a value of 0 could be used instead to indicate that the perspective enable bit is asserted, as will be understood by those skilled in the art.

[0045] It will be understood by those skilled in the art that the present invention has been described with respect to the preferred embodiments of the present invention, but that the present invention is not limited to these embodiments. Those skilled in the art will understand that modifications can be made to the embodiments discussed above which are within the spirit and scope of the present invention.