KR20070032387A - Legacy processing for pixel shader hardware - Google Patents

Abstract

The method may include receiving texture information and determining whether a precompiled shader corresponding to the texture information exists. If no precompiled shader corresponding to the texture information exists, a new shader may be compiled based on the texture information. If there is a precompiled shader that corresponds to the texture information, you can use the precompiled shader.

Description

Legacy processing for pixel shader hardware {LEGACY PROCESSING FOR PIXEL SHADER HARDWARE}

Implementations of the claimed invention may generally relate to graphical image processing, and more particularly to graphical image processing involving a legacy texture unit.

In graphics processing, textures have been applied or "mapped" to geometric primaries (eg, triangles) in an image. In the past, such texture mapping has involved so-called "fixed functions" that were determined by various combinations of hardware texture units. For example, the fixing function may involve one or more texture units that implement various texture environments, with or without additional hardware units for use in color summing, fog addition, stippling, and the like. In this way, various fixed processing functions have been built into the graphics hardware, and the graphics software application has relied on these fixed functions.

Most recently, graphics hardware has become programmable on-the-fly, in particular implementing the fixed functions implemented by previous non-programmable graphics hardware. Such programmable hardware can emulate a texture unit (eg, referred to herein as a " legacy " texture unit) constituting a legacy fixed function (or otherwise implement the functionality of the texture unit). The graphics processor can compile new fixed functions (e.g. pixel shaders) as they need. However, graphics software applications may also use legacy application programming interfaces (APIs) corresponding to legacy fixed functions. Such software applications can also change the texture environment relatively often, forcing recomputation of fixed functions (eg, pixel shaders) that undergo each change.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments consistent with the theory of the invention and, together with the description, describe such embodiments. The drawings are not necessarily drawn to scale, with emphasis instead being placed upon illustrating the theory of the invention.

1 illustrates an example system.

2 is a flowchart illustrating processing of graphical data.

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may be used to identify the same or similar components. In the following description, which is for purposes of illustration and not limitation, specific details are set forth such as specific structures, architectures, interfaces, techniques, etc., in order to understand various aspects of the claimed subject matter. However, those skilled in the art will appreciate the advantages of the present invention that the various aspects of the claimed invention may be practiced in other examples that depart from these measurement details. In some cases, descriptions of well-known devices, circuits, and methods are omitted, so that the techniques of the present invention are unnecessarily detailed and not obscured.

1 illustrates an example system 100. System 100 may include a processor 110, graphics processor 120, graphics memory 130, programmable hardware 140, and frame buffer 150. In some implementations, one or more components 120-150 may be included in a physically separate graphics card connected to the processor 110 via a data bus. In some implementations, components 120-150 may be disposed on a common circuit board (eg, motherboard, daughter card, etc.) with component 110. In some implementations, one or more components 120-150 can be part of any portion (eg, core) of the device, and processor 110 can be included in another portion (eg, other core) of the same device. .

The processor 110 may include general purpose processors, dedicated processors, and / or dedicated logic. Processor 110 may be arranged to distribute graphics data (eg, a state vector) to graphics processor 120 via a data bus. The processor 110 may deliver graphics data under the control of a program, such as rendering, games, graphics generation, or other types of graphics related programs. In some implementations, the processor 110 may communicate graphical information using an application programming interface (API), such as a legacy graphical API. This graphical information may include, for example, texture environments, geometric data, and the like.

The graphics processor 120 may include general purpose processors, dedicated processors, and / or dedicated logic. The graphics processor 120 may be arranged to receive graphics data from the processor 110 and convert the graphics data into a program (eg, a pixel shader) to be executed by the programmable hardware 140. In some cases, graphics processor 120 may compile a program primarily using graphics data received from processor 110.

In some cases, graphics processor 120 may use the received graphic information to retrieve and reuse a precompiled program (eg, pixel shader) stored in graphics memory 130. In this case, graphics processor 120 generates a signature or other index from the received graphic data to help quickly find such a precompiled program in memory 130. The operation of the graphics processor 120 related to creating a new program or using an already created program will be further described below.

