Validating a graphics pipeline using pre-determined schedules

Abstract

Determining a schedule of instructions for an integrated circuit graphics pipeline. The method includes accessing a state of a host system. The state comprises operations to be performed on fragments to be processed by the graphics pipeline. The method further includes determining a vector based on the state and indexing a table based on the vector to obtain a predetermined listing and ordering of macro-operations to be executed. The method still further includes determining instructions for programming the graphics pipeline based the executing of the macro-operations in the scheduled order.

Description

FIELD OF THE INVENTION

The present invention relates to the field of computer video graphics. Specifically, embodiments of the present invention relate to scheduling graphics operations in a graphics pipeline.

BACKGROUND ART

FIG. 1 illustrates a conventional OpenGL state diagram 100 concerned with processing fragments in graphics processing pipeline. The state diagram 100 comprises a number of rendering operations 110 indicating potential operations to be performed on an incoming fragment 120. Conventionally, a host system may set the state via one or more OpenGL calls. For example, the host system may “turn on” fog by enabling the fog operation. Consequently, the graphics pipeline is directed to apply fog to all fragments processed in the graphics processing pipeline until the fog operation is disabled by the host system. The state diagram 100 in FIG. 1 is exemplary and does not reflect all possible state variables. Furthermore, the OpenGL specification is one example of a graphics specification concerned with rendering.

The incoming fragment 120 has a color associated with it that is modified by a graphics pipeline that processes the fragment to implement whatever rendering operations 110 are “enabled” in the current state. For example, if the “fog” operation is enabled, then the graphics pipeline performs a fog operation on any fragments that are processed while the fog operation is still enabled. A final color value 130 for the fragment is arrived at after applying the rendering operations 110.

While some state variables may be “enabled” or “disabled,” there may also be “mode” and “value” state variables. An example of a mode state variable is blending, which allows a particular type of blending to be selected. An example of a value state variable is color. For example, color may be specified by a command that specifies a value between 0 and 1 for each of red, green, blue.

In order to render the fragments in accordance with the current state specified by the host system, hardware in a graphics processing pipeline can be programmed to reflect the current state. The process of determining suitable instructions for programming hardware in a graphics processing pipeline to reflect the current state is referred to as “validating” or performing validation.

Therefore, it would be advantageous to provide a method and device that validates an integrated circuit graphics pipeline. It would be further advantageous if the method and device efficiently determines a schedule of instructions to program the integrated circuit graphics pipeline, based on a current OpenGL state.

SUMMARY OF THE INVENTION

Embodiments of the present invention provide a method and device that validate an integrated circuit graphics pipeline. Embodiments of the present invention provide a method and device that efficiently determine a schedule of instructions to program the integrated circuit graphics pipeline, based on a graphics state of a host. The present invention provides these advantages and others not specifically mentioned above but described in the sections to follow.

A method of scheduling graphics operations is disclosed. One embodiment is a computer readable medium having stored thereon instructions for implementing a method of determining a schedule of instructions for an integrated circuit graphics pipeline. The method includes accessing a graphics state of a host system. The graphics state comprises operations to be performed on fragments to be processed by the graphics pipeline. The method further includes determining a vector based on the graphics state and indexing a memory-resident table based on the vector to obtain a predetermined listing and ordering of macro-operations. The method still further includes determining instructions for programming the graphics pipeline based on executing modules in accordance with the order specified by the obtained predetermined listing and ordering of macro-operations.

In one embodiment, the instructions that are generated program an arithmetic logic unit of the graphics pipeline. In another embodiment, the instructions are also used to program a data fetch unit of the pipeline. Other pipeline modules could also be programmed according to instructions generated in the embodiments described herein.

Another embodiment in accordance with the present invention is a computer-readable medium having stored thereon a device driver. The device driver includes an indexable data structure comprising entries corresponding to states of a host device. The states specify how fragments are to be processed in a graphics pipeline. The entries comprise a predetermined listing and ordering of operations for implementing a given one of the states. The device driver has a first program code operable to access a vector based on a current state of the host system and to index the data structure based on the vector to determine a schedule of macro-operations for the state. The device driver has a second program code operable to access the schedule of macro-operations for the state and to determine hardware instructions by executing portions of the second program code based on the accessed schedule of macro-operations.

The vector may be determined according to the enable states of a plurality of graphics functions that are contained within the host's graphic state. Once a particular vector is determined, the corresponding entry in the table identifies a pre-determined schedule of macro-operations that has been determined to provide an efficient and effective manner in which to program the pipeline to implement the host state.

By pre-determining a schedule of instruction generation for each possible permutation of graphics enabled functions, the scheduler of the present invention is significantly relieved in complexity and length, thereby providing a better schedule for portable and low power applications.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.

FIG. 1 is a state diagram in accordance with the prior art.

FIG. 2A is a block diagram of one example of a system upon which embodiments in accordance with the present invention may be implemented.

FIG. 2B is a block diagram of another example of a system upon which embodiments in accordance with the present invention may be implemented.

