Graphics processor with arithmetic and elementary function units

A graphics processor capable of efficiently performing arithmetic operations and computing elementary functions is described. The graphics processor has at least one arithmetic logic unit (ALU) that can perform arithmetic operations and at least one elementary function unit that can compute elementary functions. The ALU(s) and elementary function unit(s) may be arranged such that they can operate in parallel to improve throughput. The graphics processor may also include fewer elementary function units than ALUs, e.g., four ALUs and a single elementary function unit. The four ALUs may perform an arithmetic operation on (1) four components of an attribute for one pixel or (2) one component of an attribute for four pixels. The single elementary function unit may operate on one component of one pixel at a time. The use of a single elementary function unit may reduce cost while still providing good performance.

BACKGROUND

The present disclosure relates generally to circuits, and more specifically to graphics processors.

Graphics processors are widely used to render 2-dimensional (2-D) and 3-dimensional (3-D) images for various applications such as video games, graphics, computer-aided design (CAD), simulation and visualization tools, imaging, etc. A 3-D image may be modeled with surfaces, and each surface may be approximated with polygons (typically triangles). The number of triangles used to represent a 3-D image is dependent on the complexity of the surfaces as well as the desired resolution of the image and may be quite large, e.g., in the millions. Each triangle is defined by three vertices, and each vertex is associated with various attributes such as space coordinates, color values, and texture coordinates. Each attribute may have up to four components.

A graphics processor may perform various graphics operations to render an image. The graphics operations may include rasterization, stencil and depth tests, texture mapping, shading, etc. The image is composed of many triangles, and each triangle is composed of picture elements (pixels). The graphics processor renders each triangle by determining the values of the components of each pixel within the triangle.

A graphics processor may employ a shader core to perform certain graphics operations such as shading. Shading is a highly complex graphics operation involving lighting, shadowing, etc. The shader core may need to compute transcendental elementary functions such as sine, cosine, reciprocal, logarithm, exponential, square root, and reciprocal square root. These elementary functions may be approximated with polynomial expressions, which may be evaluated with relatively simple instructions executed by an arithmetic logic unit (ALU). However, shader performance may suffer greatly from computing the elementary functions in this manner using an ALU.

SUMMARY

Graphics processors capable of efficiently performing arithmetic operations and computing elementary functions are described herein. The terms “operation” and “function” are sometimes used interchangeably. A graphics processor comprises a shader core and possibly other units. The shader core has at least one ALU that can perform arithmetic operations and at least one elementary function unit that can compute elementary functions. In some embodiments, the ALU(s) and elementary function unit(s) are arranged and interconnected such that they can operate in parallel on instructions for the same or different threads to improve throughput. For example, the ALU(s) may execute one instruction for one thread, and the elementary function unit(s) may concurrently execute another instruction for another thread. These threads may be for the same or different graphics applications.

In other embodiments, the shader core has fewer elementary function units than ALUs, e.g., four ALUs and a single elementary function unit. The four ALUs may perform an arithmetic operation on (1) up to four components of an attribute for one pixel or (2) one component of an attribute for up to four pixels. The single elementary function unit may operate on one component of one pixel at a time. The use of a single elementary function unit may reduce cost (since elementary function units are more complex and costly than ALUs) while still providing good performance (since elementary functions have lower average usage than arithmetic operations).

DETAILED DESCRIPTION

FIG. 1shows a block diagram of a graphics system100that supports N graphics applications/programs110athrough110n, where in general N≧1. Graphics system100may be a stand-alone system or part of a larger system such as a computing system, a wireless communication device, etc. Graphics applications110athrough110nmay be for video games, graphics, etc., and may run concurrently. Each graphics application110may generate threads to achieve the desired results. A thread (or thread of execution) indicates a specific task that may be performed with a sequence of one or more instructions. Threads allow a graphics application to have multiple tasks performed simultaneously by different units and further allow different graphics applications to share resources.

A graphics processor120receives the threads from graphics applications110athrough110nand performs the tasks indicated by these threads. In the embodiment shown inFIG. 1, graphics processor120includes a shader core/processor130, a texture engine140, and a cache memory system150. A core generally refers to a processing unit within an integrated circuit. The terms “core”, “engine”, “processor” and “processing unit” are often used interchangeably. Shader core130may perform certain graphics operations such as shading and may compute transcendental elementary functions. Texture engine140may perform other graphics operations such as texture mapping. Cache memory system150may include one or more caches, which are fast memories that can store data and instructions for shader core130and texture engine140.

