DE102013017639B4 - Caching of adaptively sized cache tiles in a unified L2 cache with surface compression - Google Patents

Abstract

A method for adaptively sizing cache tiles in a graphics system, the method comprising:setting a cache tile size associated with a first cache tile to a first size; based on a first rendering configuration that includes a plurality of first rendering targets, the first cache tile being a screen space tile and divided into a plurality of raster tiles, the size of each raster tile being based on the cache tile size,detecting a change from a first rendering target configuration , to a second rendering target configuration comprising a plurality of second rendering targets; andsetting the cache tile size to a second size, comprising the steps of:calculating the cache space occupied by the cache tile,calculating a first number of bytes per pixel for the second rendering target configuration,applying a surface compression factor to the first number of bytes to calculate a second number of bytes consumed per compressed pixel;determining the second size of the cache tile size based on the second number of bytes.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to United States Provisional Patent Application Serial No. 61/719,271 filed October 26, 2012, entitled "An Approach to Tile Caching." The subject matter of this related application is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

field of invention

Embodiments of the present invention relate generally to graphics processing and more particularly to caching of adaptively sized cache tiles in a unified L2 cache.

Description of the prior art

In some graphics subsystems, a tiling architecture is implemented for rendering graphics images, wherein one or more rendering targets, such as a block buffer, are divided into screen-space subdivisions called tiles. In such a tile architecture, the graphics subsystem reorders work such that the work associated with a particular tile resides in an on-chip cache for a longer time than would be the case with an architecture that does not reorder work in this manner. This rearrangement helps improve memory bandwidth compared to a non-tile architecture.

Typically, the set of imaging targets will change over time as the imaging progresses. For example, in a first pass, a first configuration of imaging targets could be applied to partially render the image. In a second pass, a second configuration of imaging targets could be used to create the image. In a third pass, a third set of rendering targets could be used to ultimately finish rendering the image. During the rendering process, the computer graphics subsystem could use up to 50 or more different rendering target configurations to generate the final image. Each different configuration of rendering targets consumes a different amount of memory. To increase the likelihood of work remaining in the on-chip cache, tiles are typically sized to accommodate the most complex configuration of rendering targets used during rendering. As a result, the tiles are sized to accommodate all of the various rendering target configurations used during generation of the final image - from the most complex to the least complex rendering target configuration.

A disadvantage of the above approach is that tiles are inefficiently sized for less complex configurations of rendering targets. Among other things, less complex rendering target configurations require the smaller tile size required for more complex rendering target configurations so that work remains available in the cache during the rendering process. A smaller tile size requires more tiles to cover full screen space compared to a larger tile size, which requires fewer tiles to cover the same screen space. The smaller tile size results in increased computational overhead, as computational requirements increase as the number of tiles increases. As a result, computational power is wasted on less complex configurations of imaging targets. Wittenbrink C.M. et al give in "Fermi GF100 GPU architecture" Micro, IEEE, 2011, Vol 31(2). 50-59 an overview of the Fermi GPU architecture. In "Decoupled deferred shading for hardware rasterization", Proceedings of the ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games, ACM, 2012, pp. 143-150, Liktor G. et al describe a method for generating a geometry in which shading is independent be saved from visibility. Hsiao, C.C: et al in "A hierarchical primitive lists structure for tile-based rendering", Computational Science and Engineering, 2009, CSE'09, International Conference on IEEE, 2009, S 408-413 shows a tile-based rendering which a hierarchical list used by basic elements.

As the foregoing indicates, what is needed in the art is a technique for more efficient use of cache memory in a graphics subsystem employing a tile architecture in which cache tiles can be easily resized.

OVERVIEW OF THE INVENTION

An embodiment of the present invention provides a method for adaptive dimming sioning of cache tiles in a graphics system according to claim 1. The method includes, among other things, setting a cache tile size associated with a first cache tile to a first size. The method further includes detecting a change from a first rendering target configuration that includes a set of rendering targets to a second rendering target configuration that includes a second set of rendering targets. The method further includes setting the cache tile size to a second size based on the second rendering target configuration.

An advantage of the disclosed approach is that the cache tile size is adaptively sized based on a rendering target configuration and a cache configuration. Smaller cache tile sizes are used for more complex rendering target configurations, while larger cache tile sizes are used for less complex rendering target configurations. By adaptively sizing the cache tiles based on the rendering target configuration, less computing power is required to process the cache tiles, resulting in more efficient processor utilization and lower performance requirements.

character list

• 1 ist eine Blockansicht, die ein Computersystem darstellt, das ausgebildet ist, einen oder mehrere Aspekte der vorliegenden Erfindung zu realisieren;
• 2 ist eine Blockansicht einer Parallelverarbeitungseinheit, die in dem Parallelverarbeitungssubsystem aus 1 gemäß einer Ausführungsform der vorliegenden Erfindung enthalten ist;
• 3A ist eine Blockansicht eines allgemeinen Verarbeitungs-Clusters, der in der Parallelverarbeitungseinheit aus 2 gemäß einer Ausführungsform der vorliegenden Erfindung enthalten ist;
• 3B ist eine Konzeptansicht einer Grafikverarbeitungs-Pipeline, die in der Parallelverarbeitungseinheit aus 2 gemäß einer Ausführungsform der vorliegenden Erfindung realisiert werden kann;
• 4 ist eine Konzeptansicht einer Cache-Kachel, für die die Grafikverarbeitungs-Pipeline aus 3B ausgebildet ist, diese zu erzeugen und zu verarbeiten gemäß einer Ausführungsform der vorliegenden Erfindung;
• 5 zeigt eine Gruppe aus Bilderzeugungszielen, wie sie in einem oder mehreren der DRAMs aus 2 gemäß einer Ausführungsform der vorliegenden Erfindung gespeichert sind;
• 6 zeigt eine Reihe von Bilderzeugungszielkonfigurationen, die mit der Bilderzeugung eines Computergrafikbildes gemäß einer Ausführungsform der vorliegenden Erfindung verknüpft ist; und
• 7 gibt ein Flussdiagramm von Verfahrensschritten an, um Cache-Kacheln gemäß einer Ausführungsform der vorliegenden Erfindung adaptiv zu dimensionieren.

In order to indicate the manner in which the above features of the present invention are to be understood in detail, a more detailed description of the invention, briefly summarized above, is given with reference to embodiments, some of which are illustrated in the accompanying drawings are. However, it should be noted that the attached drawings represent only typical embodiments of this invention and therefore should not be considered as limiting the scope thereof, since the invention admits of other equally effective embodiments.

• 1 Figure 12 is a block diagram illustrating a computer system configured to implement one or more aspects of the present invention;
• 2 Fig. 12 is a block diagram of a parallel processing unit included in the parallel processing subsystem 1 according to an embodiment of the present invention;
• 3A Figure 12 is a block diagram of a general processing cluster implemented in the parallel processing unit 2 according to an embodiment of the present invention;
• 3B Fig. 12 is a conceptual view of a graphics processing pipeline executed in the parallel processing unit 2 can be implemented according to an embodiment of the present invention;
• 4 Figure 12 is a conceptual view of a cache tile for which the graphics processing pipeline is drawn 3B configured to generate and process them in accordance with an embodiment of the present invention;
• 5 Figure 12 shows a set of imaging targets as defined in one or more of the DRAMs 2 stored in accordance with an embodiment of the present invention;
• 6 Figure 12 shows a series of rendering target configurations associated with rendering a computer graphics image in accordance with an embodiment of the present invention; and
• 7 Figure 12 provides a flowchart of method steps to adaptively size cache tiles in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