FIG. 3 is a block diagram of an exemplary pipeline architecture, for which embodiments of the present invention are suitable to determine a schedule of hardware instructions.

FIG. 4 is a diagram illustrating exemplary components in a device driver used in the generation of instructions for programming a graphics pipeline in accordance with one embodiment of the present invention

FIG. 5 is a flowchart illustrating an exemplary process of scheduling instructions in a graphics pipeline, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of the present invention, validating an integrated circuit graphics pipeline, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be recognized by one skilled in the art that the present invention may be practiced without these specific details or with equivalents thereof. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.

NOTATION AND NOMENCLATURE

Some portions of the detailed descriptions that follow are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits that can be performed on computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, computer executed step, logic block, process, etc., is here, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “requesting” or “allocating” or “computing” or “transferring” or “calculating” or “determining” or “receiving” or “executing” or “accessing” or “generating” or “storing” or “indexing” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Embodiments of the present invention perform a validation process by generating instructions for use in programming hardware in a graphics processing pipeline such that the graphics processing pipeline implements a current graphics state specified by a host system. Embodiments of the present invention are well-suited to perform validation in connection with a graphics specification that is substantially compliant with the OpenGL specification. However, the present invention is not limited to the validation involving OpenGL. Throughout this description, the term “graphics specification” includes any specification that may be used to define a rendering state. In one embodiment, the instruction scheduling techniques and processes described herein may be implemented within a device driver associated with a graphics pipeline.

The rendering state or graphics state, as specified by a host device making calls that are compliant with a graphics specification, may comprise one or more operations to be performed on one or more fragments. For example, the rendering state may indicate that “blend” and “fog” operations are to be performed on each fragment that is processed in the graphics processing pipeline. The rendering state may be changed at the discretion of, for example, an application program such as a video game executing in the host device. When the rendering state is changed, embodiments of the present invention may re-program the graphics pipeline hardware, if necessary, by determining a new schedule of hardware instructions. Moreover, embodiments of the present invention determine the schedule of instructions efficiently and with a relatively small scheduling code and memory resources. Rendering state may involve, but is not limited to, the following graphics functions: multiple textures, antialiasing, fog, alpha test, stencil, z-test, blend, and color mask.

Within the LUT are entries that correspond to every permutation that the rendering state can have. Each state therefore has a custom and pre-determined schedule of macro-operations, which identify an order to execute software modules to generate the graphics pipeline instructions

Embodiments of the present invention utilize a look-up table (LUT) that comprises a distinct schedule for different rendering states, such that hardware may be programmed based on one of the schedules. The schedules in the LUT are not necessarily the hardware instructions themselves, but may serve as an intermediary in the determination of hardware instructions. For each rendering state, a hardware instruction sequence is a function of the hardware parameters, and applying optimizations and exceptions to that sequence. Therefore, the determination of a hardware instruction sequence is a complex process.

In some cases, an operation in a rendering state maps directly to a corresponding hardware instruction. In other cases, a single rendering operation in the rendering state may be implemented by multiple hardware instructions. In still other cases, multiple rendering operations may be optimally performed by a single hardware instruction. The latter case is particularly desirable as minimizing the number of instructions generally results in faster graphics rendering performance.

Because embodiments of the present invention use a LUT to aid scheduling hardware instructions in a graphics pipeline, computation time is saved when rendering is taking place. For example, the scheduling information in the LUT can be determined “offline” by examining factors related to the rendering states such as the presence (or absence) of a blending operation, first texture, second texture, fog, etc. The total number of permutations of these factors may be in the hundreds. However, the LUT of scheduling information is very compact.

Run-time information in addition to the scheduling information in the LUT may be used to determine the actual hardware instructions used to program the graphics pipeline. However, there is no need to determine the order of instructions and perform optimization, as these functions have been performed “offline” with the results included in the LUT.

Exemplary Computer System Platforms

FIG. 2A is a block diagram of a system 200 upon which embodiments in accordance with the present invention may be implemented. For example, embodiments of the present invention may be implemented as a device driver within system 200. System 200 shows the components of an execution platform for implementing certain software-based functionality of embodiments in accordance with the present invention. As depicted in FIG. 2A, the system 200 includes a microprocessor 202 coupled to a graphics processor 205 via a host interface 201. The host interface 201 translates data and commands passing between the microprocessor 202 and the graphics processor 205 into their respective formats. Both the microprocessor 202 and the graphics processor 205 are coupled to a memory 207 via a memory controller 206. In the system 200 embodiment, the memory 207 is a shared memory, whereby the memory 207 stores instructions and data for both the microprocessor 202 and the graphics processor 205. Access to the shared memory 207 is through the memory controller 206. The shared memory 206 also includes a video frame buffer for storing pixel data that drives a coupled display 208.

As described above, certain processes and steps of the present invention are realized, in one embodiment, as a series of instructions (e.g., a software program) that reside within computer-readable memory (e.g., memory 207) of a computer system (e.g., system 200) and are executed by the microprocessor 202 and graphics processor 205 of system 200. When executed, the instructions cause the system 200 to implement the functionality of embodiments of the present invention as described below.