Graphics processor120may include other processing and control units, engines, and memories. For example, graphics processor120may include one or more additional engines that perform triangle setup, rasterization, stencil and depth tests, attribute setup, pixel interpolation, etc. The various graphics operations described herein are known in the art. The additional engine(s) may be coupled between graphics applications110and shader core130or may be coupled to shader core130. Graphics processor120may implement a software interface such as Open Graphics Library (OpenGL), Direct3D, etc. OpenGL is described in a document entitled “The OpenGL® Graphics System: A Specification,” Version 2.0, dated Oct. 22, 2004, which is publicly available.

A main memory160is a large, slower memory located further away (e.g., off-chip) from graphics processor120. Main memory160stores data and instructions that may be loaded into the caches within cache memory system150.

FIG. 2illustrates attributes and components of a pixel. As noted above, a 2-D or 3-D image may be composed of many triangles, and each triangle may be composed of pixels. Each pixel may have various attributes such as space coordinates, color values, texture coordinates, etc. Each attribute may have up to four components. For example, space coordinates may be given by three components for horizontal and vertical coordinates (x and y) and depth (z) or by four components x, y, z, and w, where w is a fourth term for homogeneous coordinates. Homogeneous coordinates are useful for certain graphics operations such as translation, scaling, rotation, etc. Color values are typically given by red (r), green (g), and blue (b). Texture coordinates are typically given by horizontal and vertical coordinates (u and v). A pixel may also be associated with other attributes.

In many cases, it is desirable to operate on groups of pixels in an image to be rendered. The group size may be selected based on various factors such as hardware requirements, performance, etc. A group size of 2×2 may provide a good tradeoff between the various factors. Processing on four pixels in a 2×2 grid may be performed in several manners.

FIG. 3Ashows pixel-parallel processing on four pixels 1 through 4 with four identical scalar ALUs, ALU1 through ALU4, respectively. In this example, the four components of an attribute being operated on are denoted as Ap,1, Ap,2, Ap,3and Ap,4, where p is a pixel index and pε{1, 2, 3, 4} for pixels 1 through 4. These components may be for space coordinates, color values, texture coordinates, etc. The four operands to be applied to the four components are denoted as Bp,1, Bp,2, Bp,3and Bp,4, for pε{1, 2, 3, 4} and may be constants. In this example, the ALUs perform a multiply and accumulate (MAC) operation. The four components of each pixel are thus multiplied with the four operands, and the four intermediate results are accumulated to generate a final result for that pixel.

For pixel-parallel processing inFIG. 3A, each scalar ALU operates on the four components of one pixel, and the four ALUs concurrently operate on the four pixels. ALU1 multiplies component A1,1with B1,1in the first clock period T1, then multiplies component A1,2with B1,2and accumulates this result with the prior result in the second clock period T2, then multiplies component A1,3with B1,3and accumulates this result with the prior result in the third clock period T3, then multiplies component A1,4with B1,4and accumulates this result with the prior result in the fourth clock period T4. ALU2 through ALU4 similarly operate on the components of pixels 2 through 4, respectively.

FIG. 3Bshows component-parallel processing on four pixels with one quad ALU, which may also be called a vector-based ALU. For component-parallel processing, the quad ALU operates on all four components of one pixel at a time. Thus, the quad ALU multiplies components A1,1, A1,2, A1,3and A1,4with operands B1,1, B1,2, B1,3and B1,4, respectively, and accumulates the four intermediate results to obtain the final result for the first pixel in the first clock period T1. The quad ALU similarly operates on the components of the second, third and fourth pixels in clock periods T2, T3and T4, respectively.

FIGS. 3A and 3Bshow two schemes for performing quad processing on up to four components of an attribute for up to four pixels. Quad processing for arithmetic operations may be performed by a single quad ALU or four scalar ALUs. In the following description, ALUs are assumed to be scalar ALUs unless noted otherwise. Quad processing may substantially improve performance. Thus, shader core130may be designed with capability to perform quad processing.

FIG. 4shows a block diagram of an embodiment of a shader core/processor130awith a 4-unit ALU core440and a 4-unit elementary function core450. Shader core130amay be used for shader core130inFIG. 1.