The graphic memory 130 may include a storage device for storing graphic data. The graphics memory 130 may include a RAM device such as DRAM, DDR RAM, or the like. Although shown as being connected to a graphics processor, in some implementations, graphics memory 130 may be connected to (at least directly writeable / readable by) at least one processor 110 and programmable hardware 140. have.

The graphics memory 130 may receive and store graphics data and / or programs from the processor 110 and the graphics processor 120. In addition to storing graphics data, graphics memory 130 also stores indexes and / or signature lists associated with such graphics data and / or programs to quickly check for the presence of specific information (eg, specific pixel shader programs). Makes it possible to do

Programmable hardware 140 may be arranged to perform certain graphic rendering operations on the graphic data based on the received program (eg, pixel shader). This operation may be performed on rasterized graphical data and may include some combination of texturing, color summing, fog addition, ignition, and the like. Programmable hardware 140 may receive such a program from graphics processor 120, for example, to execute a legacy fixed function. In some implementations, programmable hardware 140 can receive a program address in memory 130 and read this program directly from memory 130.

Frame buffer 150 may be arranged to receive processed data from programmable hardware 140 and to buffer the data before displaying it (if necessary). The frame buffer 150 may output data to a display or display interface, possibly under the control of the graphic processor 120. Associated displays (not shown) may include televisions, monitors, projectors, or other devices suitable for displaying graphical information such as video and / or graphics. Such displays may utilize a number of display technologies, including cathode ray tubes (CRTs), liquid crystal displays (LCDs), plasma and / or projection technologies.

2 is a flow chart 200 illustrating the processing of graphical data. Process 200 may be described with respect to system 100 for ease of explanation, but the claimed invention is not necessarily limited in this respect. In some implementations, process 200 may only be performed if some aspect of the current texture environment changes. In some implementations, process 200 can only be performed when legacy APIs are used and some aspects of current texturing schemes change.

Processing may begin with graphics processor 120 receiving graphics data (state vector in some implementations) from processor 110. Graphics processor 120 may generate a signature for the received state vector (execution 210). In some implementations, this signature can be a shortened and / or compressed version of a state vector including, for example, texture environment (s), fog, color summation information, and the like. Such a compressed state vector signature may contain only a few bytes per texture unit instead of tens of bytes per texture for the state vector. In some implementations, the signature can be a hash, checksum or other known identification method that generates relatively quickly for a given piece of graphical data. This hashing may be performed by graphics processor 120 in a state vector or compressed state vector version.

Processing may continue with graphics processor 120 checking memory 130 for an existing signature that matches the signature generated at execution 210 (execution 220). The presence of an existing signature in memory 130 may indicate that a precompiled program (eg, pixel shader) corresponding to the received state vector is available in memory 130.

If no signature match (and thus no precompiled shader) is found [execution 230], graphics processor 120 may compile a pixel shader program corresponding to the received state vector [execution 240]. This new pixel shader can correspond to legacy fixed functions that have not previously occurred in a given graphics application.

As such, graphics processor 120 may store the new pixel shader in graphics memory 130 for later reuse (execution 250). At run 250, the graphics processor may also store the associated signature generated at run 210, so that a new pixel shader may be found at a later run 220.

Processing may end with graphics processor 120 returning the pixel shader to programmable hardware 140 for further processing (execution 260). In some implementations (eg, if execution 250 has already been performed), processor 120 can pass the shader address in memory 130 to programmable hardware 140. Programmable hardware 140 may then execute the program at that address at a suitable time. In some implementations, the processor 120 may deliver the pixel shader program directly to the programmable hardware 140 to enable the executions 250 and 260 to be performed simultaneously.

Returning to execution 220, if a matching signature (and an appropriate precompiled shader) is found in memory 130 [execution 230], graphics processor 120 may execute the precompiled pixel shader for other processing. Return to programmable hardware 140 (execution 260). Such precompiled pixel shaders may correspond to legacy fixed functions that previously occurred in a given graphics application and may be reused. This reuse of pixel shaders can prevent the use of resources to recompile the pixel shaders previously encountered for every change in the texture environment.