As shown in FIG. 2A, system 200 includes basic components of a computer system platform that implements functionality of embodiments of the present invention. Accordingly, system 200 can be implemented as, for example, a number of different types of portable handheld electronic devices. Such devices can include, for example, portable phones, personal digital assistants (PDAs), handheld gaming devices, or virtually any other type of device with display capability where there is an interest in rendering three-dimensional graphical images at low cost and low power. In such embodiments, components would be included that are designed to add peripheral buses, specialized communications components, support for specialized input/output (I/O) devices, and the like.

Additionally, it should be appreciated that although the components of FIG. 2A are depicted as discrete components, several of the components can be implemented as a single integrated circuit device (e.g., a single integrated circuit die) configured to take advantage of the high levels of integration provided by modern semiconductor fabrication processes. For example, in one embodiment, the microprocessor 202, host interface 201, graphics processor 205, and memory controller 206 are fabricated as a single integrated circuit die.

FIG. 2B shows a system 220 in accordance with an alternative embodiment of the present invention. System 220 is substantially similar to system 200 of FIG. 2A. System 220, however, utilizes a microprocessor 202 having a dedicated system memory 227, and a graphics processor 205 having a dedicated graphics memory 226. In the system 220 embodiment, the system memory 227 stores instructions and data for processes/threads executing on the microprocessor 202, and graphics memory 226 stores instructions and data for those processes/threads executing on the graphics processor 205. The graphics memory 226 stores pixel data in a frame buffer that drives the display 208. As with computer system 220 of FIG. 2A, one or more of the components of system 220 can be integrated as a single integrated circuit die.

Exemplary Programmable Graphics Pipeline

FIG. 3 is a block diagram of an exemplary programmable graphics pipeline 300 for which embodiments of the present invention develop a schedule of hardware instructions to implement a graphics rendering state. It will be understood that embodiments of the present invention are well-suited to determine a schedule of hardware instructions for other graphics pipelines. The pipeline 300 includes a setup stage 305, a raster stage 310, a gatekeeper stage 320, a data fetch stage 330, an Arithmetic Logic Unit (ALU) stage 340, and a data write stage 355.

Setup stage 305 of FIG. 3 receives instructions and graphics primitives from a host, such as a software application running on system 200 or 250 of FIGS. 2A and 2B, respectively. In general, setup stage 305 calculates vertex parameters needed by raster stage 310. In one embodiment, setup stage 305 performs functions associated with the geometrical 3D to 2D transformation of coordinates, clipping, and setup. The setup stage 305 takes vertex information (e.g., x, y, z, color and/or texture attributes, etc.) and applies a user-defined view transform to calculate screen space coordinates for each geometrical primitive (hereinafter described as triangles because primitives are typically implemented as triangles), which are then sent to the raster stage 310 to draw a given triangle. A vertex buffer 308 may be included to provide a buffer for vertex data used by setup stage 305.

In general, raster stage 310 translates triangles to pixels using interpolation. Raster stage 310 receives data from setup stage 305 regarding triangles that are to be rendered (e.g., converted into pixels). Raster stage 310 determines which pixels correspond to which triangle, processes each pixel of a given triangle including computation of parameters associated with each pixel, and determines shader processing operations that need to be performed on a pixel as part of the rendering, such as color, texture, and fog operations.

Raster stage 310 generates a “pixel packet” for each pixel of a triangle that is to be processed. A pixel packet is, in general, a set of descriptions used for calculating an instance of a pixel value for a pixel in a frame of a graphical display. A pixel packet is associated with each pixel in each frame. Each pixel is associated with a particular (x,y) location in screen coordinates.

Each pixel packet includes a payload of pixel attributes required for processing (e.g., color, texture, depth, fog, and [x,y] location, etc.) and sideband information (pixel attribute data is provided by the data fetch stage 330). In one embodiment, the sideband information includes a kill bit. If the kill bit is set somewhere in the pipeline 300, then the pixel packet will proceed through the remainder of the pipeline 300 without active processing. A pixel packet may contain one row of data or may contain multiple rows of data. A row is generally the width of the pipeline bus.

In one embodiment, raster stage 310 of FIG. 3 calculates barycentric coordinates for each pixel packet. The use of barycentric coordinates improves dynamic range, which permits using fixed-point calculations that require less power than floating point calculations.

As each pixel of a triangle is walked through raster stage 310, raster stage 310 generates pixel packets for further processing which are received by gatekeeper stage 320. Gatekeeper stage 320 performs a data flow control function. In one embodiment, gatekeeper stage 320 has an associated scoreboard 325 for scheduling, load balancing, resource allocation, and hazard avoidance of pixel packets, as well as circulation. Scoreboard 325 tracks the entry and retirement of pixels. Pixel packets entering gatekeeper stage 320 set the scoreboard 325, and the scoreboard 325 is reset as the pixel packets drain out of pipeline 300.