Within shader core130a, a multiplexer (Mux)410receives threads from graphics applications110athrough110nand provides these threads to a thread scheduler and context register420. Thread scheduler420performs various functions to schedule and manage execution of threads. Thread scheduler420determines whether to accept new threads, creates a register map table for each accepted thread, and allocates resources to the threads. The register map table indicates mapping between logical register address to physical register file address. For each thread, thread scheduler420determines whether resources required for that thread are ready, pushes the thread into a sleep queue if any resource (e.g., instruction, register file, or texture read) for the thread is not ready, and moves the thread from the sleep queue to an active queue when all of the resources are ready. Thread scheduler420interfaces with a load control unit460in order to synchronize the resources for the threads.

Thread scheduler420also manages execution of threads. Thread scheduler420fetches the instruction(s) for each thread from an instruction cache422, decodes each instruction if necessary, and performs flow control for the thread. Thread scheduler420selects active threads for execution, checks for read/write port conflict among the selected threads and, if there is no conflict, sends instruction(s) for one thread into a processing core430and sends instruction(s) for another thread to load control unit460. Thread scheduler420maintains a program/instruction counter for each thread and updates this counter as instructions are executed or program flow is altered. Thread scheduler420also issues requests to fetch for missing instructions and removes threads that are completed.

Instruction cache422stores instructions for the threads. These instructions indicate specific operations to be performed for each thread. Each operation may be an arithmetic operation, an elementary function, a memory access operation, etc. Instruction cache422may be loaded with instructions from cache memory system150and/or main memory160, as needed, via load control unit460

In the embodiment shown inFIG. 4, processing core430includes ALU core440and elementary function core450. ALU core440performs arithmetic operations such as addition, subtraction, multiplication, multiply and accumulate, absolute, negation, comparison, saturation, etc. ALU core440may also perform logical operations such as AND, OR, XOR, etc. ALU core440may also perform format conversion, e.g., from integers to floating point numbers, and vice versa. In the embodiment shown inFIG. 4, ALU core440may be a single quad ALU or four scalar ALUs. ALU core440may perform pixel-parallel processing on one component of an attribute for up to four pixels, as shown inFIG. 3A. Alternatively, ALU core440may perform component-parallel processing on up to four components of an attribute for a single pixel, as shown inFIG. 3B.

In the embodiment shown inFIG. 4, elementary function core450is composed of four elementary function units that can compute an elementary function for one component of an attribute for up to four pixels (pixel-parallel) or up to four components of an attribute for one pixel (component-parallel). Elementary function core450may compute transcendental elementary functions such as sine, cosine, reciprocal, logarithm, exponential, square root, reciprocal square root, etc, which are widely used in shader instructions. Elementary function core450may improve shader performance by computing the elementary functions in much less time than the time required to perform polynomial approximations of the elementary functions using simple instructions.

Load control unit460controls the flow of data and instructions for various units within shader core130a. Load control unit460interfaces with cache memory system150and loads instruction cache422, a constant buffer432, and register file banks/output buffer470with data and instructions from cache memory system150. Load control unit460also saves the data in output buffer470to cache memory system150. Load control unit460also provides instructions to texture engine140.

Constant buffer432stores constant values used by ALU core440. Output buffer470stores temporary results as well as final results from ALU core440and elementary function core450for threads. A demultiplexer (Demux)480receives the final results for the executed threads from output buffer470and provides these results to the graphics applications.

In the embodiment shown inFIG. 4, processing core430includes both ALU core440and elementary function core450. This embodiment allows ALU core440and elementary function core450to share buses that couple cores440and450to other units (e.g., thread scheduler420and output buffer470) within shader core130a.

Elementary function units are generally more complex than ALUs. Even with cost-effective implementations, elementary function units typically occupy much larger circuit area than ALUs and are thus more expensive than ALUs. To achieve high shader throughput for all shader instructions, the number of elementary function units may be selected to match the number of ALUs, which is four in the embodiment shown inFIG. 4. However, studies have shown that even though elementary functions are widely used, the average usage of elementary functions is fairly lower than the average usage of ALU operations. The lower average usage results from elementary functions being called less often than arithmetic operations as well as fewer components being operated on by elementary functions than arithmetic operations. For example, elementary functions are typically called less often than arithmetic operations and may thus be adequately supported by fewer elementary function units. Furthermore, while it may be common to perform addition or multiplication on all four components of an attribute, which would then benefit from having four ALUs, it is less common to perform an elementary function on all four components. Hence, fewer elementary function units may be able to provide good performance in many cases in which elementary functions are performed on only a subset of the components, e.g., one or two components. Implementing fewer elementary function units may reduce cost while still providing good performance.