In the following description, various specific details are set forth in order to provide a more thorough understanding of the present invention. However, those skilled in the art will recognize that the present invention may be practiced without one or more of these specific details.

system overview

1 1 is a block diagram showing a computer system 100 configured to implement one or more aspects of the present invention. As shown, the computer system 100 includes, without limitation, a central processing unit (CPU) 102 and a system memory 104 coupled to a parallel processing subsystem 112 via a memory bridge 105 and a communications path 113 . The memory bridge 105 is further connected to an I/O (input/output) bridge 107 via a communication path 106 and the I/O bridge 107 is in turn connected to a switch 116 .

In operation, I/O bridge 107 is configured to receive user input information from input devices 108, such as a keyboard or mouse, and to pass the input information to CPU 102 via communication path 106 and memory bridge 105 for processing. Switch 116 is designed to provide connections between I/O bridge 107 and other components of the computer systems 100, such as a network adapter 118 and various add-on cards 120 and 121.

As further shown, I/O bridge 107 is connected to a system disk 114, which may be configured to store content and applications and data for use by CPU 102 and parallel processing subsystem 112. In general, the system disk 114 provides non-volatile storage space for applications and data and may include fixed or removable hard drives, hard drives, and CD (Compact Disk Read Only Memory), DVD (Digital Versatility Disk ROM), Blu- ray, HD-DVD (high definition DVD) or other magnetic, optical or electronic storage devices. Finally, although not explicitly shown, other components such as a universal serial bus or other port connections, compact disk drives, digital versatile disk drives, movie recorders, and the like may be connected to I/O bridge 107 as well.

In various embodiments, memory bridge 105 may be a north bridge chip and I/O bridge 107 may be a south bridge chip. Furthermore, communication paths 106 and 113, as well as other communication paths within computer system 100, may be implemented using any technically suitable protocol, including without limitation: AGP (Accelerated Graphics Port), HyperTransport, or other bus or point-to-point communication protocols that are known in the prior art.

In some embodiments, the parallel processing subsystem 112 includes a graphics subsystem that provides pixels to a display device 110, which may be any conventional cathode ray tube, liquid crystal display, light emitting diode display, or the like. In such embodiments, parallel processing subsystem 112 includes circuitry optimized for graphics or video processing, including, for example, video output circuitry. As below in 2 As described in more detail, such circuitry may be included in one or more parallel processing units (PPUs) included in parallel processing subsystem 112 . In other embodiments, parallel processing subsystem 112 includes circuitry optimized for general purpose and/or computational processing. Again, such circuitry may be included in one or more PPUs included in parallel processing subsystem 112 configured to perform such general purpose operations and/or computations. In still other embodiments, the one or more PPUs included in parallel processing subsystem 112 may be configured to perform operations for graphics processing, general purpose processing, and computational processing. System memory 104 includes at least one device driver 103 configured to manage the processing operations of the one or more PPUs in parallel processing subsystem 112 .

In various embodiments, the parallel processing subsystem 112 may reside in one or more of the other elements 1 be integrated to form a single system. For example, the parallel processing subsystem 112 may be integrated with the CPU 102 and other interconnect circuitry on a single chip to form a system on a chip (SoC).

It should be noted that the system shown herein is illustrative in nature and that various variations and modifications are possible. The interconnect topology, including the number and placement of bridges, the number of CPUs 102, and the number of parallel processing subsystems 112 can be modified as needed. For example, in some embodiments, system memory 104 could be connected to CPU 102 directly instead of through memory bridge 105 , and other devices could communicate with system memory 104 through memory bridge 105 and CPU 102 . In other alternative topologies, the parallel processing subsystem 112 may be connected to the I/O bridge 107 or directly to the CPU 102 instead of through the memory bridge 105. In still other embodiments, I/O bridge 107 and memory bridge 105 may be integrated into a single chip rather than existing as one or more discrete components. Finally, in certain embodiments, one or more of the 1 components shown may not be present. For example, switch 116 could be omitted and network adapter 118 and add-in cards 120, 121 connected directly to I/O bridge 107.

2 12 is a block diagram of a parallel processing unit (PPU) 202 included in the parallel processing subsystem 112. FIG 1 according to an embodiment of the present invention. although 2 represents a single PPU 202, as noted above, the parallel processing subsystem 112 may include any number of PPUs 202. As shown, the PPU 202 is associated with a local parallel processing (PP) memory cher 204 connected. The PPU 202 and PP memory 204 may be implemented using one or more integrated circuit devices, such as programmable processors, application specific integrated circuits (ASIC), or memory devices, or in any other technically feasible manner.

In some embodiments, the PPU 202 includes a graphics processing unit (GPU) that may be configured to implement a graphics generation pipeline to perform various operations related to the generation of pixel data based on graphics data generated by the CPU 102 and/or the system memory 104. When processing graphics data, the PP memory 204 may be used as a graphics memory, storing one or more conventional block buffers and also one or more other rendering targets as needed. Among other things, PP memory 204 may be used to store and update pixel data and ultimately pass final pixel data or display blocks to display device 110 for rendering. In some embodiments, PPU 202 may be configured for general purpose processing and arithmetic operations.

During operation, CPU 102 is the master processor of computer system 100, controlling and coordinating the operation of other system components. In particular, the CPU 102 issues commands that control the operation of the PPU 202. In some embodiments, the CPU 102 writes a stream of instructions for the PPU 202 into a data structure (in 1 or 2 not explicitly shown), which may be in system memory 104, PP memory 204, or some other memory location accessible to both CPU 102 and PPU 202. A pointer to the data structure is written to a shift buffer to initiate processing of the stream of instructions in the data structure. The PPU 202 reads instruction streams from the shift buffer and then executes instructions asynchronously relative to the CPU 102 operation. In embodiments where multiple shift buffers are created, priorities for execution for each shift buffer may be specified by an application program via device driver 103 to control the scheduling of the different shift buffers.

As further shown, PPU 202 includes an I/O (input/output) unit 205 that communicates with the rest of computer system 100 via communication path 113 and memory bridge 105 . I/O unit 205 generates packets (or other signals) for transmission on communication path 113 and also receives any incoming packets (or other signals) from communication path 113 and directs the incoming packets to appropriate components of PPU 202. For example, commands that are related to processing tasks are routed to a main interface 206 , while commands that are related to memory operations (e.g., reading from and writing to PP memory 204 ) are sent to an intersection unit 210 . The main interface 206 reads each shift buffer and sends the command stream stored in the shift buffer to a front end 212.

As previously in connection with 1 is mentioned, the connection of the PPU 202 to the rest of the computer system 100 may be different. In some embodiments, parallel processing subsystem 112, which includes at least one PPU 202, is implemented as an add-on card that can be inserted into an expansion slot of computer system 100. In other embodiments, PPU 202 may be integrated on a single chip with a bus bridge, such as memory bridge 105 or I/O bridge 107. In still other embodiments, some or all elements of PPU 202 may be included along with CPU 102 in a single integrated circuit or system on a chip (SoC).

During operation, front end 212 sends processing tasks received from main interface 206 to a work distribution unit (not shown) in task/work unit 207. The work distribution unit receives pointers to processing tasks, encoded as task metadata (TMD) and stored in memory are saved. The pointers to the TMD are contained in an instruction stream stored as a push buffer and received by the front end unit 212 from the main interface 206 . Processing tasks, which may be encoded as TMD, contain indices associated with the data to be processed, as well as state parameters and instructions that define how the data is to be processed. For example, the state parameters and the instructions can specify the program to be executed on the data. Task/work unit 207 receives tasks from front end 212 and ensures that GPCs 208 are configured to a valid state before initiating the processing task specified by each set of TMD. A priority can be specified for each set of TMD, which is used to schedule the execution of processing tasks. Processing tasks can also be derived from the processing Cluster array 230 are received. Optionally, the TMD may include a parameter that controls whether the TMD is added to the head or end of a list of processing tasks (or a list of pointers to the processing tasks), thereby providing another level of control in addition to execution priority.