Gatekeeper 320 and scoreboard 325 provide several benefits. Scoreboard 325 can track pixel packets that are capable of being processed by ALUs 350, along with those pixel packets that have their kill bit set. For example, if there are no valid pixel packets, the ALU pipe stages may be turned off, for example, not clocked, to save power.

A data fetch stage 330 fetches data for pixel packets passed on by gatekeeper 320. Such data may include color information, any depth information, and any texture information for each pixel packet. In one embodiment, data fetch stage 330 also manages a local z-depth cache 333, local texture/fog cache 332, and a color cache 334. Color cache 334 may be used for alpha blending. Fetched data is placed into an appropriate field in the pixel packet prior to sending the pixel packet on to the next stage.

From the data fetch stage 330, pixel packets enter an ALU stage 340. In one embodiment, the ALU stage 340 includes multiple ALUs 350 configured to execute shader programming related to three-dimensional graphics operations such as, but not limited to, texture combine (texture environment), stencil, fog, alpha blend, alpha test, and depth test.

In the example of FIG. 3, there are four (4) ALUs 350-0, 350-1, 350-2, and 350-3. The ALUs may be series coupled scalar units. While four ALUs 350 are illustrated, in other implementations, ALU stage 340 may incorporate a different number of ALUs 350.

Each ALU 350-0, 350-1, 350-2, and 350-3 executes an instruction, each instruction for performing an arithmetic operation on operands that correspond to the contents of the pixel packets. An ALU can use temporarily stored values from previous operations.

Continuing with reference to FIG. 3, an example of an arithmetic operation performed by ALUs 350-0, 350-1, 350-2, and 350-3 is a scalar arithmetic operation of the form (a*b)+(c*d), where a, b, c, and d are operand values that are obtained from a pixel packet. Each ALU 350-0, 350-1, 350-2, and 350-3 can perform other mathematical operations.

Each ALU 350-0, 350-1, 350-2, and 350-3 of FIG. 3 may determine whether to generate a kill bit based on a test, such as a comparison of a*b and c*d (e.g., kill if a*b not equal to c*d). An individual ALU 350-0, 350-1, 350-2, and 350-3 can be disabled, for example, not clocked, with regard to processing a pixel packet if the kill bit is set in a pixel packet. A clock-gating mechanism may be used to disable ALU 350-0, 350-1, 350-2 or 350-3 when a kill bit is detected in any row of a pixel packet. As a result, after a kill bit is generated for a row of a pixel packet, the ALUs 350-0, 350-1, 350-2, and 350-3 do not waste power on the row of the pixel packet as it propagates through ALU stage 340. However, note that a pixel packet with a kill bit set still propagates onwards, permitting it to be accounted for by data write stage 355 and scoreboard 325. This permits all pixel packets to be accounted for by scoreboard 325, even those pixel packets marked by a kill bit. A kill bit refers to a pixel packet associated with a pixel that is not to be rendered on the screen.

The output of the ALU stage 340 goes to the data write stage 355. The data write stage 355 stores pipeline results in a write buffer 360 or in a frame buffer in memory (e.g., memory 207 of FIG. 2A or memory 226 of FIG. 2B). Data write stage 355 indicates retired writes to gatekeeper stage 320 for scoreboarding. Optionally, pixel packets/data can be re-circulated from the data write stage back to the gatekeeper 320 if further processing of the data is needed.

Exemplary Macro-Operations

Table I includes a list of exemplary macro-operations that relate to programming an ALU and a general description of the manner in which the graphics pipeline hardware should be programmed to effect each macro-operation, in accordance with an embodiment of the present invention. Table I does not describe specific details of programming the hardware. It will be understood that the macro-operations are not the actual hardware instructions. Rather, the macro-instructions define an ordered list of operations from which the actual hardware instructions are generated. Further, a single macro-operation may be implemented with more than one hardware instruction.

In Table I, the first macro-operation is defined as un-used or invalid. The second macro-operation is implemented by programming the hardware to kill a pixel without writing the pixel data to a frame buffer or the like. As discussed above, killing a pixel can be achieved by not clocking the hardware such that the payload associated with the pixel packet is not propagated through the hardware. Thus, killing a pixel saves power. The third macro-operation is used when the hardware is to be programmed to pass a pixel packet without processing. When passing a pixel without processing, the hardware is clocked such that the payload associated with the pixel packet is propagated through the hardware. Several macro-operations are provided to indicate the hardware is to be programmed to apply a texture. In the example of Table I, there are five texture units that may be used. Other exemplary macro-operations in Table I specify that the hardware should be programmed to perform fog, blending, and/or alpha operations.

Some of the macro-operations relate to multiple rendering operations in the state of the graphics specification. For example, one macro-operation combines a “fog” and an “alpha test” operation. Another macro-operation combines a “blend” and a “color mask” operation. The exemplary macro-operations are well-suited for use in the process of validating a graphics pipeline such as the exemplary graphics pipeline depicted in FIG. 3. However, the exemplary macro-operations are not limited to validating the exemplary graphics pipeline of FIG. 3. Further, macro-operations may be used to specify the programming of hardware other than an ALU, such as a data fetch unit in a graphics pipeline. Further, embodiments of the present invention are not limited to the macro-operations described in Table I.