FIG. 5shows a block diagram of an embodiment of a shader core130bwith a 4-unit ALU core540and an L-unit elementary function core550, where 1≦L<4. Shader core130bmay also be used for shader core130inFIG. 1. Shader core130bincludes a multiplexer510, a thread scheduler and context register520, an instruction cache522, a constant buffer532, ALU core540, elementary function core550, a load control unit560, register file banks/output buffer570, and a demultiplexer580that operate in similar manner as units410,420,422,432,440,450,460,470and480, respectively, inFIG. 4.

ALU core540may be a single quad ALU or four scalar ALUs. ALU core540couples to thread scheduler520, constant buffer532, and output buffer570via one set of buses. Elementary function core550may be composed of one, two or three (L) elementary function units that can compute an elementary function for either L components of one pixel or one component of L pixels. Elementary function core550couples to thread scheduler520, constant buffer532, and output buffer570via another set of buses. In the embodiment shown inFIG. 5, ALU core540and elementary function core550are implemented separately from one another and are coupled to other units within shader core130bvia separate buses. ALU core540and elementary function core550may then operate on different instructions in parallel. These instructions may be for the same or different graphics applications.

In the embodiment shown inFIG. 5, the number of elementary function units is fewer than the number of ALUs and may be selected based on a tradeoff between cost and performance. In many cases, elementary function core550will be able to keep pace with ALU core540because of the lower average usage of elementary functions. Thread scheduler520appropriately schedules elementary function operations with knowledge that L (instead of four) elementary function units are available for use.

FIG. 6shows a block diagram of an embodiment of a shader core/processor130cwith a 4-unit ALU core640and a 1-unit elementary function core650. Shader core130cmay also be used for shader core130inFIG. 1. Shader core130cincludes a multiplexer610, a thread scheduler and context register620, an instruction cache622, a constant buffer632, ALU core640, elementary function core650, a load control unit660, register file banks/output buffer670, and a demultiplexer680that operate in similar manner as units410,420,422,432,440,450,460,470and480, respectively, inFIG. 4.

ALU core640may be a single quad ALU or four scalar ALUs. ALU core640couples to thread scheduler620, constant buffer632, and output buffer670via a set of buses. Elementary function core650may be composed of a single elementary function unit that can compute an elementary function for one component of one pixel at a time. In the embodiment shown inFIG. 6, elementary function core650couples to load control unit660and output buffer670. This embodiment reduces the number of buses to support separate ALU core640and elementary function core650. This embodiment may also provide other benefits such as more efficient sharing of resources such as register file read/write port, instruction decode, etc.

Instructions for elementary functions (or EF instructions) may be generated in an appropriate manner given the design as well as the placement of elementary function core650within shader core130c. If the number of EF units is equal to the number of ALU units (e.g., as shown inFIG. 4) and if the EF units have the same pipeline latency as the ALU units, then the EF instructions may be treated as ALU instructions with predictable pipeline delay. However, uneven implementations of ALU core640and elementary function core650may result in uneven throughput. Thus, in an embodiment, shader core130ctreats elementary function core650as a load resource and processes EF instructions in similar manner and with the same synchronization as, e.g., a texture load or a memory load. For example, a shader compiler may compile EF instructions as instructions related to texture load instead of as ALU instructions, which may be the case in the embodiments shown inFIGS. 4 and 5.

The shader compiler may include synchronization (sync) bits810in instructions800as appropriate.FIG. 3Cshows an example instruction800with synchronization bits810. A sync bit810may indicate that the current instruction800which contains the sync bit810has data dependency with one or more previous instructions800, which may have unpredictable delay or latency. The unpredictable latency may be due to several sources. First, unpredictable latency of texture load or memory load may result from unpredictable execution conditions such as a cache hit/miss, memory access competence, memory access sequence, etc. Second, unpredictable latency may be caused by uneven implementations of the ALU core and the elementary function core.FIG. 3Dis an example illustration of latencies of an ALU and an elementary function unit. Latency820illustrates an example of the latency of an ALU, and latency830illustrates an example of the latency of an elementary function unit, which is different than the latency of an ALU, e.g., latency820. AlthoughFIG. 3Dillustrates that latency820is less than latency830, aspects of this disclosure should not be considered as limited to the example ofFIG. 3D. The shader compiler may insert sync bits810in instructions800that have data dependency with previous EF instructions, which may have unpredictable delay. These sync bits810ensure that the instructions800follow their dependent EF instructions and hence operate on the proper data.