The PPU 202 advantageously implements a highly parallel processing architecture based on a processing cluster array 230 comprising a set of C general processing clusters (GPCs) 208, where C≧1. Each GPC 208 is capable of executing a large number (e.g., hundreds or thousands) of threads simultaneously, with each thread being an instance of a program. In various applications, different GPCs 208 may be dedicated to different types of programs or to perform different types of calculations. Allocation of GPCs 208 may vary depending on the workload that arises for each type of program or computation.

A memory interface 214 includes a set of D partition units 215, where D≥1. Each partition unit 215 is connected to one or more dynamic random access memory (DRAM) 220 residing in PP memory 204 . In one embodiment, the number of partition units 215 is equal to the number of DRAMs 220 and each partition unit 215 is connected to a different DRAM 220. In other embodiments, the number of partition units 215 differs from the number of DRAMs 220. Those skilled in the art will recognize that a DRAM 220 may be substituted for any other technically suitable memory device. In operation, various rendering targets, such as texture maps and block buffers, can be stored across the DRAMs 220, allowing the partition units 215 to write portions of each rendering target in parallel to efficiently utilize the available PP memory 204 bandwidth.

A given GPC 208 may process data to be written to one or more of the DRAMs 220 in PP memory 204 . The crossover unit 210 is configured to route the output of each GPC 208 to the input of a partition unit 215 or to another GPC 208 for further processing. The GPCs 208 communicate with the memory interface 214 via the crossover unit 210 to read from or write to various DRAMs 220 . In one embodiment, the crossover unit 210 has a connection to the I/O unit 205 in addition to a connection to the PP memory 204 via the memory interface 214, enabling the processing cores in the different GPCs 208 to communicate with the system memory 104 or to connect to other memory that is not local to the PPU 202. In the embodiment off 2 the crossover unit 210 is directly connected to the I/O unit 205. In various embodiments, the intersection unit 210 may use virtual channels to separate traffic flows between the GPCs 208 and the partition units 215.

Again, the GPCs 208 may be programmed to perform processing tasks related to a wide variety of applications including, without limitation, linear and non-linear data transformations, filtering of video and/or audio data, modeling operations ( e.g. the application of physical laws to determine position, speed and other attributes of objects), imaging operations (e.g. programs for tessellation shading, vertex shading, geometry shading and/or pixel/fragment shading), general computational methods, etc. Im In operation, the PPU 202 is configured to transfer data from the system memory 104 and/or the PP memory 204 to one or more on-chip memory devices, process the data, and write result data back to the system memory 104 and/or the PP memory 204 . The resultant data can then be accessed by other system components, including CPU 102, another PPU 202 within parallel processing subsystem 112, or another parallel processing subsystem 112 in computer system 100.

As previously indicated, any number of PPUs 202 may be included in the parallel processing subsystem 112. For example, multiple PPUs 202 can be provided in a single option card, or multiple option cards can be connected to the communication path 113, or one or more of the PPUs 202 can be integrated in a bridge chip. The PPUs 202 in a multi-PPU system may be identical to or different from one another. For example, different PPUs 202 may have different numbers of processing cores and/or different sizes of PP memory 204 . In embodiments where there are multiple PPUs 202, those PPUs can operate in parallel to process data at a higher throughput than would be possible with a single PPU 202. Systems incorporating one or more PPUs 202 can be in a variety of configurations Networks and form factors can be implemented, including, without limitation, desktop computers, mobile computers, handheld personal computers or other handheld devices, service provider computers, workstations, game consoles, embedded systems, and the like.

3A FIG. 12 is a block diagram of a GPC 208 installed in the PPU 202. FIG 2 according to an embodiment of the present invention. In operation, the GPC 208 may be configured to execute a large number of threads in parallel to perform graphics, general purpose processing, and/or computational operations. As used herein, a "thread" refers to an instance of a specific program that is executed on a specific set of input data. In some embodiments, single-instruction, multiple-data (SIMD) instruction issue techniques are employed to support parallel execution of a large number of threads without providing multiple independent instruction units. In other embodiments, single-instruction, multiple-thread (SIMT) techniques are employed to support parallel execution of a large number of commonly synchronized threads, with a common instruction unit configured to issue instructions to a group of processing units within the GPC 208 . Unlike a SIMD execution regime, in which all processing units typically execute identical instructions, SIMT execution allows different threads to more efficiently follow divergent execution paths through a given program. Those skilled in the art will recognize that a SIMD processing regime is a functional subset of a SIMT processing regime.

The operation of the GPC 208 is controlled by a pipeline manager 305 which dispatches processing tasks it receives from a work distribution unit (not shown) in the task/work unit 207 to one or more stream multiprocessors (SM) 310 . The pipeline manager 305 may also be configured to control a work distribution intersection unit 330 by specifying destinations for processed data output from the SMs 310 .

In one embodiment, GPC 208 includes a set of M SM 310, where M≧1. Each SM 310 also includes a set of functional execution units (not shown), such as execution units and load-store units. The processing of operations specific to any of the functional execution units may be pipelined or executed in parallel, allowing a new instruction to be issued for execution before execution of a previous instruction completes. Any combination of functional execution units can be provided in a given SM 310 . In various embodiments, the function execution units may be configured to support a variety of different operations, including integer and floating point arithmetic (e.g., addition and multiplication), comparison operations, Boolean operations (AND, OR, EXCLUSIVE OR), bit shifting, and computation of various algebraic functions (e.g., plane interpolation, trigonometric, exponential, and logarithmic functions, etc.). Advantageously, the same function execution unit can be designed to execute different operations.

In operation, each SM 310 is configured to process one or more thread groups. As used herein, a "thread group" or "bowl" means a group of threads concurrently executing the same program on different input data, with a single thread of the group being assigned to a different execution unit within an SM 310 . A thread group may contain fewer threads than the number of execution units within SM 310, in which case some of the execution units may be idle during certain cycles when that thread group is being processed. A thread group may also contain more threads than the number of execution units within SM 310, in which case processing may span consecutive clock cycles. Since each SM 310 can support up to G thread groups simultaneously, it follows that up to G*M thread groups can be executed in the GPC 208 simultaneously.

Furthermore, multiple related thread groups may be active in an SM 310 at the same time (in different phases of execution). This collection of strand groups is referred to herein as a "cooperative strand array" ("CTA") or "strand array". The size of a particular CTA is equal to m*k, where k is the number of concurrently executing threads in a thread group, which is typically an integer multiple of the number of execution units within the SM 310, and m is the number of thread groups that are concurrently executing in are active on the SM 310.

Although in 3A not shown, each SM 310 contains a level one (L1) cache or uses space in a corresponding L1 cache external to the SM 310 to perform, among other things, load and store operations supported by the execution units. Each SM 310 also has access to level two (L2) cache memory (not shown) shared by all GPCs 208 in PPU 202 . The L2 caches can be used to exchange data between threads. Finally, SM 310 may also have access to off-chip "global" memory, which may include PP memory 204 and/or system memory 104 . It should also be noted that any memory external to the PPU 202 can be used as global memory. As also in 3A As shown, a level one-point-five (L1.5) cache memory may be used in the GPC 208 and may be configured to receive and hold data requested by the SM 310 from the memory via the memory interface 214 . Such data can include, without limitation, commands, uniform data, and constant data. Advantageously, in embodiments having multiple SM 310 within GPC 208 , SM 310 may share common instructions and data cached in L1.5 cache 325 .