TABLE I
Macro-operation   Description
ALU_OP_UNUSED = 0 ALU instruction is unused/invalid
ALU_OP_KILL       Kill pixel and write no results
ALU_OP_PASSTHRU   Pass-through
ALU_OP_TEX0       Texenv function on texture unit 0
ALU_OP_TEX1       Texenv function on texture unit 1
ALU_OP_TEX2       Texenv function on texture unit 2
ALU_OP_TEX3       Texenv function on texture unit 3
ALU_OP_TEX4       Texenv function on texture unit 4
ALU_OP_FOG        Fog
ALU_OP_FOG_ALPHA  Fog + alpha test
ALU_OP_ALPHA_FUNC Alpha testing
ALU_OP_BLEND_MASK Blend and/or color mask
ALU_OP_LOGICOP    Logic op

Exemplary Macro-Operation Schedules

Table II illustrates exemplary pre-determined macro-operation schedules using the exemplary macro-operations described in Table I, in accordance with an embodiment of the present invention. Each schedule is for a respective rendering state, for example, an active OpenGL rendering state. The first column in Table II represents an encoded version of the schedule. The second column lists “enable” states in OpenGL that affect rendering. The third column lists a schedule of macro-operations corresponding to the OpenGL state in the same row. The fourth column provides comments and explanations. It will be understood that implementations of the LUT store only the encoded schedule, as depicted in the first column. Thus, while referring to the LUT as “storing pre-determined macro-operation schedules,” it will be understood that the LUT may actually store an identifier of a macro-operation. In practice, the LUT may contain many more entries than depicted in Table II.

While the example in Table II contemplates OpenGL, the present invention is not limited to OpenGL. Furthermore, while examples herein refer to “enable” states, the present invention is not limited to “enable” state variables. For example, the states that affect rendering may be any state variable including, for example, “mode” and “value” state variables.

The encoded schedule of macro-operations is stored in a look-up table. As an illustrative example, the second entry in Table II corresponds to an OpenGL state in which the following operations are enabled: “texture_—0,” “blend,” and “fog”. In this case, three macro-operations are scheduled, in the order specified in Table II. The order can be determined in any suitable fashion. The present invention is not limited to the particular order in which macro-operations are specified in Table II. In this example, the schedule “00000002”h is read from right to left and each hexadecimal value represents a macro-operation to be performed and the order specified. For example, the value “2” indicates a “pass-through macro-operation.”The schedule “00000B83” indicates that macro-operations identified by “B”, “3”, and “8” should be implemented. The schedule is input by scheduling code, which generates appropriate hardware instructions, based on the ordered list of macro-operations, in accordance with embodiments of the present invention.

The third entry in Table II is an example in which multiple ALU passes are performed, which reflects the nature of the underlying hardware that is being validated this embodiment. In this example, the graphics hardware being validated re-circulates a pixel packet such that there multiple ALU passes in order to perform more than four operations on a fragment associated with the pixel packet. For example, a pixel packet is re-circulated as indicated in FIG. 3 from the data write stage 355 to the gatekeeper stage 320. In this case, the five rendering operations in the OpenGL state leads to five ALU instructions, which are performed in two passes. However, there are six macro-operations as a “pass-through” macro-operation is added at the start of the second pass through the ALU. The present invention is well-suited for hardware with other characteristics.

The fourth entry provides an example in which two of the OpenGL rendering operations correspond to a single macro-operation. For example, a single macro-operation “fog_alpha” can be used for the “fog” and “alpha_test” enable in the OpenGL state. Thus, a total of four OpenGL enables correspond to a total of three macro-operations, in this case. Moreover, the ALU can be programmed with a single instruction to perform both the fog and alpha operations. Thus, the pre-determined macro-operation schedule is optimized to take advantage of the capability of the ALU.

The fifth entry in Table II provides an example in which a single OpenGL enable expands to multiple macro-operations. For example, a macro-operation of “passthru” is added before an alpha test followed by a blend. This allows the hardware to be programmed such that ALU registers are properly loaded for the blending operation.

The final entry in Table II illustrates a case in which nine OpenGL enables are implemented with seven macro-operations, plus a pass-through macro-operation. As discussed previously, breaking the macro-operations into two passes reflects the nature of underlying hardware; embodiments of the present invention are well-suited to validate other hardware.

TABLE II
		Macro-op
	Active OpenGL state	schedule
Schedule	affecting pixel	(“ALU_OP_”
(encoded)	rendering	prefix omitted)	Comments/explanation
00000002h	(default)	PASSTHRU	Baseline case: vertex color
			only
00000B83h	GL_TEXTURE_0,	TEX0, FOG,	Multiple enables/operations: 1
	GL_BLEND,	BLEND_MASK	texture + fog + blending
	GL_FOG