In the embodiment shown inFIG. 6, thread scheduler620may generate elementary function requests that may share a bus with data load requests. This shared bus may comprise the bus from thread scheduler620to load control unit660. However, elementary function core650may execute in parallel with load instructions in load control unit660. In another embodiment, elementary function core650is coupled directly to thread scheduler620via a dedicated bus, e.g., as shown inFIG. 5. In this embodiment, elementary function requests and data load requests may use separate buses. In both embodiments, thread scheduler620, ALU core640, elementary function core650, and load control unit660may operate in parallel on different threads for improved performance.

FIGS. 4 through 6show specific embodiments of shader cores130a,130band130c. Other variations of shader cores130a,130band130care also possible. For example, elementary function core450inFIG. 4may include fewer than four elementary function units. As another example, elementary function core650inFIG. 6may include more than one elementary function unit, e.g., two elementary function units.

In general, a shader core may include any number of processing, control and memory units, which may be arranged in any manner. These units may also be referred to by other names. For example, a load control unit may also be called an input/output (I/O) interface unit. In some embodiments, a shader core may include fewer elementary function units than ALUs to reduce cost with little degradation in performance. In other embodiments, a shader core may include separate ALU core and elementary function core that can operate on different instructions for the same or different graphics applications in parallel. The ALUs and elementary function units may be implemented with various designs known in the art. A shader core may also interface with external units via synchronous and/or asynchronous interfaces.

The graphics processors and shader cores described herein may be used for wireless communication, computing, networking, personal electronics, etc. An exemplary use of a graphics processor for wireless communication is described below.

FIG. 7shows a block diagram of an embodiment of a wireless device700in a wireless communication system. Wireless device700may be a cellular phone, a terminal, a handset, a personal digital assistant (PDA), or some other device. The wireless communication system may be a Code Division Multiple Access (CDMA) system, a Global System for Mobile Communications (GSM) system, or some other system.

Wireless device700is capable of providing bi-directional communication via a receive path and a transmit path. On the receive path, signals transmitted by base stations are received by an antenna712and provided to a receiver (RCVR)714. Receiver714conditions and digitizes the received signal and provides samples to a digital section720for further processing. On the transmit path, a transmitter (TMTR)716receives data to be transmitted from digital section720, processes and conditions the data, and generates a modulated signal, which is transmitted via antenna712to the base stations.

Digital section720includes various processing and interface units such as, for example, a modem processor722, a video processor724, an application processor726, a display processor728, a controller/processor730, a graphics processor740, and an external bus interface (EBI)760. Modem processor722performs processing for data transmission and reception (e.g., encoding, modulation, demodulation, and decoding). Video processor724performs processing on video content (e.g., still images, moving videos, and moving texts) for video applications such as camcorder, video playback, and video conferencing. Application processor726performs processing for various applications such as multi-way calls, web browsing, media player, and user interface. Display processor728performs processing to facilitate the display of videos, graphics, and texts on a display unit780. Controller/processor730may direct the operation of various processing and interface units within digital section720.

Graphics processor740performs processing for graphics applications and may be implemented as described above. For example, graphics processor740may include shader core/processor130and texture engine140inFIG. 1. A cache memory system750stores data and/or instructions for graphics processor740. Cache memory system750may be implemented with (1) configurable caches that may be assigned to different engines within graphics processor740and/or (2) dedicated caches that are assigned to specific engines. EBI760facilitates transfer of data between digital section720(e.g., the caches) and main memory770.

Digital section720may be implemented with one or more digital signal processors (DSPs), micro-processors, reduced instruction set computers (RISCs), etc. Digital section720may also be fabricated on one or more application specific integrated circuits (ASICs) or some other type of integrated circuits (ICs).

The graphics processors and shader cores/processors described herein may be implemented in various hardware units. For example, the graphics systems and shader cores/processors may be implemented in ASICs, digital signal processors (DSPs), digital signal processing device (DSPDs), programmable logic devices (PLDs), field programmable gate array (FPGAs), processors, controllers, micro-controllers, microprocessors, and other electronic units.

Certain portions of the graphics processors may be implemented in firmware and/or software. For example, the thread scheduler and/or load control unit may be implemented with firmware and/or software modules (e.g., procedures, functions, and so on) that perform the functions described herein. The firmware and/or software codes may be stored in a memory (e.g., memory750or770inFIG. 7) and executed by a processor (e.g., processor730). The memory may be implemented within the processor or external to the processor.