Embodiments of the present invention generally relate to computer graphics.
Recent advances in computer performance have enabled graphics systems to provide more realistic graphical images using personal computers, home video game computers, handheld devices, and the like. In such graphics systems, a number of procedures are executed to render or draw graphics primitives to the screen of the system. A graphics primitive is a basic component of a graphic, such as a point, line, polygon, or the like. Rendered images are formed with combinations of these graphics primitives. Many procedures may be utilized to perform three-dimensional (3-D) graphics rendering.
Specialized graphics processing units (GPUs) have been developed to increase the speed at which graphics rendering procedures are executed. The GPUs typically incorporate one or more rendering pipelines. Each pipeline includes a number of hardware-based functional units that are designed for high-speed execution of graphics instructions/data. Generally, the instructions/data are fed into the front end of a pipeline and the computed results emerge at the back end of a pipeline. The hardware-based functional units, cache memories, firmware, and the like, of the GPUs are designed to operate on the basic graphics primitives and produce real-time rendered 3-D images.
There is increasing interest in rendering 3-D graphical images in portable or handheld devices such as cell phones, personal digital assistants (PDAs), and other devices. However, portable or handheld devices generally have limitations relative to more full-sized devices such as desktop computers. For example, because portable devices are typically battery-powered, power consumption is a concern. Also, because of their smaller size, the space available inside portable devices is limited. The desire is to quickly perform realistic 3-D graphics rendering in a handheld device, within the limitations of such devices.
Embodiments of the present invention provide methods and systems for quickly and efficiently processing data in a graphics processor unit pipeline.
Pixel data for a group of pixels proceeds collectively down the graphics pipeline to the arithmetic logic units (ALUs). In the ALUs, a same instruction is applied to all pixels in a group in SIMD (single instruction, multiple data) fashion. For example, in a given clock cycle, an instruction will specify a set of operands that are selected from the pixel data for a first pixel in the group of pixels. In the next clock cycle, the instruction will specify another set of operands that are selected from the pixel data for a second pixel in the group, and so on. According to embodiments of the present invention, a conditional execute bit is associated with each set of operands. The values of the conditional execute bits determine how (whether) the respective sets of operands are processed by the ALUs.
In general, if a conditional execute bit is set to do not execute, then the pixel data associated with that conditional execute bit is not operated on by the ALUs. More specifically, in one embodiment, the pixel data is not latched by the ALUs if the conditional execute bit is set to do not execute; this can be accomplished by gating the input flip-flops to the ALUs so that the flip-flops do not clock in the pixel data. Accordingly, the ALUs do not change state—the latches (flip-flops) in the ALUs remain in the state they were in on the previous clock cycle. Power is saved by not clocking the flip-flops, and power is also saved because the inputs to the combinational logic remain the same and therefore no transistors change state (the flip-flops do not transition from one state to another because, if the conditional bit is set to do not execute, then the operands remain the same from one clock cycle to the next).
In summary, an instruction is applied across a group of pixels, but it may not be necessary to execute the instruction on each pixel in the group. To maintain proper order in the pipeline, the instruction is applied to each pixel in the group—a set of operands is selected for each pixel in the group. However, if a conditional execute bit associated with a set of operands is set to do not execute, then those operands are not operated on by the ALUs—the associated instruction is not executed on the operands and instead the downstream operands are replicated. Consequently, flip-flops are not unnecessarily clocked and combinational logic is not unnecessarily switched, thereby saving power. As such, embodiments of the present invention are well-suited for graphics processing in handheld and other portable, battery-operated devices (although the present invention is not limited to use on those types of devices).
These and other objects and advantages of the various embodiments of the present invention will be recognized by those of ordinary skill in the art after reading the following detailed description of the embodiments that are illustrated in the various drawing figures.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of embodiments of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be recognized by one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the embodiments of the present invention.
Some portions of the detailed descriptions, which follow, are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits within a 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 “determining” or “using” or “setting” or “latching” or “clocking” or “identifying” or “selecting” or “processing” or “controlling” or the like, refer to the actions and processes of a computer system (e.g., computer system 100 of
The GPU can be implemented as a discrete component, a discrete graphics card designed to couple to the computer system via a connector (e.g., an Accelerated Graphics Port slot, a Peripheral Component Interconnect-Express slot, etc.), a discrete integrated circuit die (e.g., mounted directly on a motherboard), or an integrated GPU included within the integrated circuit die of a computer system chipset component (not shown) or within the integrated circuit die of a PSOC (programmable system-on-a-chip). Additionally, a local graphics memory 114 can be included for the GPU for high bandwidth graphics data storage.
In the example of
The program sequencer functions by controlling the operation of the functional modules of the graphics pipeline. The program sequencer can interact with the graphics driver (e.g., a graphics driver executing on the CPU 101 of
In one embodiment, data proceeds between the functional modules 220-240 in a packet-based format. For example, the graphics driver transmits data to the GPU in the form of data packets, or pixel packets, that are specifically configured to interface with and be transmitted along the fragment pipe communications pathways of the pipeline. A pixel packet generally includes information regarding a group or tile of pixels (e.g., four pixels, eight pixels, 16 pixels, etc.) and coverage information for one or more primitives that relate to the pixels. A pixel packet can also include sideband information that enables the functional modules of the pipeline to configure themselves for rendering operations. For example, a pixel packet can include configuration bits, instructions, functional module addresses, etc., that can be used by one or more of the functional modules of the pipeline to configure itself for the current rendering mode, or the like. In addition to pixel rendering information and functional module configuration information, pixel packets can include shader program instructions that program the functional modules of the pipeline to execute shader processing on the pixels. For example, the instructions comprising a shader program can be transmitted down the graphics pipeline and be loaded by one or more designated functional modules. Once loaded, during rendering operations, the functional module can execute the shader program on the pixel data to achieve the desired rendering effect.
In this manner, the highly optimized and efficient fragment pipe communications pathway implemented by the functional modules of the graphics pipeline can be used not only to transmit pixel data between the functional modules (e.g., modules 220-240), but to also transmit configuration information and shader program instructions between the functional modules.
In the example of
The rasterizer 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. In one embodiment, the graphics system renders a two pixel-by-two pixel region of a display screen, referred to as a quad.
Each pixel packet includes a payload of pixel attributes required for processing (e.g., color, texture, depth, fog, x and y locations, etc.) and sideband information (pixel attribute data is provided by the data fetch stage 330). A pixel packet may contain one row of data or it may contain multiple rows of data. A row is generally the width of the data portion of the pipeline bus.
The data fetch stage fetches data for pixel packets. Such data may include color information, any depth information, and any texture information for each pixel packet. Fetched data is placed into an appropriate field, which may be referred to herein as a register, in a row of pixel data prior to sending the pixel packet on to the next stage.
From the data fetch stage, rows of pixel data enter the arithmetic logic stage 230. In the present embodiment, one row of pixel data enters the arithmetic logic stage each clock cycle. In one embodiment, the arithmetic logic stage includes four ALUs 0, 1, 2 and 3 (
The output of the arithmetic logic stage goes to the data write stage. The data write stage stores pipeline results in a write buffer or in a framebuffer in memory (e.g., graphics memory 114 or memory 115 of
Sideband information 420 is associated with each row of pixel data. The sideband information includes, among other things, information that identifies or points to an instruction that is to be executed by an ALU using the pixel data identified by the instruction. In other words, the sideband information associated with row 0 identifies, among other things, an instruction I0. An instruction can specify, for example, the type of arithmetic operation to be performed and which registers contain the data that is to be used as operands in the operation.
In one embodiment, the sideband information includes a conditional execute bit per row of pixel data. The value of the conditional execute bit may be different for each row of pixel data, even if the rows are associated with the same pixel. A conditional execute bit associated with a row of pixel data can be set in order to prevent execution of an instruction on operands of the associated pixel. For example, if the conditional execute bit associated with P0R0 is set to do not execute, then instruction I0 will not be executed for pixel P0 (but can still be executed for the other pixels in the group). The function of the conditional execute bit is described further below, in conjunction with
With each new clock cycle, a row of pixel data proceeds in succession from the data fetch stage to the arithmetic logic stage of the pipeline. For example, row 0 proceeds down the pipeline on a first clock, followed by row 1 on the next clock, and so on. Once all of the rows associated with a particular group of pixels (e.g., a quad) are loaded into the pipeline, rows associated with the next quad can begin to be loaded into the pipeline.
In one embodiment, rows of pixel data for each pixel in a group of pixels (e.g., a quad) are interleaved with rows of pixel data for the other pixels in the group. For example, for a group of four pixels, with four rows per pixel, the pixel data proceeds down the pipeline in the following order: the first row for the first pixel (P0r0 through P0r3), the first row for the second pixel (P1r0 through P1r3), the first row for the third pixel (P2r0 through P2r3), the first row for the fourth pixel (P3r0 through P3r3), the second row for the first pixel (P0r4 through P0r7), the second row for the second pixel (P1r4 through P1r7), the second row for the third pixel (P2r4 through P2r7), the second row for the fourth pixel (P3r4 through P3r7), and so on to the fifteenth row, which includes P3r12 through P3r15. As mentioned above, there may be less than four rows per pixel. By interleaving rows of pixel packets in this fashion, stalls in the pipeline can be avoided, and data throughput can be increased.
Thus, in the present embodiment, a row of pixel data (e.g., row 0) including sideband information 420 is delivered to the deserializer 510 each clock cycle. In the example of
In the example of
Pixel data including sideband information for a group of pixels (e.g., quad 0) arrives at the arithmetic logic stage, followed by pixel data including sideband information for the next group of pixels (e.g., quad 1), which is followed by the pixel data including sideband information for the next group of pixels (e.g., quad 2).
Once all of the rows of pixel data associated with a particular pixel have been deserialized, the pixel data for that pixel can be operated on by the ALUs. In one embodiment, the same instruction is applied to all pixels in a group (e.g., a quad). The ALUs are effectively a pipelined processor that operates in SIMD (same instruction, multiple data) fashion across a group of pixels.
As noted above, in one embodiment, the same instruction originating from the per-row sideband information is applied to all pixels in a group (e.g., a quad). For example, at a given clock cycle, an instruction will specify a set of operands that are selected from the pixel data for a first pixel in the group of pixels. In the next clock cycle, the instruction will specify another set of operands that are selected from the pixel data for a second pixel in the group, and so on. According to embodiments of the present invention, a conditional execute bit originating from the per-row sideband information is associated with each set of operands. In general, if a conditional execute bit is set to do not execute, then the operands associated with that conditional execute bit are not operated on by the ALUs.
In the example of
Accordingly, the operands P2.I2 are not operated on by the ALU. More specifically, in one embodiment, the operands P2.I2 are not latched by the ALU if the conditional execute bit is set to do not execute. As a result, the pipe stages of the ALU that would have operated on these operands do not change state. Thus, at clock cycle N, both stage 1 and stage 2 of the ALU contain the same data (P1.I2), because the flip-flops are not latched and therefore remain in the state they were in on the previous clock cycle N−1. Accordingly, the combinational logic in the downstream pipe stages of the ALU does not transition and power is not unnecessarily expended.
In clock cycle N+1, the combinational logic in stage 2 of the ALU is not switched because the operands are the same as that in the preceding clock cycle. Similarly, in clock cycle N+2, the combinational logic in stage 3 of the ALU is not switched. In clock cycle N+3, the flip-flops associated with stage 4 do not change state because the set of operands is the same as in the preceding clock cycle.
Even though the conditional execute bit is set to do not execute for the operands P2.I2, a set of “non-useful” operands effectively propagates through the ALU in its place. In this manner, the order of data through the graphics pipeline is maintained, and the timing across ALUs is also maintained.
Generally speaking, when the conditional execute bit is set to do not execute, the ALU does not perform any work on the pixel data associated with the conditional execute bit. In effect, the conditional execute bit acts as an enabling bit—if the bit is set to do not execute, then data flip-flops are not enabled and will not capture the new input operands. Instead, the outputs of the flip-flops retain their current state (the state introduced when data was captured in the preceding clock cycle). In one embodiment, this is achieved by gating the clocks of the flip-flops. If the conditional execute bit is set to do not execute, then the flip-flops that capture the input operands are not clocked—the clock signals do not transition, and so new data is not captured by the flip-flops. In one embodiment, only the flip-flops (e.g., latch 710 of
Power is saved by not clocking the flip-flops in the ALUs when not necessary. Power is also saved in the combinational logic of the ALUs because no switching activity occurs in the logic, because the operands are the same from clock to clock.
In block 810, arithmetic operations are performed according to an instruction. The same instruction is applied to different sets of operands of pixel data. Each set of operands is associated with a respective pixel in a group (e.g., quad) of pixels. A conditional execute bit is also associated with each set of operands.
In block 820, the value of the conditional execute bit associated with a set of operands is used to determine whether those operands are to be loaded into the ALUs. More specifically, the operands are loaded into and operated on by the ALUs if the conditional execute bit is set to a first value (e.g., 0 or 1) but not loaded into or operated on by the ALUs if the conditional execute bit is set to a second value (e.g., 1 or 0, respectively).
In summary, an instruction is applied across a group of pixels, but it may not be necessary to execute the instruction on pixel data for each pixel in the group. To maintain proper order in the pipeline, the instruction is applied to each pixel in the group—a set of operands is selected from the pixel data for each pixel in the group. However, if a conditional execute bit associated with a set of operands for a pixel is set to do not execute, then those operands for that pixel are not operated on by the ALUs. Consequently, ALU flip-flops are not unnecessarily clocked and switched, thereby saving power. As such, embodiments of the present invention are well-suited for graphics processing in handheld and other portable, battery-operated devices, as well as in other types of devices.
The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and many modifications and variations are possible in light of the above teaching. For example, embodiments of the present invention can be implemented on GPUs that are different in form or function from the GPU 110 of
This application is related to U.S. patent application Ser. No. ______ by T. Bergland et al., filed on ______, entitled “Buffering Deserialized Pixel Data in a Graphics Processor Unit Pipeline,” with Attorney Docket No. NVID-P003219, assigned to the assignee of the present invention, and hereby incorporated by reference in its entirety. This application is related to U.S. patent application Ser. No. ______ by T. Bergland et al., filed on ______, entitled “Shared Readable and Writeable Global Values in a Graphics Processor Unit Pipeline,” with Attorney Docket No. NVID-P003476, assigned to the assignee of the present invention, and hereby incorporated by reference in its entirety.