Each GPC 208 may have an associated memory management unit (MMU) 320 configured to map virtual addresses to physical addresses. In various embodiments, MMU 320 may reside in GPC 208 or may reside in memory interface 214 . The MMU 320 contains a set of page table entries (PTE) used to map a virtual address to a physical address of a tile or memory page and optionally a cache line index. The MMU 320 may include address translation lookaside buffers (TLB) or caches, which may reside in the SM 310, in one or more L1 caches, or in the GPC 208.

In graphics and computing applications, the GPC 208 may be configured such that each SM 310 connects to a texture unit 315 for reading texture mapping requests, such as determining texture sample positions, reading texture data, and filtering texture data.

In operation, each SM 310 sends a task to the work distribution crossbar 330 to direct the processed task to another GPC 208 for further processing or to store the processed task in an L2 cache (not shown), parallel processing memory 204, or system memory 104 via the crossing unit 210 to store. Furthermore, a pre-raster operations (pre-ROP) unit 325 is configured to receive data from the SM 310, supply data to one or more raster operations (ROP) units in the partition units 215, perform optimizations for color mixing, pixel color data organize and perform address translations.

It should be noted that the core architecture described herein is illustrative in nature and is subject to change and modification. Any number of processing units, such as SM 310, texture units 315, or pre-ROP units 325, may be included in GPC 208, among others. As further above in connection with 2 patent, the PPU 202 may include any number of GPCs 208 configured to be functionally similar to one another such that execution behavior is not dependent on which GPC 208 is assigned which particular processing task. Furthermore, each GPC 208 operates independently of the other GPCs 208 in the PPU 202 to perform tasks for one or more application programs. In view of the foregoing, those skilled in the art will recognize that the 1-3A architecture described is in no way limiting to the scope of the present invention.

Graphics pipeline architecture

3B FIG. 3 is a conceptual view of a graphics processing pipeline 350 running in the PPU 202. FIG 2 can be implemented according to an embodiment of the present invention. As shown, graphics processing pipeline 350 includes, without limitation, a primitive (PD) dispatch unit 355; a vertex attribute fetch unit (VAF) 360; a vertex, tessellation, geometry processing unit (VTG) 365; a viewport scaling, selecting and clipping unit (VPC) 370; a tiling unit 375, a setup unit (setup) 380, a raster unit (raster) 385; a fragment processing unit, also referred to as a pixel shader unit (PS) 390, and a raster operations unit (ROP) 395.

The PD 355 collects vertex data associated with higher-order surfaces, graphic primitives, and the like from the front area 212 and sends the vertex data to the VAF 360.

The VAF 360 retrieves vertex attributes associated with each of the incoming vertices from shared memory and stores the vertex data in shared memory along with the associated vertex attributes.

The VTG 365 is a programmable execution unit designed to run vertex shading programs, tessellation programs, and run geometry programs. These programs process vertex data and vertex attributes received from the VAF 360 and generate graphics primitives, such as color values, surface normal vectors, and transparency values at each vertex for the graphics primitives for further processing within the graphics processing pipeline 350. Although not explicitly shown, in some embodiments the VTG 365 may include one or more of the following units: a vertex processing unit, a tessellation initialization processing unit, a task generation unit, a task distribution unit, a topology generation unit, a tessellation processing unit, and a geometry processing unit.

The vertex processing unit is a programmable execution unit configured to process vertex shader programs, lighting, and transformation of vertex data as specified by the vertex shader programs. For example, the vertex processing unit may be programmed to convert the vertex data from an object-based coordinate representation (object space) to an alternative basis coordinate system, such as world space or normalized device coordinate (NDC) space. The vertex processing unit can read vertex data and vertex attributes stored in a shared memory by the VAF and process the vertex data and the vertex attributes. The vertex processing unit 415 stores processed vertices in shared memory.

The tessellation initialization processing unit is a programmable execution unit configured to execute tessellation initialization shader programs. The tessellation initialization processing unit processes vertices generated by the vertex processing unit and generates graphics primitives known as patch regions. The tessellation initialization processing unit also creates various attributes for patch areas. The tessellation initialization processing unit then stores the blob area data and blob area attributes in the shared memory. In some embodiments, the tessellation initialization shader may be called a skin shade or a tessellation control shade.

The task generation unit retrieves data and attributes for vertices and blob areas from shared memory. The task generation unit generates tasks to process the vertices and patch areas for processing by later stages in the graphics processing pipeline 350.

The task distribution unit redistributes the tasks generated by the task generation unit. The tasks generated by the various instances of the vertex shader and the tessellation initializer can vary significantly from one graphics processing pipeline 350 to another. The task distribution unit redistributes these tasks such that each graphics processing pipeline 350 has approximately the same workload during later pipeline stages.

The topology generation unit retrieves tasks distributed from the task management unit. The topology generation unit indexes the vertices, including vertices associated with patch regions, and computes (U,V) coordinates for tessellation vertices and the indices connecting the tessellated vertices to form graphical primitives. The topology generation unit then stores the indexed vertices in the shared memory.

The tessellation processing unit is a programmable execution unit configured to execute tessellation shading programs. The tessellation processing unit reads input data from and writes output data to the shared memory. This output data in shared memory is passed to the next shading stage, i.e. geometry processing unit 445, as input data. In some embodiments, the tessellation shader may be referred to as a region shader or a tessellation score shader.

The geometry processing unit is a programmable execution unit configured to execute geometry shading programs, thereby transforming graphics primitives. Vertices are grouped to form graphics primitives for processing, where graphics primitives include triangles, line segments, points, and the like. For example, the geometry processing unit may be programmed to partition the graphics primitives into one or more new graphics primitives and to calculate parameters, such as coefficients for a plane equation, used to rasterize the new graphics primitives.

The geometry processing unit sends the parameters and the vertices that the new graphi indicate geometric primitives to the VPC 370. The geometry processing unit may read data stored in the shared memory for use in processing the geometry data. The VPC 370 performs cropping, selection, perspective corrections, and viewport transformation to determine which graphics primitives are potentially viewable and which graphics primitives are potentially not viewable in the final generated image. The VPC 370 then sends the processed graphics primitives to the tiling unit 375.

The tiling unit 375 is a graphical primitive sorting unit that lies between a world-space pipeline 252 and a screen-space pipeline 354, as further described herein. Graphics primitives are processed in the world space pipeline 352 and then passed to the tiling unit 375 . Screen space is divided into cache tiles, with each cache tile being associated with a region of screen space. For each graphics primitive, the tiling unit 375 determines the set of cache tiles that have an intersection with the graphics primitive, a process referred to as "tiling." After a certain number of graphical primitives are tiled, the tiling unit 375 processes the graphical primitives at the cache tile level, sending graphical primitives associated with a particular cache tile to the setup unit 380 . The crossing unit 375 sends graphics primitives to the setup unit 380, passing a single cache tile at a time. Graphics primitives that intersect multiple cache tiles are typically processed once in the world-space pipeline 352, but are then committed to the screen-space pipeline 354 multiple times.