00B82543h	GL_TEXTURE0,	TEX0, TEX1,	Multiple ALU passes
	GL_TEXTURE1,	TEX2,	(“recirculation”) when
	GL_TEXTURE2,	PASSTHRU,	programming more than 4
	GL_BLEND,	FOG,	operations: 5 “enables” → 5
	GL_FOG	BLEND_MASK	ALU instructions → 2
			“passes” 6 macro-ops; 1st
			operation of 2nd “pass” is a
			pass-through
00000B93h	GL_TEXTURE0,	TEX0,	Combining multiple OpenGL
	GL_BLEND,	FOG_ALPHA,	enables into a single macro-
	GL_FOG,	BLEND_MASK	op (and ALU instruction): fog +
	GL_ALPHA_TEST		alpha test → FOG_ALPHA
00000BA2h	GL_BLEND,	PASSTHRU,	Single OpenGL enable
	GL_ALPHA_TEST	ALPHA,	expands to multiple
		BLEND_MASK	instructions/macro-ops: alpha
			test followed by blend is
			preceded by a pass-through
			to load up ALU registers for
			blending.
B9726543h	GL_TEXTURE_0,	TEX0, TEX1,	9 OpenGL enables
	GL_TEXTURE_1,	TEX2, TEX3,	implemented using 7 macro-
	GL_TEXTURE_2,	PASSTHRU,	ops (not counting
	GL_TEXTURE_3,	TEX4,	PASSTHRU) in a 2-pass 4 + 4
	GL_LINE_SMOOTH,	FOG_ALPHA,	schedule; fog + alpha test
	GL_BLEND,	BLEND_MASK	implemented using
	GL_FOG,		FOG_ALPHA macro-op,
	GL_ALPHA_TEST,		blending + color mask
	glColorMask		implemented using
			BLEND_MASK macro-op

FIG. 4 is a diagram illustrating software elements in a device driver 400 used in the generation of a schedule of instructions for programming a graphics pipeline, in accordance with an embodiment of the present invention. The various elements of the device driver 400 may be stored in computer-readable medium. The device driver 400 may be implemented within a system such as system 200 or 250 depicted in FIGS. 2A and 2B, respectively. However, the device driver is not so limited. The look-up table (LUT) 410 comprises a plurality of entries, each of which describes a schedule of macro-operations and refers to a respective rendering state. The schedule may be encoded as depicted in the “encoded schedule” column of Table II. Each entry in the LUT 410 defines a sequence of macro-operations for a given state of a host system. The LUT 410 has sufficient entries to cover all states of interest. For example, the LUT 410 has sufficient entries to cover all states that affect the programming of the graphics pipeline hardware.

The context data structure 415 may be built by the device driver 400 based on information from a host device. For example, the device driver 400 builds and updates the context data structure 415 in response to OpenGL calls or the like. The context data structure 415 may include information that was not obtained from the host device, if desired. The context data structure 415 includes various enable bits 412, which define whether the corresponding rendering operation is enabled. The vector that is used to index the LUT 410 is formed from at least some of the enable bits, in accordance with this embodiment. it is not required that all enable bits be used to form the vector. The context data structure 415 also includes other state data 414, which is not used to form the vector, in this embodiment. However, it will be understood that the vector may be formed in any suitable fashion from whatever information in the context data structure 415 or elsewhere that is deemed relevant to validate the graphics pipeline using well-known techniques.

The vector that is generated based on state information is used to index the LUT 410, thus determining a sequence of macro-operations for that state. The macro-operations for the entry pointed to by the vector are transferred to and stored in the configuration map data structure 420 by writing the encoded schedule into the configuration map data structure 420. The configuration map data structure 420 is updated whenever the state in the context data structure 415 changes in a way that affects the scheduling of macro-operations.

The scheduling code 430 is used to determine instructions for the hardware. The scheduling code 430 accesses the configuration map data structure 420 to input the encoded schedule. Thus, the scheduling code 430 effectively inputs a list of macro-operations and the order in which they should be performed to implement the current state. The list of macro-operations by itself does not necessarily contain all of the information to program the graphics pipeline. For example, a macro-operation may define that a blend operation should be performed. However, additional “context” information may be accessed to determine whether a “multiply” or an “add” should be executed when performing the blend operation. The scheduling code 430 may thus input context information. The context information may be derived from, for example, the other state data 414 in the context data structure 415. As another example, the context data may identify a particular texture map for a texture macro-operation.

Based on the schedule of macro-operations and possibly context information, the scheduling code 430 executes portions of the scheduling code and outputs one or more hardware instructions, which are stored in the hardware instruction cache 440. The hardware instructions may then be used to program a graphics pipeline to implement the graphics state. For example, an ALU (FIG. 3, 340) and data fetch unit (FIG. 3, 330) may be programmed via the hardware instructions.

The scheduling code 430 may have various modules 435 that are executed to determine the hardware instructions, based on the encoded schedule of macro-operations. For example, there may be a texture module, an alpha test module, a fog module an anti-alias module, a depth test module, a color mask module, etc. The scheduling code 430 may execute the fog module if the accessed schedule of macro-operations includes a fog macro-operation, for example. In some embodiments, the listing and ordering of macro-operations in the LUT corresponds to these modules. As such, the modules are executed according to the ordering in the LUT, wherein the executing generates instructions for programming the graphics pipeline to implement said state. As used herein, the phrase “executing the macro-operations in the scheduled order” means executing scheduling software based on one of the encoded schedules of macro-operations from the LUT.