The above description of one or more embodiments provides illustrations and descriptions, but is not intended to limit the scope of the invention to the precise forms disclosed. Modifications and variations are possible in light of the above teachings, which may be accomplished by practicing various embodiments of the invention.

For example, the shader reuse schemes described herein have been described primarily with respect to legacy APIs, but these schemes can also be used with any number of graphical APIs and combinations thereof to prevent unnecessary recompilation.

In addition, the execution of FIG. 2 need not be implemented in the order shown, nor do all necessarily need to be performed. Also, those runs that do not depend on other runs can be performed in parallel with the other runs. Further, at least some of the executions in this figure may be implemented as instructions or groups of instructions executed on a machine-readable recording medium.

Any component, implementation or instruction used in the description of the present application should not be construed as important or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” includes one or more items. Modifications and variations may be made in the above-described embodiment (s) of the claimed invention without departing substantially from the spirit and theory of the invention. All such changes and modifications are intended to be included within the scope of this disclosure and protected by the following claims.

Claims (18)

Receiving texture information; Determining whether a precompiled shader corresponding to the texture information exists; Compiling a new shader based on the texture information if the precompiled shader corresponding to the texture information does not exist; Using the precompiled shader if the precompiled shader corresponding to the texture information exists. Way. The method of claim 1, The determining step, Generating a signature related to the texture information; Checking whether the signature already exists in memory; Way. The method of claim 2, If it is determined that the signature does not yet exist in the memory, the checking further comprises storing the signature and the new shader. Way. The method of claim 2, The generating may include compressing the test information to generate the signature. Way. The method of claim 1, The texture information is included in an application programming interface (API). Way. Memory for storing texturing programs, Programmable hardware to execute texturing programs, Receive texture information, check a memory for a texturing program corresponding to the texture information, and if a texturing program corresponding to the texture information is found in the memory, transfer the programmable hardware to the texture program corresponding to the texture information. Including a processor to indicate system. The method of claim 6, If the texturing program corresponding to the texture information is not found in the memory, the processor is configured to compile the texture information into a new texturing program. system. The method of claim 7, wherein The processor is further configured to store the new texturing program in the memory and direct the programmable hardware to the new texturing program. system. The method of claim 8, The processor is further configured to generate a signature corresponding to the new texturing program and to store the signature in the memory. system. The method of claim 6, The processor is configured to generate a signature from the texture information and use the signature to check the memory for the texturing program corresponding to the texture information. system. The method of claim 6, It further includes another processor for passing texture information in the API to the processor system. A machine-accessible recording medium comprising instructions, comprising: When executed, the instruction causes the machine to: Generate a signature from the received graphics API, Determine whether the memory includes a pixel shader program corresponding to the graphics API based on the signature, If the memory includes the pixel shader program, direct programmable hardware to execute the pixel shader program corresponding to the graphics API, If the memory does not include the pixel shader program corresponding to the graphics API, causing a new pixel shader program to be compiled based on the graphics API Machine-accessible recording medium. The method of claim 12, When running, causes the machine to And instructions for storing the new pixel shader program in the memory. Machine-accessible recording medium. The method of claim 12, When running, causes the machine to And instructing the programmable hardware to execute the new pixel shader program if the memory does not include the pixel shader program corresponding to the graphics API. Machine-accessible recording medium. To accommodate the new texture environment, Generating a new signature corresponding to the new texture environment; Checking a memory for a stored signature corresponding to the new signature; Programming the hardware with a stored pixel shader corresponding to the stored signature if the memory includes the stored signature. Way. The method of claim 15, Generating a new pixel shader corresponding to the new texture environment if the memory does not include the stored signature. Way. The method of claim 16, Storing the new pixel shader and the new signature in the memory. Way. The method of claim 16, Programming the hardware with the new pixel shader. Way.

Images