Such a technique improves cache locality during processing in the screen-space pipeline 354, where multiple memory operations associated with a first cache tile access one region of the L2 cache, or another technically feasible cache memory maintained during screen-space processing of the first cache tile. Once the graphics primitives associated with the first cache tile are processed by the screen-space pipeline 354, the portion of the L2 cache associated with the first cache tile may be flushed and the tiling unit may be cleaned transfer graphical primitives associated with a second cache tile. Multiple memory operations associated with a second cache tile can then access the region of L2 caches preserved during screen-space processing of the second cache tile. As a result, overall memory traffic to the L2 caches and rendering targets can be reduced. In some embodiments, the world-space computation is performed once for a given graphics primitive, regardless of the number of cache tiles in screen-space that intersect the graphics primitive.

The setup unit 380 receives vertex data from the VPC 370 via the crossing unit 375 and calculates parameters associated with the graphics primitive, including but not limited to edge equations, sub-level equations, and low-level equations. The setup unit 380 then sends the processed graphics primitives to the rasterization unit 385.

The rasterizer 385 scan converts the new graphics primitives and sends fragments and coverage data to the pixel shader 390. Furthermore, the rasterizer 385 may be configured to perform z-selection and other z-based optimizations.

The pixel shader unit 390 is a programmable execution unit configured to execute fragment shader programs that transforms fragments obtained from the rasterizer unit 385 as specified by the fragment shader programs. Fragment shader programs can shade fragments at pixel-level resolution, and such shader programs may be called pixel shader programs. Alternatively, fragment shader programs can shade at sample-level resolution, where each pixel contains multiple samples, and where each sample represents a sub-area of a pixel. Alternatively, fragment shaders can shade fragments at any other technically feasible resolution, depending on the programmed sampling rate.

In various embodiments, fragment processing unit 460 may be programmed to perform operations such as perspective correction, texture mapping, shading, blending, and the like to generate shaded fragments that are then sent to ROP 395 . The pixel shader 300 can Read data stored in shared memory.

The ROP 395 is a processing unit that performs raster operations such as stencil, z-test, blending, and the like, and passes the pixel data as processed graphics data for storage in graphics memory via memory interface 214, the graphics memory typically structured as one or more rendering targets is. The processed graphics data may be stored in graphics memory, parallel processing memory 204, or system memory 104 for display on display device 110 or for further processing by CPU 102 or parallel processing subsystem 112. In some embodiments, the ROP 395 is configured to compress z-data or color data that is written to memory and to decompress z-data or color data that is read from memory. In various embodiments, the ROP 395 may be located in the memory interface 214, in the GPCs 208, in the processing cluster array 230 external to the GPCs, or in a separate unit (not shown) in the PPUs 202.

The graphics processing pipeline may be implemented by one or more processing elements in the PPU 202. For example, one of the SM 310 from 3A be configured to perform the functions of the VTG 365 and/or the pixel shader 390. The functions of the PD 355, VAF 360, VPC 450, tiling unit 375, setup unit 380, rasterizer unit 385, and ROP 395 may also be performed by processing elements within a particular GPC 208 in conjunction with a corresponding partition unit 215. Alternatively, the graphics processing pipeline 350 may be implemented using specific fixed function connectors for one or more of the functions listed above. In various embodiments, the PPU 202 may be configured to implement one or more graphics processing pipelines 350 .

In some embodiments, the graphics processing pipeline 350 can be divided into an image-space pipeline 352 and a screen-space pipeline 354 . The world-space pipeline 352 processes graphical objects in 3D space, in which the position of each graphical object relative to other graphical objects and relative to a 3D coordinate system is known. The screen-space pipeline 354 processes graphical objects that have been projected from the 3D coordinate system onto a 2D planar surface representing the surface of the display device 110 . For example, the world-space pipeline 352 may include pipeline stages in the graphics processing pipeline 350 from the PD 355 to the VPC 370. The screen-space pipeline 354 may include pipelined stages in the graphics processing pipeline 350 from the setup unit 380 to the ROP 395. The tiling unit 375 would occur after the last stage of the world-space pipeline 352, i.e., after the VPC 370. The tiling unit 375 would occur before the first stage of the screen-space pipeline 354, i.e. before the setup unit 380.

In some embodiments, the image-space pipeline 352 can be further divided into an alpha-phase pipeline and a beta-phase pipeline. For example, the alpha phase pipeline may include pipeline stages in the graphics processing pipeline 350 from the PD 355 to the task generation unit. The beta phase pipeline may include pipeline stages in the graphics processing pipeline 350 from the topology generation unit to the VPC 370 . Graphics processing pipeline 350 performs a first set of operations during processing in the alpha phase pipeline and performs a second set of operations during processing in the beta phase pipeline. As used herein, a group of operations is defined as one or more instructions to be executed by a single thread, by a thread group, or by multiple thread groups acting as a unit.

In a system with multiple graphics processing pipelines 350, the vertex data and vertex attributes associated with a set of graphical objects can be partitioned such that each graphics processing pipeline 350 performs approximately the same amount of workload during alpha has phase. The alpha phase processing can greatly expand the amount of vertex data and vertex attributes, so the amount of vertex data and vertex attributes generated by the task generation unit is significantly larger than the amount of vertex data and vertex attributes generated by the PD 255 and the VAF 360. Furthermore, the task generation engine associated with a single graphics processing pipeline 350 may generate a significantly larger amount of vertex data and vertex attributes than the task generation engine associated with a different graphics processing pipeline 350, even in cases where the two graphics processing pipelines 350 process the same set of attributes at the beginning of the alpha phase pipeline. In such cases, the task distribution engine redistributes the attributes produced by the alpha phase pipeline such that each graphics processing pipeline 350 has approximately the same workload at the start of the beta phase pipeline.

It is further noted that, as used herein, references to shared memory include one or more technically feasible memories, including without limitation local memory shared by the one or more SM 310, or memory accessible via memory interface 214, such as cache memory, parallel processing memory 204, or system memory 104. It should also be noted that, as used herein, references to cache memory include one or more technically feasible ones memory includes, without limitation, an L1 cache, an L1.5 cache, and the L2 caches.

Tiled caching

4 Figure 4 is a conceptual view of a cache tile 410(0) for which the graphics processing pipeline 350 is generated 3B configured to generate and process them in accordance with an embodiment of the present invention. As shown, cache tile 410( 0 ) represents a portion of screen space 400 and is divided into multiple raster tiles 420 .

Screen space 400 represents one or more memory buffers configured to store rendered image data and other data passed from the functional units within graphics processing pipeline 350 . In some embodiments, the one or more buffers are embodied as one or more rendering targets. Screen space represents a buffer memory configured to store the image generated by the graphics processing pipeline. Screen-space 400 may be associated with any number of rendering targets, and each rendering target may be configured to contain any number of tiles independently of other rendering targets. Each field in an imaging target, independent of other fields, is designed to contain any number of bits. Each render target can contain multiple picture elements (pixels), and each pixel can in turn contain multiple samples. In some embodiments, the size of each cache tile may be based on the size and configuration of rendering targets associated with screen space. In operation, when rendering is complete, the pixels in the one or more rendering targets may be sent to a display device to display the rendered image.

For example, a set of render targets for screen-space 400 may include eight render targets. The first rendering target may contain four fields representing colors, including red, green, and blue component colors, and transparency information associated with a corresponding fragment. The second rendering target may contain two fields representing depth information and template information, respectively, associated with the corresponding fragment. The third rendering target may contain three fields representing information about the surface normal vector including an X-axis normal vector and a Y-axis normal vector and a Z-axis normal vector associated with the corresponding fragment. The remaining five rendering targets can be configured to store additional information associated with the corresponding fragment. Such configurations may include: storage for miscellaneous information including, without limitation, 3D position data, diffuse illumination information, and specular illumination information.