FIG. 5 is a flowchart illustrating an exemplary process 500 of scheduling instructions in a graphics pipeline, in accordance with an embodiment of the present invention. Steps of process 500 may be stored as instructions on a computer readable medium, which may be executed on a computer processor as a part of a device driver. Process 500 may be implemented within a system such as system 200 or 250 depicted in FIGS. 2A and 2B, respectively. However, process 500 is not so limited. In step 510, the state of a host system is accessed. The state is related to graphics processing. For example, the state may define whether certain rendering operations should be performed. The state may be stored based on received calls, such as OpenGL calls, from an application program and accessed when desired.

In step 520, a vector is computed based on the graphics state that was accessed in step 510. The vector is a binary number of any length and can be used as an index to a LUT that comprises scheduling information. It will be understood that not every aspect of the state may need to be considered in order to properly program the hardware in the graphics processing pipeline. The present invention is well-suited to consider whatever types of state variables are useful to program the hardware. In one implementation, bits are set in the vector based on whether a state variable is “enabled” or “disabled.” However, embodiments of the present invention are also well-suited to base the vector on “mode” state variables, “value” state variables, and any other type of state variables.

In step 530, a memory-resident look-up table is indexed to determine an ordered sequence of macro-operations that are suitable for the current graphics state. Exemplary macro-operations include texture operation, blend operation, fog operation, and alpha operation. These examples correspond to operations in a rendering state that are substantially compliant with the OpenGL specification. However, the present invention is well-suited for other specifications. Moreover, it is not required that there be a one-to-one correspondence between operations in the graphics rendering state and macro-operations. For example, a single macro-operation can correspond to multiple operations in the graphics rendering state. Such an exemplary macro-operation is a “fog-alpha” macro-operation, which corresponds to distinct “fog” and “alpha” operations in the graphics rendering state. Furthermore, there may be more macro-operations in a given schedule than rendering operations in the corresponding graphics rendering state. For example, a “pass-through” macro-operation may be used that has no corresponding rendering operations in the graphics rendering state.

In step 540, instructions for programming the graphics pipeline based on the macro-operations are determined. This step may comprise executing modules within scheduling code according to an ordering of macro-operations in the LUT. The ordered list of macro-operations by itself does not necessarily contain all of the information to program the graphics pipeline. Therefore, additional information referred to herein as “context information” or the like may also be used in the determination of the hardware instructions. The hardware instructions may be stored in a hardware instruction cache.

In step 550, the hardware instructions are used to program a graphics pipeline, such that the state of the host system is implemented by the graphics pipeline. For example, elements in FIG. 3 such as the ALU and data fetch unit are programmed via the hardware instructions.

The preferred embodiment of the present invention, validating an integrated circuit graphics pipeline using pre-determined scheduling, is thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the below claims. In the claims, the order of elements does not imply any particular order of operations, steps, or the like, unless a particular element makes specific reference to another element as becoming before or after.

Claims

1. A method of determining a schedule of instructions for a graphics pipeline, said method comprising: accessing a state of a host system;determining a vector based on said state, wherein said vector comprises information about said state;indexing a table based on said vector to obtain a plurality of macro-operations associated with said state, wherein said plurality of macro-operations are associated with at least one operation to be performed by said graphics pipeline; anddetermining at least one instruction for programming said graphics pipeline to implement said state, wherein said at least one instruction is determined based on said plurality of macro-operations and also based on context information, wherein said context information comprises data associated with graphics processing that is used to perform said at least one operation.

2. The method of claim 1, wherein said at least one operation is selected from a group consisting of a texture operation, an alpha test operation, a stencil operation, a fog operation, an anti-alias operation, a depth test operation, an alpha test, a color mask operation, a blending operation, and a pass-through operation.

3. The method of claim 1, wherein said at least one other operation is selected from a group consisting of a multiply operation and an add operation.

4. The method of claim 1, wherein said context information further identifies data accessed as part of performing said at least one operation.

5. The method of claim 4, wherein said data comprises a texture map.

6. The method of claim 1, wherein said determining at least one instruction further comprises executing at least one module to generate said at least one instruction.

7. The method of claim 6 further comprising: determining an order of execution of said at least one module based on an ordering of said plurality of macro-operations, andwherein said determining at least one instruction further comprises executing said at least one module in said order of execution to generate said at least one instruction.

8. The method of claim 6, wherein said at least one module is selected from a group consisting of a texture module, an alpha test module, a fog module, an anti-alias module, a depth test module, and a color mask module.

9. The method of claim 1, wherein said state comprises at least one enable flag associated with said at least one operation.

10. The method of claim 1, wherein said state is substantially compliant with an OpenGL graphics state.