Each cache tile 410 represents a portion of screen-space 400. For clarity, only five cache tiles 410(0)-410(4) are in 4 shown. In some embodiments, the cache tiles are arbitrarily sized in X and Y screen space. For example, if a cache tile resides in cache memory that is also used to store other data, then the cache tile may be sized to occupy only a specific area of the cache memory. The size of a cache tile can be based on a number of factors, including: the quantity and configuration of rendering targets associated with screen space 400, the amount of samples per pixel, and whether those are in the cache tile stored data is compressed. In general, a cache tile is sized to increase the likelihood that the cache tile data will be retained in cache memory until all of the graphics primitives associated with the cache tile have been fully processed.

The raster tiles 420 represent a portion of the cache tile 410(0). As shown, cache tile 410(0) includes 16 raster tiles 420(0)-420(15) arranged in an array that is four raster tiles 420 wide and four raster tiles high 420 has. In systems that include multiple GPCs 208, the processing associated with a given cache tile 410(0) may be distributed among the available GPCs 208. In the case shown By way of example, if the 16 raster tiles of cache tile 410(0) are to be processed by many different GPCs 208, then each GPC 208 can be assigned to contain four of the 16 raster tiles 420 in the cache Tile 410(0) processed. In particular, the first GPC 208 may be assigned to process raster tiles 420(0), 420(7), 420(10), and 420(13). The second GPC 208 can be assigned to process raster tiles 420(1), 420(4), 420(11), and 420(14). The third GPC 208 can be assigned to process raster tiles 420(2), 420(5), 420(8), and 420(15). The fourth GPC 208 can then be assigned to process raster tiles 420(3), 420(6), 420(9), and 420(12). In other embodiments, the processing of the different raster tiles in a given cache tile may be divided among the GPCs 208 or other processing units included in the computer system 100 in any technically feasible manner.

Adaptively sized cache tiles

The cache tiles off 4 are sized to accommodate a specific imaging target configuration. A rendering target configuration contains one or more rendering targets, each containing one or more fields. The cache tile size is calculated based on the size of the various fields in the rendering targets of a given rendering target configuration.

5 FIG. 12 shows a set of imaging targets 599 as they reside in one or more of the DRAMs 220. FIG 2 are stored in accordance with an embodiment of the present invention. As shown, the set of render targets 500 includes five separate render targets 510(0)-510(4).

The first render target 510(0) contains four fields representing a first set of color and transparency information associated with a corresponding scan or fragment. As shown, the four fields include a red value 515, a green value 520, a blue value 525, and an alpha or transparency value 530. The red value 515, green value 520, blue value 525, and alpha value 530 each contain a single byte of data. This first rendering target 520(0) may be referred to as C0, indicating that the first rendering target 510(0) contains a first set of color and alpha information.

The second render target 510(1) contains four fields representing a second set of color and transparency information associated with a corresponding scan or fragment. As shown, the four fields include a red 535 value, a green 540 value, a blue 545 value, and an alpha or transparency 550 value. The red 535 value, green 540 value, blue 545 value, and alpha 550 value each contain a single byte of data. This second rendering target 520(1) may be referred to as C1, indicating that the second rendering target 510(1) contains a second set of color and alpha information.

The third render target 510(2) includes two fields representing a first set of depth and template information associated with a corresponding sample or fragment. As shown, the two fields include a z or depth value 555 and a template mask 560. As shown, the z value 555 contains three bytes of data, while the template mask 560 contains a single byte of data. This third rendering target 520(2) may be referred to as Z0, indicating that the third rendering target 510(2) contains a first set of z and template information.

The fourth rendering target 510(3) contains two fields representing a second set of depth and template information associated with a corresponding sample or fragment. As shown, the two fields include a z or depth value 565 and a stencil mask 570. As shown, the z value 565 contains three bytes of data, while the stencil mask 570 contains a single byte of data. This fourth rendering target 520(3) may be referred to as Z1, indicating that the fourth rendering target 510(3) contains a second set of z and template information.

The fifth rendering target 510(4) contains four fields representing information about surface normal vectors associated with a corresponding sample or fragment. As shown, the four fields include an X-axis normal vector 475, a Y-axis normal vector 580, and a Z-axis normal vector 585. In this particular configuration for the fifth rendering target 510(4), the fourth field is an unused field 590. The X-axis normal vector 575, the Y-axis normal vector 580 and the Z-axis normal vector 585 and the unused field 590 each contain 1 byte of data. This fifth rendering target 520(4) may be referred to as N0, indicating that the fifth rendering target 510(4) contains a first set of surface normal information.

As the imaging process progresses, the imaging target configuration changes ration. Each rendering target configuration contains the set of rendering targets used for a particular stage of rendering. The cache tile can be cleared and resized at the boundary between a current rendering target configuration and a new rendering target configuration. In some embodiments, the cache tile is not flushed and resized in cases where the new rendering target configuration is a subset of the current rendering target configuration.

6 FIG. 6 shows a series of image generation target configurations 600 associated with the generation of a computer graphics image according to an embodiment of the present invention. As shown, the row of rendering target configurations 600 includes eight rendering target configurations 610(0)-610(7) in a given order.

When rendering of the computer graphics image begins, the first rendering target configuration 610(0) indicates that the first color/alpha rendering target C0, the first Z/template rendering target Z0, and the normal vector rendering target N0 are used during this phase of rendering. Consequently, this first rendering target configuration 610(0) is denoted as C0Z0N0.

A cache tile size is calculated based on the first rendering target configuration 610(0). First, the amount of cache memory occupied by the cache tile is divided by the amount of memory required for each location in the first rendering target configuration 610(0), which gives the number of pixels in the cache tile . Storage space could be measured in units of bytes or some other suitable measure. This collection of pixels is then used to determine the cache tile size. In one example, the size of the cache memory is 153600 bytes and half of the cache memory is occupied by the cache tile. The amount of memory occupied by the cache tile would be 153600/2 or 76800 bytes. The number of bytes occupied by each location in render target configuration 610(0) would be three render targets X four bytes per render target, or 12 bytes. The number of pixels in the cache tile is then 76800/12 or 6400 pixels. For square cache tiles, the cache tile would be ^6400½ or 80 pixels wide X 80 pixels high. Alternatively, the cache tile size could be any technically feasible format that is not square, such as 64 pixels wide X 100 pixels high.

As the rendering of a computer graphics image proceeds, the second rendering target configuration 610(1) indicates that the second color/alpha rendering target C1 and the second Z/template rendering target Z1 are used during this phase of rendering. Consequently, this second imaging target configuration 610(1) is referred to as C1Z1. Since the render target configuration has changed, the cache tile is cleared and a new cache tile size is calculated.

The new cache tile size is calculated based on the second rendering target configuration 610(1). In one example, the size of the cache memory is 153600 bytes and half of the cache memory, ie 76800 bytes, is occupied by the cache tile. The number of bytes occupied by each position in render target configuration 610(1) is two render targets X four bytes per render target, or 8 bytes. The number of pixels in the cache tile is then 76800/8 or 9600 pixels. For square cache tiles, the cache tile would be 9600 ^½ _', which rounds up to 98 pixels wide X 98 pixels high. Alternatively, the cache tile size can be any technically feasible format that is not square, such as 75 pixels wide X 128 pixels high.

As the rendering of the computer graphics image progresses, the third rendering target configuration 610(2) indicates that the first color/alpha rendering target C0 and the first Z/template rendering target Z0 are used during this phase of rendering. Accordingly, this third rendering target configuration 610(2) is denoted C0Z0. Since the rendering target configuration has changed, the cache tile is cleared and a new cache tile size is calculated. In this case, the number of bytes corresponding to the third rendering target configuration 610(2) is the same as for the second rendering target configuration 610(1). Consequently, the cache tile size does not change from the second rendering target configuration 610(1) to the third rendering target configuration 610(2).

As the rendering of the computer graphics image progresses, the fourth rendering target configuration 610(3) indicates that the first color/alpha rendering target C0, the second color/alpha rendering target C1, and the first Z/template rendering target Z0 are used during this phase of rendering . Consequently, this fourth rendering target configuration 610(3) is denoted as C0C1Z0. Because the rendering target configuration has changed, the cache tile is cleared and a new cache tile size calculated. In this case, the number of bytes corresponding to the fourth rendering target configuration 610(3) is equal to that for the first rendering target configuration 610(0). Thus, the cache tile size is calculated as previously described in connection with the first rendering target configuration 610(0).

As the rendering of the computer graphics image progresses, the fifth through eighth rendering target configurations 610(4)-610(7) specify rendering target configurations C0Z0, C0C1Z0, C0C1, and C0C1Z0, respectively. In one embodiment, as the rendering progresses through each change in rendering target configuration 610, the cache tile is cleared and a new cache tile is computed, as previously described. However, clearing and resizing the cache tile may be computationally expensive and may delay rendering with a new rendering target configuration 610 while the current cache tile is cleared. Furthermore, the purge reduces the number of graphics primitives that are scheduled together in the cache tile, correspondingly reducing the benefit of tiling.

Thus, in another embodiment, when a new rendering target configuration 610 represents a subset of the current rendering target configuration 610, the cache tile is neither deleted nor resized. This approach involves a situation where the new rendering target configuration 610 is the same as the current rendering target configuration 610. Such a practice may result in less efficient use of cache memory. On the other hand, cache tile flushing and resizing may be reduced, which may result in greater efficiency and performance gains, to a greater degree as cache memory utilization efficiency is reduced. In yet another embodiment, the improvement in cache memory utilization efficiency that results from changing the cache tile size can be compared to the performance increase if the cache tile is not cleared and resized. The decision as to whether to keep the current cache tile configuration or to delete and resize the cache tile can be made according to this comparison.

With this latter approach, each of the fifth through eighth rendering target configurations 610(4)-610(7) is a subset of the fourth rendering target configuration 610(3). This allows the cache tile size to remain as configured for the fourth rendering target configuration 610(3) while the rendering process progresses through the fifth through eighth rendering target configurations 610(4)-610(7). Alternatively, the cache tile and some or all of the changes in the fifth through eighth rendering target configurations 610(4)-610(7) may be cleared and resized.

In one embodiment, the cache tile size may be modified according to the currently selected debugging mode. In debugging mode, multiple samples can be stored for each pixel location and later merged, resulting in improved image quality in the final image produced. The debugging mode can be specified numerically using labels such as AA-1, AA-2, AA-4, or AA-8, indicating that each pixel contains 1, 2, 4, or 8 samples, respectively. Thus, each pixel of a cache tile may consume 1, 2, 4, or 8 times the amount of bytes, respectively, compared to a pixel in a cache tile that does not use error recovery. The cache tile size calculation can take the debug mode into account when calculating the cache tile size. For example, a cache tile may contain 76800 bytes in a rendering target configuration that occupies 12 bytes per pixel. Such a cache tile would contain 6400 pixels with no debugging mode as previously described. With an error-fixing mode, the cache tile would contain 6400, 3200, 1600, or 800 pixels for AA-1, AA-2, AA-4, or AA-8 mode, respectively. If the cache tiles are square, each cache tile would be formatted as 80 X 80, 57 X 57, 40 X 40, or 29 X 29 pixels, respectively.

In some embodiments, the cache tiles may be larger to take advantage of the fact that sample data for each pixel may be compressed at higher debugging modes. For example, debugging modes AA-1, AA-2, AA-4, or AA-8 may consume 1, 2, 3, or 5 times the amount of bytes, respectively, compared to a pixel of a cache tile if no debugging is employed. The cache tile size calculation can take the debug mode into account when calculating the cache tile size. A cache tile can contain 76800 bytes in a rendering target configuration that occupies 12 bytes per pixel. Such a cache tile would contain 6100 pixels with no debugging mode as previously described. With debugging mode, the cache tile would be 6400, 3200, 2134, or 1280 pixels for the AA-1, AA-2, AA-4 or AA-8 mode included. Similarly, if the cache tiles are square, each cache tile would be formatted as 80 X 80, 57 X 57, 47 X 47, or 36 X 36 pixels.

In yet another embodiment, surface compression may be applied to further increase the cache tile size. Surface data from the raster operation units 395, such as ZROP and CROP data, may be stored in the rendering targets 510 in a compressed manner. Such compressed surface data can be exchanged with the L2 caches without decompression and recompression of the data, thereby reducing traffic between rendering targets and the L2 cache. The compressed surface data may be stored in the L2 cache in a compressed format, thereby reducing memory consumption in the L2 cache. The calculation of the cache tile size can be modified in a manner similar to that previously described in connection with the debugging modes using the estimated or actual compression ratio associated with the surface compression.

In another embodiment where the cache tile resides in a unified cache, such as L2 cache, as described herein, a cache controller may advantageously exploit other cache traffic to and from rendering targets 510 to reduce external memory bandwidth and improve performance. Cache tiles may be stored in the L2 cache using an EVICT_NORMAL policy, subjecting cache tiles to standard eviction rules that may affect other data stored in the L2 cache that have the same eviction policy , such as when related to the ROP unit 395, the VAF 360, and the texture unit (not shown). When processing the geometric primitives for a particular cache tile, the data stream multiprocessor 310 (via global loads and global stores), the ROP 395, and the texture unit may perform memory operations associated with the particular area of the screen containing the cache tile influenced, linked. All such memory operations can be performed through the same L2 cache.

Caching data via a unified L2 cache as described above allows the cache controller to dynamically allocate cache memory between various usages including, without limitation, cache tile data, vertex attribute data and texture data. For example, the cache controller may allocate more of the cache memory for non-cache-tile data, such as texture data, resulting in improved cache performance for that other data. Thus, cache control is not limited to static L2 cache partitioning or to an architecture that includes a separate dedicated cache for cache tile data and a second dedicated cache for other data such as vertex attribute data and texture data . Rather, the cache controller dynamically selects the partitioning of the single unified L2 cache between cache tile data and other data based on current cache resource requirements.

Since accesses to the cache tile data are subject to the same EVICT_NORMAL eviction policy as other L2 data traffic streams, the L2 cache does not include static partitioning between these different traffic streams. Thus, the cache controller may combine traffic between the L2 cache and regions of rendering target memory to further reduce traffic between the L2 cache and rendering targets 510, taking advantage of the temporal and spatial locality of cache data will.

In one example, the cache controller may combine write transactions directed to the same rendering target location from the ZROP unit, the CROP unit, or from SM 310 global memory accesses. The cache controller may combine these write transactions to the L2 cache using the write-back strategy while the cache tile resides in the L2 cache. The cache controller can then write the data from the L2 cache to the rendering targets 510 in a single transaction. This approach takes advantage of spatial locality for write transactions associated with rendering target data.

In yet another example, due to the square or rectangular shape of the cache tiles present in an area of adjacent pixels in the render targets 510, the cache controller may have a higher probability of reading adjacent memory addresses from the render targets. Such data can be fetched once from the rendering targets 510 and stored in the L2 cache be cherted. The read data can then be accessed multiple times while the data resides in the L2 cache. This approach takes advantage of spatial locality for read transactions associated with the rendering target data.