11. The method of claim 1, wherein said method is implemented by a device driver of said host system.

12. The method of claim 1, wherein said graphics pipeline comprises at least one unit selected from a group consisting of an arithmetic logic unit, a setup unit, a raster unit, a gatekeeper unit, a data fetch unit, and a data write unit.

13. The method of claim 1 further comprising: programming said graphics pipeline based on said at least one instruction.

14. A computer-readable memory having computer-readable program code embodied therein for causing a computer system to perform a method of determining a schedule of instructions for a graphics pipeline, said method comprising: accessing a state of a host system;determining a vector based on said state, wherein said vector comprises information about said state;indexing a table based on said vector to obtain a plurality of macro-operations associated with said state, wherein said plurality of macro-operations are associated with at least one operation to be performed by said graphics pipeline; anddetermining at least one instruction for programming said graphics pipeline to implement said state, wherein said at least one instruction is determined based on said plurality of macro-operations and also based on context information, wherein said context information comprises data associated with graphics processing that is used to perform said at least one operation.

15. The computer-readable memory of claim 14, wherein said at least one operation is selected from a group consisting of a texture operation, an alpha test operation, a stencil operation, a fog operation, an anti-alias operation, a depth test operation, an alpha test, a color mask operation, a blending operation, and a pass-through operation.

16. The computer-readable memory of claim 14, wherein said at least one other operation is selected from a group consisting of a multiply operation and an add operation.

17. The computer-readable memory of claim 14, wherein said context information further identifies data accessed as part of performing said at least one operation.

18. The computer-readable memory of claim 17, wherein said data comprises a texture map.

19. The computer-readable memory of claim 14, wherein said determining at least one instruction further comprises executing at least one module to generate said at least one instruction.

20. The computer-readable memory of claim 19, wherein said method further comprises: determining an order of execution of said at least one module based on an ordering of said plurality of macro-operations, andwherein said determining at least one instruction further comprises executing said at least one module in said order of execution to generate said at least one instruction.

21. The computer-readable memory of claim 19, wherein said at least one module is selected from a group consisting of a texture module, an alpha test module, a fog module, an anti-alias module, a depth test module, and a color mask module.

22. The computer-readable memory of claim 14, wherein said state comprises at least one enable flag associated with said at least one operation.

23. The computer-readable memory of claim 14, wherein said state is substantially compliant with an OpenGL graphics state.

24. The computer-readable memory of claim 14, wherein said method is implemented by a device driver of said host system.

25. The computer-readable memory of claim 14, wherein said graphics pipeline comprises at least one unit selected from a group consisting of an arithmetic logic unit, a setup unit, a raster unit, a gatekeeper unit, a data fetch unit, and a data write unit.

26. The computer-readable memory of claim 14, wherein said method further comprises: programming said graphics pipeline based on said at least one instruction.

27. A system comprising a processor and a memory, wherein said memory comprises instructions that when executed by said system implement a method of determining a schedule of instructions for a graphics pipeline, said method comprising: accessing a state of a host system;determining a vector based on said state, wherein said vector comprises information about said state;indexing a table based on said vector to obtain a plurality of macro-operations associated with said state, wherein said plurality of macro-operations are associated with at least one operation to be performed by said graphics pipeline; anddetermining at least one instruction for programming said graphics pipeline to implement said state, wherein said at least one instruction is determined based on said plurality of macro-operations and also based on context information, wherein said context information comprises data associated with graphics processing that is used to perform said at least one operation.

28. The system of claim 27, wherein said at least one operation is selected from a group consisting of a texture operation, an alpha test operation, a stencil operation, a fog operation, an anti-alias operation, a depth test operation, an alpha test, a color mask operation, a blending operation, and a pass-through operation.

29. The system of claim 27, wherein said at least one other operation is selected from a group consisting of a multiply operation and an add operation.

30. The system of claim 27, wherein said context information further identifies data accessed as part of performing said at least one operation.

31. The system of claim 30, wherein said data comprises a texture map.

32. The system of claim 27, wherein said determining at least one instruction further comprises executing at least one module to generate said at least one instruction.

33. The system of claim 32, wherein said method further comprises: determining an order of execution of said at least one module based on an ordering of said plurality of macro-operations, andwherein said determining at least one instruction further comprises executing said at least one module in said order of execution to generate said at least one instruction.

34. The system of claim 32, wherein said at least one module is selected from a group consisting of a texture module, an alpha test module, a fog module, an anti-alias module, a depth test module, and a color mask module.

35. The system of claim 27, wherein said state comprises at least one enable flag associated with said at least one operation.

36. The system of claim 27, wherein said state is substantially compliant with an OpenGL graphics state.

37. The system of claim 27, wherein said method is implemented by a device driver of said host system.

38. The system of claim 27, wherein said graphics pipeline comprises at least one unit selected from a group consisting of an arithmetic logic unit, a setup unit, a raster unit, a gatekeeper unit, a data fetch unit, and a data write unit.

39. The system of claim 27, wherein said method further comprises: programming said graphics pipeline based on said at least one instruction.