In yet another example, memory read transactions targeting the same location in rendering targets 510 may occur close in time during rendering. Overlapping primitives can access the same texture with texture coordinates aligned with cache tile coordinates. In such cases, the texture memory in rendering targets 510 may be accessed multiple times, with the accesses being close in time. The cache controller can combine these accesses into a single read transaction that is targeted to the texture memory in rendering targets 510 . This procedure advantageously utilizes the temporal locality of the imaging target data. In addition to texture accesses, similar benefits of temporal locality can be achieved for read and write accesses by the ROP 395 and for general global load and global memory accesses by the SM 310. In some embodiments, the same approach can be applied to accessing the texture memory associated with a surface that is not a rendering target.

It should be noted that the architecture described herein is illustrative in nature and that variations and modifications are possible. In one example, the techniques are described herein in the context of a specific set of imaging targets 500 in a given configuration. However, the techniques described may be employed using any number of imaging targets 500. Each rendering target 510 can be configured independently of other rendering targets to contain any number of fields. Such fields may include, without limitation, 3D position data, diffuse illumination information, and specular illumination information. Each field in an imaging target 510 can be configured independently of other fields to contain any number of bits. As another example, any technically feasible imaging target configurations 610 may be specified, although specific imaging configurations 610 are shown in the series of imaging target configurations 600 . In yet another example, a series of rendering target configurations 600 may be employed during rendering of a particular image, where any set of rendering target configurations 610 may be specified, and where any rendering target configuration 610 may precede or succeed another rendering target configuration 610.

7 Figure 12 provides a flowchart of method steps for adaptively sizing cache tiles according to an embodiment of the present invention. Although the method steps associated with the systems of 1-6 are described, those skilled in the art will recognize that any system configured to perform the method steps in any order is within the scope of the invention.

As shown, a method 700 begins at step 702 in which the device driver 103 detects a new rendering target configuration that differs from a current rendering target configuration. The change in imaging target configuration may result from the start of a new imaging process or from a change from a current imaging target configuration to a new imaging target configuration during an imaging process. In step 704, the device driver 103 determines whether the new rendering target configuration is a subset of the current rendering target configuration. If the new rendering target configuration is a subset of the current rendering target configuration, then method 700 ends.

However, if the new rendering target configuration is not a subset of the current rendering target configuration, then the method 700 proceeds to step 706 in which the device driver 103 calculates the cache memory space occupied by the cache tile. For example, the cache tile could take up half or a third of the total available cache memory. In step 708, device driver 103 calculates the amount of memory space occupied by each pixel. For example, device driver 103 may total the number of bytes occupied by each field of each rendering target in the new rendering target configuration.

In step 710 the device driver 103 applies an error recovery mode factor to the memory space calculation in step 708 . In one example, device driver 103 may multiply the memory space per pixel by a factor of 1, 2, 4, or 8 for AA-1, AA-2, AA-4, or AA-8, respectively. In another example, device driver 103 may multiply the memory space per pixel by a factor of 1, 2, 3, or 5 corresponding to AA-1, AA-2, Multiply AA-4 or AA-8, accounting for the ability to compress pixels in higher error correction modes. In step 712, the device driver 103 applies a surface compression factor to the step 708 calculation of memory space. For example, device driver 103 may multiply the storage space per pixel by a factor based on an estimated or actual compression factor of ZROP data or CROP data.

In step 714, the device driver 103 calculates the number of pixels in the cache tile based on one or more of the following factors: the cache memory configuration, the new rendering target configuration, the error correction factor, and the surface compression factor. In step 716, device driver 103 calculates the cache tile size. In step 718 the device driver 103 sets the cache tile size to the calculated cache tile size from step 716 . The method 700 then ends.

In summary, cache tiles are resized when a change in rendering target configuration is detected. The size of the cache tiles is based on the rendering target configuration as well as the cache configuration. The sum of bytes required for a single position in each render target is calculated. The amount of bytes in the cache that are available for cache tiles is divided by this sum to determine the number of pixels in the cache tile. If the cache tile is square, then the square root of the number of pixels is calculated and rounded up to the nearest integer, giving the width and height of the cache tile. If the cache tile is not square, then a width and a height are chosen, where the product of the width and the height is equal to at least the number of pixels.

The cache tile size can be chosen to include multiple cache tiles in the cache memory, so that work for one or more cache tiles can be received while another cache tile is being processed. If the cache tile resides in a general-purpose cache memory, the cache tile size can be set to consume only a portion of the cache memory, about a half or a third of the cache memory, leaving the rest of the cache -Speaker for other cache clients remains. The cache tile data may be compressed to further reduce the cache tile size, taking advantage of data efficiencies at higher debugging modes and surface compression, such as ZROP and CROP compression.

An advantage of the disclosed approach is that the cache tile size is adaptively sized based on a rendering target configuration and the cache configuration. Smaller cache tile sizes are chosen for more complex rendering target configurations, while larger cache tile sizes are chosen for less complex rendering target configurations. By adaptively sizing the cache tiles based on the rendering target configuration, less computing power is required to process the cache tiles, resulting in more efficient processor utilization and lower performance requirements. Another advantage of the disclosed approach is that when compressed cache tile data is stored in the cache memory, the cache tile size can be further reduced, thereby increasing the available cache memory even more. Alternatively, the cache tile size remains the same and each cache tile can cover a larger area of the screen surface. As a result, the total number of cache tiles can be reduced, resulting in less processing overhead associated with tiling. Furthermore, a unified L2 cache tile allows for dynamic partitioning of cache memory between cache tile data and other data, where the area of L2 cache memory allocated to various categories of data may vary based on current needs. Finally, the cache controller can reduce the number of render target accesses by combining reads and writes to the same render target issued by multiple clients, by fetching the render target data once and then reusing that data multiple times. to take advantage of spatial and temporal locality.

An embodiment of the invention may be implemented as a program product for use in a computer system. The program(s) of the program product define functions of the embodiments (including the methods described herein) and may be embodied on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer, such as compact disk read-only memory (CD-ROM) floppy disks read only from a CD-ROM Drive Readable, Flash Memory, Read Only Memory (ROM) chips or other type of non-volatile electronic semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g., floppy disks in a floppy disk drive or a hard disk drive or other type of solid-state random access electronic memory) on which alterable information is stored.

Claims (6)

A method for adaptively sizing cache tiles in a graphics system, the method comprising: setting a cache tile size associated with a first cache tile to a first size; based on a first rendering configuration comprising a plurality of first rendering targets, wherein the first cache tile is a screen space tile and is divided into a plurality of raster tiles, the size of each raster tile being based on the cache tile size, detecting a change from a first rendering target configuration to a second rendering target configuration including a plurality of second rendering targets; and Set the cache tile size to a second size with the steps: Calculating the cache space occupied by the cache tile, calculating a first number of bytes per pixel for the second rendering target configuration, applying a surface compression factor to the first number of bytes to calculate a second number of bytes occupied per compressed pixel; Setting the second size of the cache tile size based on the second number of bytes. The procedure after claim 1 , further comprising: determining that the second plurality of render targets does not include a subset of the first plurality of render targets. The procedure after claim 1 , wherein the first size and/or the second size corresponds to a cache tile that has non-square dimensions. The procedure after claim 1 , wherein the second size is further based on a configuration of a cache memory in which the first cache tile resides. The procedure after claim 4 , wherein the first size and/or the second size are set to ensure that the first cache tile does not occupy more than a first portion of the cache memory. The procedure after claim 1 , further comprising: modifying the cache tile size based on a compression factor associated with an error recovery mode.

Images