Cache device for graphics processing system

Abstract

The present invention relates to a cache device for a graphics processing system. A graphics processing system is disclosed, the graphics processing system having a cache system (24) arranged between a memory (23) and a graphics processor (20), the cache system comprising a first cache (53) for transferring data to and from the graphics processor (20) and a second cache (54) arranged and configured to transfer data between the first cache (53) and the memory (23). When data is to be written from the first cache (53) to the memory (23), a cache controller (55) determines the data type of the data and, depending on the data type, causes the data to be written to the second cache (54) without being written to the memory (23), or causes the data to be written to the memory (23) without being stored in the second cache (54). In an embodiment, the second cache (54) is allocated for write-only operation.

Description

Technical Field

[0001] The present invention relates to a graphics processing system, and in particular to a cache operation in a graphics processing system. Background Art

[0002] Graphics processing is typically performed by first dividing the scene to be displayed into a number of similar basic components or "primitives" and then performing the desired graphics processing operations on these primitives. Graphics "primitives" typically take the form of simple polygons, such as triangles.

[0003] At this stage, each primitive is defined by and represented as a set of vertices. Each vertex of a primitive is associated with a set of data representing the vertex (such as position, color, texture, and other attribute data). This "vertex data" is then used, for example, when rasterizing and rendering the primitive associated with the vertex to generate the desired rendered output of the graphics processing system.

[0004] Thus, once a primitive and its vertices have been generated and defined, the primitive can be processed by a graphics processing system, for example, to display a frame. This processing essentially involves determining which sampling points in an array of sampling points covering the output area to be processed are covered by the primitive, and then determining the appearance that each sampling point should have (e.g., in terms of its color, etc.) to represent the primitive at that sampling point. These processes are generally referred to as rasterization and rendering, respectively.

[0005] Some graphics processing systems use so-called "tile-based" rendering. In tile-based rendering, instead of efficiently processing the entire rendered output (e.g., a frame) at once as in fast mode rendering, the rendered output (e.g., the output frame to be displayed) is divided into multiple smaller sub-regions, typically referred to as "tiles." Each tile (sub-region) is rendered separately (typically one after another), and then the rendered tiles (sub-regions) are reassembled to provide a complete rendered output, such as a frame for display. In such a setting, the rendered output is typically divided (by area) into rendering tiles of regular size and shape (e.g., typically square or rectangular). Other terms commonly used for "tiling" and "tile-based" rendering include "chunking" (rendered tiles are called "chunks") and "bucket" rendering. The terms "tile" and "tiling" will be used below for convenience, but it should be understood that these terms are intended to cover all alternative and equivalent terms and techniques in which the rendered output is rendered as multiple sub-regions of smaller area.

[0006] The advantage of this tile-based rendering is that primitives that do not appear in a given tile do not need to be processed for that tile and can therefore be ignored when processing the tile. This allows for a reduction in the total amount of graphics processing required for a given rendered output. However, this means that in a tile-based rendering system, it is generally desirable to be able to identify and know in advance which primitives actually exist in a given tile (i.e., sub-region).

[0007] To facilitate this, it is known to prepare, for each tile, a list of primitives to be rendered (e.g., to appear in that tile). Such a "tile list" (also often referred to as a "primitive list" or "polygon list") identifies the primitives to be rendered for the tile in question, for example by reference to a primitive indicator. Thus, the process of preparing a tile list for a tile to be rendered essentially involves determining the primitives that should be rendered for a given tile. This process is typically performed by determining (with a desired accuracy) the primitives that intersect the tile in question (i.e., will (at least partially) appear in it), and then preparing a list of these primitives for future use by the graphics processing system. It should be noted here that in the case where a primitive falls into more than one tile (which is typically the case), the primitive is included in the tile list for each tile in which the primitive falls. In practice, a tile can be viewed as having a bin (a tile list), and any primitive that should be processed for that tile is placed in that bin (in fact, the process of sorting primitives tile by tile in this way is often called "binning").

[0008] In a tile-based rendering system, the rendering work is thus effectively split into two distinct processing passes. The first pass performs (at least) geometry-related processing (e.g., vertex shading) and generates tile lists indicating which primitives contribute to each tile. This is typically performed by processing the data for the primitives in a pipelined manner, for example, by performing a series of processing steps such as obtaining vertex data for the primitives (i.e., primitive assembly, which may include various geometry processing steps), bounding, faceting, etc. The geometry data used for and / or generated as part of the processing is typically written to a geometry buffer until tile list generation is complete and the processing can proceed to the next processing step.

[0009] A second processing pass then rasterizes the primitives for each tile into separate graphics fragments for processing and performs the required fragment processing to render the fragments tile by tile, writing the rendered tiles back to memory (e.g., to a frame buffer) when the rendered tiles are complete.

[0010] The entire graphics processing pipeline of a tile-based graphics processing system thus typically includes a geometry processing stage that takes as input raw geometry (e.g., position and attribute) data stored in a memory system and processes this data to obtain transformed geometry (e.g., transformed position and attribute) data for primitives that constitute the rendered output (e.g., an image to be displayed), and prepares tile lists. Once the tile lists are prepared and written back to memory (along with the transformed geometry data), the primitives for each tile are rasterized into individual graphics fragments for processing by the graphics processing unit (processor), where the fragments are sent to a fragment shading stage that performs appropriate fragment processing operations on the fragments to generate the required fragment data, etc., for the rendered output. The processed fragment data is then written to the appropriate tile buffer so that, after all fragments to be rendered for a particular tile have been processed, the fully rendered tile can be written back to the output frame buffer, from which the fully rendered tile (along with other rendered tiles, as they have been processed) can be read to generate the entire rendered output.

[0011] Thus, when rendering a particular output (e.g., a frame) in a tile-based graphics processing system, data is generated at various stages of the graphics processing pipeline, and this data is temporarily stored, for example, in one or more associated buffers, until it is ready to be used and passed to the next stage of the graphics processing pipeline. Thus, this data is written by the graphics processing unit (GPU) to associated storage (e.g., its associated buffers), from which it can subsequently be read as the graphics processing operation progresses. Consequently, this data is variously transferred between the GPU and the memory system during the graphics processing operation, with an associated memory "bandwidth" cost, which represents the amount of data that needs to be transferred to / from the memory.

[0012] As GPUs get larger (and the graphics content more complex), graphics processing operations consume increasing amounts of memory bandwidth. Consequently, the power cost of moving this data to and from memory during graphics processing operations can represent a significant portion of the overall power budget. Therefore, particularly for system-on-chip (SoC) mobile devices or other devices with limited bandwidth and power resources, it is desirable to try to reduce the amount of memory bandwidth required. Summary of the Invention

[0013] To this end, one could consider implementing a cache device to store data more locally on the GPU, thereby reducing the need to access relatively slow data storage (e.g., particularly in main memory). However, the applicant has recognized that simply attempting to cache any and all data traffic flowing into and out of the GPU is not the most efficient use of cache resources. Therefore, the applicant believes that there is room for improvement in this regard.

[0014] According to a first aspect of the present invention, there is provided a graphics processing system, the graphics processing system comprising:

[0015] Memory system;

[0016] Graphics processor; and

[0017] a buffer system disposed between the memory system and the graphics processor and configured to transfer data between the memory system and the graphics processor for use by the graphics processor in generating rendering output;

[0018] The buffer system includes:

[0019] a first buffer configured to communicate data to and from a graphics processor for use in generating rendered output;

[0020] a second buffer arranged and configured to transfer data between the first buffer and the memory system; and

[0021] A cache controller configured to, when data is to be written from a first cache to a memory system, determine a data type of the data to be written, and to cause the data to be written to a second cache without being written to the memory system, or to cause the data to be written to the memory system without being stored in the second cache, depending on the determined data type.

[0022] According to a second aspect of the present invention, a method for processing graphics using a graphics processing system is provided. The graphics processing system includes: a memory system; a graphics processor; and a buffer system, the buffer system being arranged between the memory system and the graphics processor and being operable to transfer data between the memory system and the graphics processor for use by the graphics processor in generating rendering output. The buffer system includes: a first buffer, the first buffer being operable to transfer data to and from the graphics processor for use in generating rendering output; a second buffer being arranged and being operable to transfer data between the first buffer and the memory system; and a buffer controller. The method includes the following steps:

[0023] When data is to be written from the first buffer to the memory system during a graphics processing operation, the cache controller determines a data type of the data to be written and writes the data to the second buffer without writing the data to the memory system, or writes the data to the memory system without storing the data in the second buffer, depending on the determined data type.

[0024] The present invention, at least in its preferred embodiments, relates to a tile-based graphics processing system (although this is not necessarily the case and the present invention may also find application in other types of graphics processing systems). Accordingly, the first and second aspects of the present invention presented above preferably relate to a tile-based graphics processing system, and a method of processing graphics using a tile-based graphics processing system, respectively. When generating rendered output within a graphics processing system, particularly within such a tile-based system, various data traffic flows (e.g., geometry data and fragment data) may flow between a graphics processing unit (processor) and a memory system. In order to reduce the need to access a relatively slow memory system and save memory read / write bandwidth, it may be desirable to use relatively fast storage (i.e., caches) within the memory hierarchy to transfer at least some of this data. That is, rather than having to transfer data directly between the memory system and the graphics processing unit (processor), the data may be at least temporarily stored in one or more caches (cache system) disposed between the graphics processing unit (processor) and the memory system.

[0025] In such an arrangement, when data needs to be read from memory (or written back to memory) in order to perform a graphics processing operation by a graphics processing unit (processor), a read (or write) request for that data may be issued to the cache system. That is, the read (or write) operation will be performed via the cache system, and in the case of a read operation, for example, if the data is already available in the appropriate cache (there is a cache "hit"), then the graphics processing unit (processor) will use the data from that cache without having to go to the associated data storage portion, such as in main memory.

[0026] Thus, such an arrangement may work well to reduce the instances where a relatively slow memory system must be accessed, thereby saving memory bandwidth and / or increasing throughput within the graphics processing system.

[0027] However, applicants have recognized that simply attempting to cache any and all data in a single cache may not be the most efficient use of cache resources. Accordingly, the present invention provides a more efficient arrangement for caching data used in a (e.g., tile-based) graphics processing system.

[0028] In the present invention, a cache system connected to a (main) memory system of a graphics processing system and used for caching data generated and / or used by a graphics processing unit (processor) includes (at least) two caches.

[0029] Specifically, the cache system includes: a first cache for transferring data to and from the graphics processing unit (processor) during operation, and a second cache arranged between the first cache and the memory system and for transferring data between the memory system and the first cache during operation. Therefore, the graphics processing unit (processor) typically interfaces with the first cache of the cache system, which in turn interfaces with the second cache that interfaces with the memory system. Naturally, the first cache and the second cache do not necessarily have to interface directly with the graphics processing unit (processor) or the memory system (or each other), and various other levels of caches may be included in the graphics processing system. For example, the first cache may interface with a higher cache (e.g., L1 cache) of the graphics processing unit (processor). Of course, various other arrangements will be possible.

[0030] A cache controller is provided to control the operation of the cache system. Specifically, the second cache can be used to cache only certain (selected) types of data. For example, when data is to be written from the first cache to the memory, the cache controller is used to first determine the data type of the data when it is in operation to control whether the second cache is used to process (i.e., cache) the data or not (in this case, the data preferably bypasses the second cache and enters the memory system directly without being stored in the second cache, i.e., so that the data cannot be retrieved from the second cache later).

[0031] Therefore, when a write request is issued to write some data from the first buffer back to the memory system, the present invention first checks the type of data to be written. If the data is of a data type that should not be cached using the second buffer (for example, because it is expected that data of that type cannot be cached efficiently using the second buffer (thus, in an embodiment, data of that data type is not cached using the second buffer)), the cache controller can determine this and then cause the data to be written to the memory system without storing the data in the second buffer.

[0032] However, in the case where the data has a data type that is to be cached using the second cache, the cache controller can determine this and then cause the second cache to be used to process the data accordingly. For example, if an entry (e.g., a cache line) for the data does not already exist in the second cache (i.e., there is a cache miss for the data in the second cache), a cache line of the second cache can be allocated for the data, and then the data can be written to the second cache. Accordingly, if a cache line of the second cache has already been allocated for the data (i.e., there is a cache hit), the cache entry (cache line) can be updated with the new data (value), thereby overwriting the existing entry.

[0033] In this regard, when data of a data type to be cached using the second buffer is to be written back from the first buffer, the data is therefore written to the second buffer without being written to the memory system. In some cases, the data written to the second buffer can subsequently be written back to the memory, for example, if some data needs to be evicted from the second buffer to free up cache lines for new data. However, in a preferred embodiment, (at least some) of the data stored in the second buffer can be used and ultimately discarded without ever being written back to the memory. For example, as further explained below, when a processing job (or a set of jobs) using the data in the second buffer has been completed, the entire second buffer is preferably invalidated so that the data in the second buffer can then be discarded without being written back to the memory.

[0034] Thus, the present invention allows the use of the second cache to process certain (selected) types of data, preferably without having to write that data to the memory system, thereby significantly reducing the bandwidth used for memory writes. However, at the same time, other types of data (e.g., data types that cannot be efficiently processed using the second cache (e.g., because that type of data is expected to be too large to be efficiently cached)) and their presence in the second cache may harm cache performance (e.g., by "corrupting" the cache and causing other data that could be more efficiently cached to be evicted before use), and may result in the second cache being bypassed and written back to the memory system, i.e., not attempting to store that data in the second cache).

[0035] Thus, the cache resources in the second buffer can be used in the expected most favorable circumstances. This allows for more efficient use of cache resources than attempting to cache any and all data being passed to or from the first buffer of the cache system in the second buffer. Thus, the cache system of the present invention can provide numerous advantages over other arrangements for caching data in (e.g., tile-based (delayed)) graphics processing systems.

[0036] For example, in some modern graphics processing systems, the graphics processing unit (GPU) has access to a relatively large L2 cache (e.g., on the order of 2MB to 4MB). This L2 cache is allocated for both reading and writing, and is used to cache any data traffic flowing between the GPU (GPU) and memory during operation. Typically, this L2 cache can efficiently cache at least some of this data.

[0037] Surprisingly, however, Applicants have discovered that making the L2 cache larger does not necessarily provide any substantial performance or bandwidth benefits, particularly when attempting to cache certain types of data streams that may extend over multiple processing jobs or rendering passes, for example.

[0038] For example, in a tile-based graphics processing system, there are typically two main data streams: a geometry data stream (e.g., involving raw geometry data that is input, as well as transformed position and attribute data that is generated during vertex shading and written back from the graphics processing unit (processor) into associated geometry buffers along with tile lists, etc.) and a fragment data stream (e.g., fragment data that is processed for each tile and written out to a frame buffer for each rendered tile when generating rendered output).

[0039] The geometry processing stage of a tile-based renderer will therefore generate various transformed position and attribute data for primitives (i.e., from vertex shading, tessellation, geometry shading, etc.), which are written out from the graphics processing unit (processor) along with the required tile lists (and any associated pointer tables, etc.) into associated buffers until geometry processing is complete, after which the geometry data can be passed to the next stage of the graphics processing pipeline, e.g., for rasterization and rendering. The data generated during these geometry processing jobs is typically temporarily stored in associated buffers before being provided as input to the next processing stage. Thus, the geometry buffer includes, for example, transformed position and attribute data, tile lists, etc.

[0040] This geometry data may be purely intermediate (or temporary), i.e., it will eventually be consumed during the graphics processing operation (and then no longer needed). For example, the geometry data may be consumed by connected fragment processing work. As another example, particularly when transform feedback is enabled, a geometry buffer may be copied to an output buffer (e.g., which is visible to the application that caused the graphics processing operation to be performed). However, when the geometry buffer is copied to the output buffer, the geometry buffer is no longer needed at that time. The lifespan of these geometry buffers (measured in clock cycles between the generation and consumption of the associated geometry data) may be relatively long. Therefore, the L2 cache is generally unable to cache this type of data efficiently because the data may be evicted before it is used (requiring the data to be repeatedly fetched into the L2 cache, thereby consuming more bandwidth).

[0041] Another example of data that is involved in spreading across different processing jobs would be fragment data that is to be written to a frame buffer, for example, to display the final rendered output. For example, a frame buffer typically includes color / depth buffer writes and texture reads, etc. Thus, in a first rendering job, the frame buffer is rendered as output and can then be read back as an input texture for a subsequent rendering job. However, frame buffers are often relatively large (and typically larger than the geometry buffer), so the entire frame buffer may not fit in a typical L2 cache (for example, a frame buffer for a 1080 pixel frame may be approximately 4MB, depending on the compression scheme used). Even if the size of the L2 cache were to be increased so that the entire frame buffer could fit in the L2 cache, the lifespan of the frame buffer data would still be relatively long, so that in a typical cache arrangement, the data might still be evicted from the L2 cache before being (re)used.

[0042] One approach to attempting to cache these data streams would be to integrate another (larger) cache, such as an L3 cache, between the L2 cache and main memory. However, simply adding another cache allocated for read and write below the L2 cache is similar to making the L2 cache larger, and therefore may still not be the most efficient use of cache resources. Therefore, this may not be the best solution, especially for applications where the area available for cache resources may be limited, such as for system-on-chip mobile devices.

[0043] In contrast, the present invention allows for a more efficient use of cache resources, since the cache resources of the second cache may be used to cache only certain (selected) types of data which it is desired to be able to cache efficiently in the second cache.

[0044] Specifically, the second buffer is preferably used to cache intermediate data generated by the graphics processing unit (processor), such as the above-mentioned type of intermediate data, that is, temporary data generated and consumed during a graphics processing operation (a set of one or more processing jobs) but not required to be retained outside the current processing job (or jobs) using the data. Therefore, in an embodiment, the cache controller causes at least some types of intermediate (temporary) data to be written to the second buffer, which are generated by the graphics processing unit (processor) during the generation of the rendering output and are to be written out to the memory.

[0045] For example, the second buffer is preferably used to cache geometric data generated during the geometry processing step of a graphics processing operation in a tile-based graphics processing system. For example, the second buffer can (and preferably) be used to cache (at least) transformed position and attribute data generated according to the geometry processing step (e.g., as generated from a vertex shader), preferably as well as tile lists and / or associated pointer tables, etc. This geometric data is temporarily stored until the connected fragment processing work that requires the data is ready. However, the geometric data is then completely consumed during the associated fragment work, and it can be guaranteed that the transformed geometric data will not be reused after the fragment work using the data is completed, so that the data can (and preferably) be discarded at that time. In other words, as discussed above, the geometric data is therefore purely intermediate (i.e., temporary) data. Therefore, in an embodiment, the cache controller is configured to write the intermediate geometric data generated by the graphics processor when generating rendering output to the second buffer.

[0046] In an embodiment, the second buffer can (also) be used to cache frame buffer data. That is, in some embodiments, the cache controller is configured to cause the frame buffer data (and geometry data) to be written to the second buffer. For example, the second buffer can be used to cache the color / depth data of the rendered fragments generated by the graphics processing unit (processor) when generating the rendering output. For example, this can be particularly (but not exclusively) the case where the frame buffer data is reused as texture input when rendering the next frame, but does not need to be stored otherwise, and is therefore also intermediate (i.e., temporary) data that can potentially be discarded and never written to the memory (and preferably therefore not written to the memory), but can advantageously be cached using the second buffer. However, other arrangements are of course possible.

[0047] In the present invention, the data type can generally be selected based on the known buffer size and the expected size of the working set of data items of the data type to be cached using the second buffer, for example, so that all data of that type to be written during a particular graphics processing operation (i.e., a set of one or more processing jobs) can be expected to be completely accommodated in the second buffer.

[0048] For a relatively large second buffer (e.g., significantly larger than the expected size of the frame buffer, e.g., a second buffer on the order of 8MB to 16MB, depending on the implementation), it may be advantageous to cache both geometry data and fragment (frame buffer) data written from the first buffer to the second buffer. That is, depending on the size of the second buffer, i.e., assuming the second buffer is large enough to efficiently cache such data, the second buffer may be advantageously used to cache both geometry data and frame buffer data. However, this may not always be practical, particularly for mobile devices where the available area of ​​cache resources may be limited.

[0049] Therefore, for a smaller second buffer (e.g., on the order of 2MB to 4MB), improved performance can be achieved by operating the second buffer to cache only geometry data (i.e., not fragment (frame buffer) data). For example, in this case, the expected fragment data (e.g., of the entire frame buffer) is too large to fit in the second buffer. Therefore, there is little benefit in caching this data in the second buffer. Therefore, by caching only geometry data in the second buffer, it is ensured that the geometry data can be cached efficiently without the risk of fragment data interfering with it (e.g., by causing the geometry data to be evicted before use, thereby corrupting the cache).

[0050] Thus, depending on, for example, the size of the second buffer, in some preferred embodiments, the second buffer is used only to cache intermediate geometry data, with the cache controller effectively bypassing the second buffer and passing fragment (and other) data directly to memory. However, various other arrangements are of course possible.

[0051] As already explained, it will be understood that the geometry data (and optionally also the frame buffer data, e.g. depending on the size of the second buffer) that are preferably cached using the second buffer are intermediate data, i.e. temporary data that are generated and consumed during a graphics processing operation (a set of one or more processing jobs for that operation), but do not necessarily have to be retained outside the current processing job (or jobs) that uses the data.

[0052] It will therefore be appreciated that this purely intermediate (temporary) data need not be retained beyond the processing work that uses the data and therefore need not be permanently written to the memory system. Thus, upon completion of the processing work requiring the data, the data can, and preferably is, discarded without writing the data back to the memory (this is unlike the situation in more conventional cache devices, where any evicted data can be flushed from the cache system and written back to the memory system).

[0053] Preferably, therefore, after a processing job (or a group of processing jobs) using the data in the second buffer is completed, the second buffer is (wholly or partially) invalidated so that the data can be discarded without writing the data back to the memory system. Therefore, in an embodiment, the cache controller is configured to invalidate the second buffer when a group of one or more processing jobs using the data in the second buffer is completed, so that the data in the second buffer can be evicted without writing the data to the memory system.

[0054] That is, the second cache is preferably capable not only of caching intermediate data, such as the type described above, but is also capable of discarding such data after use, without writing the data back to the memory. Thus, any intermediate data that was used only during a particular set of processing work (e.g., which may be associated with the rendering of a particular frame) can be discarded (and it is known that the data will not have to be used again) when the processing work is completed. Therefore, in an embodiment, when a set of processing work using data in the second cache is completed, this is indicated to the cache controller, and the cache controller then preferably invalidates all of the data in the second cache. For example, when the processing work using the data in the second cache is completed, the graphics processing unit (processor) can signal the cache controller to cause the cache controller to invalidate the entire second cache so that the data in the second cache can be (and eventually is) evicted without writing the data to the memory system.

[0055] By invalidating the data at this point, i.e., when the processing requiring such data in the second buffer is complete, the data can be discarded rather than written back to memory, thereby saving a significant portion of memory bandwidth. This works well in part because the second buffer is controlled to cache only certain (selected) types of data that are expected to fit into the second buffer, making it relatively unlikely that data will be evicted from the second buffer before it is used (i.e., to free up a cache entry for new data). Therefore, in a preferred embodiment, data of the type of data cached using the second buffer is never written back to the memory system.

[0056] In a preferred embodiment, the entire second buffer is invalidated when a set of processing jobs using the data in the second buffer is completed. However, it is also possible to invalidate only part of the second buffer when a set of processing jobs using the data in the second buffer is completed. For example, in the case where the second buffer is used to cache multiple types of data (e.g., geometric data and frame buffer data) when it is in operation, the entries (cache lines) in the second buffer can be selectively invalidated to invalidate only any type of data (e.g., geometric data) used by the completed processing jobs. Any entries (cache lines) marked as invalid can then be evicted without writing the data back to the memory. On the other hand, any other data (e.g., data that has not yet been used) can remain valid in the second buffer and / or can be written back to the memory as needed.

[0057] In a particularly preferred embodiment, the second cache of the present invention is allocated only for write requests (i.e., the second cache is preferably a "write-only" cache). That is, a cache line of the second cache is allocated in response to a cache miss for a write request to the second cache, but a cache line is not allocated in response to a cache miss for a read request to the second cache. Thus, in an embodiment, the second cache is allocated for write only, such that in response to a miss in the second cache for a request to write data to the second cache, a cache line of the second cache is allocated for the data so that the data can then be written to the second cache, and in response to a miss in the second cache for a request to read data from the second cache, a cache line of the second cache is not allocated and the read request is passed to the memory system. In contrast, the first cache is preferably allocated for both read and write, and is preferably used, when in operation, to cache any (and all) data types to be passed between the graphics processing unit (processor) and the memory system.

[0058] It has been discovered that by allocating the second buffer to be write-only, the intermediate data stream can be cached more efficiently. For example, because the second buffer is controlled to cache only certain (selected) types of data being written to the second buffer, and because the second buffer is preferably allocated to only respond to write requests, it is possible to ensure that most (if not all) of the data being cached in the second buffer can be processed using only the second buffer, without ever needing to write the data back to the memory system, thereby saving a significant amount of memory write bandwidth.

[0059] Thus, the present invention particularly allows these types of intermediate data streams to be more efficiently cached by the second buffer. The present invention also preferably allows such intermediate data to be discarded from the second buffer after use, without having to write the data back to the memory system, to save memory bandwidth. For example, at the end of a set of one or more processing jobs that use data in the second buffer, the graphics processing unit (processor) can and preferably does signal the cache (controller) that the data in the second buffer can be invalidated without writing the data back to the memory system, because it can be guaranteed that the intermediate data will not be used again.

[0060] However, other data that cannot be efficiently cached in the second cache can actually be passed directly through the second cache. For example, there may be some data types that cannot reasonably be accommodated in the second cache. In that case, allocating a cache line for data of that data type not only does not provide the aforementioned advantages, but may actually be detrimental to overall cache performance.

[0061] Even if the second cache is not controlled to cache only certain (selected) data types, that is, even if the second cache is used to cache all data to be written to the memory from the first cache (for example, this may be appropriate for a relatively large second cache), the use of a second cache allocated as write-only may itself be advantageous. In that case, in a manner similar to that described above, the addition of a second cache allocated as write-only allows all writes to be efficiently cached with reduced write memory bandwidth. That is, in a manner similar to that described above, the second cache can be used to cache data written back by the graphics processing unit (processor) and is arranged to reduce (or even eliminate) the situations in which this data must be written to the memory system. For any data that has already been written to the second cache, read memory bandwidth can still be saved, but in response to a missed read request, no cache line is allocated for the new data, so the read request does not cause any data that has already been written to the second cache to be evicted, thereby reducing the possibility of cache corruption.

[0062] Therefore, another aspect of the present invention provides a graphics processing system, the graphics processing system comprising:

[0063] Memory system;

[0064] Graphics processor; and

[0065] a buffer system disposed between the memory system and the graphics processor and configured to transfer data between the memory system and the graphics processor for use by the graphics processor in generating rendering output;

[0066] The buffer system includes:

[0067] a first buffer operable to communicate data to and from the graphics processor for use in generating rendered output; and

[0068] A second cache is set and configured to transfer data between the first cache and the memory system; wherein the second cache is allocated as write-only, so that in response to a write request cache miss in the second cache, a cache line of the second cache is allocated for the data so that the data can then be written to the second cache, and in response to a read request miss in the second cache, the cache line of the second cache is not allocated and the read request is passed to the memory system.

[0069] According to another aspect of the present invention, a method for processing graphics using a graphics processing system is provided. The graphics processing system includes: a memory system; a graphics processor; and a buffer system, the buffer system being disposed between the memory system and the graphics processor and being operable to transfer data between the memory system and the graphics processor for use by the graphics processor in generating rendering output. The buffer system includes: a first buffer, the first buffer being operable to transfer data to and from the graphics processor for use in generating rendering output; and a second buffer being disposed and being operable to transfer data between the first buffer and the memory system. The method includes the following steps:

[0070] When data is to be written from the first cache to the memory system, issuing a write request for the data to the second cache, and in response to a write request miss in the second cache, allocating a cache line in the second cache for the data; and

[0071] When data is to be read from the second cache to the first cache, a read request for the data is issued to the second cache, and in response to a read request miss in the second cache, the read request is passed to the memory system without allocating a cache line in the second cache.

[0072] It will be appreciated that the graphics processing systems and methods according to these other aspects may preferably have or include any or all of the features described herein with respect to the first and second aspects, at least to the extent that these features are not mutually exclusive. In particular, it will be appreciated that the cache systems according to these other aspects may include a cache controller that, when in operation, is operable to perform any of the operations described above with respect to the first and second aspects. Again, these other aspects preferably relate to tile-based graphics processing systems (although arrangements are possible).

[0073] It will therefore be appreciated that the present invention, in accordance with its various aspects, can provide various benefits compared to other caching devices and provide a more efficient method for caching intermediate data generated, particularly during tile-based rendering, thereby improving the overall performance of the graphics processing system.

[0074] The present invention, at least in preferred embodiments, relates to caching of graphics data generated and used by a graphics processor (graphics processing unit), particularly when operating a tile-based (deferred) graphics processing scheme.

[0075] In the present invention, a cache system connected to the (main) memory system of the graphics processing system and used to cache data for use by the graphics processing unit (processor) includes two caches.

[0076] The memory (memory system) of the graphics processing system (with which the buffer system of the present invention interfaces) may include any suitable and desired memory and memory system of the graphics processing system (e.g., the overall data processing system of which the graphics processing system is a part), such as and preferably, main memory for the graphics processing system (e.g., where there is a separate memory system for the graphics processor), or main memory of the data processing system shared with other elements, such as the host processor (CPU) of the data processing system. Of course, other arrangements would be possible.

[0077] In a particularly preferred embodiment, the first cache comprises an L2 cache of a primary cache hierarchy of a memory system (e.g., a graphics processing system). Thus, the first cache is preferably local to and dedicated to the graphics processing unit (processor). For example, the first cache preferably feeds into the L1 cache of the graphics processing unit (processor), which in turn feeds into the processor (core).

[0078] The second cache is preferably interfaced with the first cache. Preferably, where the first cache is an L2 cache, the second cache is an L3 cache that (directly) feeds the first cache. The second cache may be dedicated to the graphics processing unit (processor). That is, in some embodiments, the second cache is local to the graphics processing unit (processor) and is used only to transfer data to and from the graphics processing unit (processor). However, in some preferred embodiments, the second cache is a shared cache resource that is accessible to both the graphics processing unit (processor) and the host processor (CPU) of the data processing system of which the graphics processing system is a part.

[0079] However, various other arrangements are of course possible.

[0080] The first and second caches of the cache system of the present invention may be configured in any suitable and desired manner and may, for example and preferably, comprise any desired and appropriate number of cache lines. They preferably each comprise a plurality of cache lines.

[0081] The first cache and the second cache can have the same size (e.g., in terms of their storage capacity (e.g., number of cache lines)), but more typically, the second cache (which interfaces with and receives data from the memory) is larger (has a larger capacity (number of cache lines)) than the first cache (which interfaces with and receives data from the graphics processing unit (processor)).

[0082] Subject to the specific features of the first and second caches discussed herein, those caches may otherwise be configured and operated in any suitable and desired manner, such as, and preferably, relying on and in accordance with conventional cache mechanisms for the graphics (data) processing system in question. Thus, they may, for example, and preferably do, use conventional cache operations and processing (such as least recently used (LRU) processing) to identify and release cache lines for use, etc., as well as to control the storage of data in the cache. Other arrangements are of course possible.

[0083] The buffer system of the present invention (e.g., the second buffer of the buffer system) can interface with and receive data from the (main) memory (and the memory system) in any suitable and desired manner. In an embodiment, the second buffer receives data stored in the (main) memory directly from the memory. However, it is also contemplated that the second buffer can receive data stored in the (main) memory via other buffers of the (main) memory system.

[0084] Similarly, the first buffer of the buffer system of the present invention (i.e., the first buffer that interfaces with the graphics processing unit (processor) and provides data to the graphics processing unit (processor) for use in generating rendering output) can be interfaced with the graphics processing unit (processor) in any suitable and desired manner.

[0085] A buffer system is typically used to store data between a graphics processing unit (GPU) and a memory system. When performing graphics processing operations, the GPU (GPU) will send appropriate read or write memory requests to the memory system for the data. For example, when the GPU (GPU) requires some input data that is presumably resident in the memory system, a read request for that data is sent to the memory system. Similarly, when data needs to be written back from the GPU (GPU), a write request for that data is sent to the memory system.

[0086] In such an arrangement, when a read / write memory request for data is issued to the memory system, a determination is first made as to whether the data is available in the appropriate cache (a cache "lookup"). In other words, the read / write memory request is first issued to the cache system, where the memory request is passed through the memory hierarchy, i.e., from the graphics processing unit (processor) to the first cache, then to the second cache, and finally to the memory system as needed.

[0087] In the present invention, the way in which the cache system handles read / write requests preferably depends on the type of data that is the object of the request. For example, as explained above, preferably, the second cache is only used to cache certain (selected) types of data.

[0088] For example, in response to a write request to write data from the first buffer to the memory system, the cache controller will first check whether the data has a data type that should be processed using the second buffer (e.g., in a preferred embodiment, check whether the data is intermediate geometry data, and optionally also check whether the data is frame buffer data, depending on the size of the buffer). Therefore, when data is to be written from the first buffer to the memory system, the cache controller is configured to determine the data type of the data to be written and, depending on the determined data type, cause the data to be written to the second buffer without writing the data to the memory system, or cause the data to be written to the memory system without storing the data in the second buffer.

[0089] For example, if a write request is for data of a data type that is not cached using the second buffer, no cache line in the second buffer is allocated for the data, and the write request is passed down to the memory system, where the data is written accordingly (effectively bypassing the second buffer). The memory system can then issue an appropriate write response, which can be passed back through the buffer system.

[0090] On the other hand, if the write request is for data of a data type that should be cached using the second cache, the data is processed using the second cache in the usual manner. For example, the second cache is first checked for the data (cache lookup). If there is not yet an entry for the data in the second cache (i.e., there is a cache miss), a cache line of the second cache is allocated for the data, and the data (value) can be written to the second cache when the allocated cache line becomes available. On the other hand, if a cache line (entry) has already been allocated for the data, there is no need to allocate a new cache line, and the existing cache line (entry) can be updated, for example, by overwriting the existing data (value) with the new data (and optionally also increasing the (usage) counter of the cache line, etc.).

[0091] In the event that a cache line needs to be allocated in response to a write request but the second cache is full (such that no empty cache line is available for allocation to data), one of the cache lines in the second cache may be evicted. The cache line may be selected for eviction based on any suitable eviction policy. For example, a least recently used policy may be used to evict cache lines. However, other arrangements are certainly possible, and any suitable cache replacement policy may be used.

[0092] Accordingly, in an embodiment, when data is to be read from the second cache, the cache controller is configured to determine the data type of the data to be read, and when it is determined that the data has a data type to be cached using the second cache, check whether the data exists in the second cache, and if the data exists in the second cache, read the data from the second cache, otherwise if the data does not exist in the second cache, read the data from the memory system.

[0093] On the other hand, when it is determined that the data has a data type that is not cached using the second cache, the cache controller is configured to read the data from the memory system without checking the second cache. Therefore, as described above, preferably, the second cache is allocated as write-only, so that in response to a miss in the second cache for a request to write the data to the second cache, a cache line of the second cache is allocated for the data, so that the data can then be written to the second cache (e.g., in the manner described above), but in response to a miss in the second cache for a request to read the data from the second cache to the first cache, a cache line of the second cache is not allocated, and the read request is passed to the memory system. That is, preferably, a cache line in the second cache is allocated only in response to a cache miss for a write request.

[0094] Therefore, a cache miss for a read request will not attempt to allocate a cache line in the second cache. For example, when processing a read request from the first cache, the cache controller first checks whether the data is of the type to be processed by the second cache. If the data is of the type that the second cache is processing, a cache lookup is performed in response to the read request for the data. If the data is available in the second cache (a cache hit), the data can be read out accordingly (thereby saving external read bandwidth for cache hits).

[0095] However, in this case, if a cache lookup is performed in response to a read request miss in the second cache, a cache line is not allocated for the data, but instead the read request is passed to the memory system and the requested data (not stored in the second cache) is read from the memory system (i.e., the requested data is extracted from the associated data stored in the memory system without adding the data to the second cache).

[0096] In contrast to the operation of the second buffer, the first buffer is preferably allocated for both read and write. That is, a cache line of the first buffer is preferably capable of being allocated for both read and write requests. The first buffer is preferably used to buffer any (and all) appropriate data traffic to and from the graphics processing unit (processor).

[0097] The type of data to be processed using the second buffer may be determined (predetermined), for example, depending on the size of the second buffer. Therefore, a cache controller is provided that, when operative, checks the data type of data being written to / read from the second buffer to determine whether the data is of a type that should be processed using the second buffer.

[0098] Therefore, it is preferred to provide a mechanism to allow the cache controller to identify the data type of any data being written to / read from the second cache. For example, in an embodiment, page-based hardware attributes or other similar mechanisms can be used to implement control of the second cache. Then, using page-based hardware attributes, a buffer can be allocated and some tags can be assigned to the page table to indicate what type of data service the buffer will contain. A simple classification can be to distinguish, for example, geometry buffer services (such as transformed position and attribute data, tile lists, etc.) and frame buffer services (such as color / depth buffer writes and texture reads, etc.). However, other settings are certainly possible. For example, instead of using page-based hardware attributes, a set of bits of the physical memory address of the data can be used to indicate the data type. Alternatively, the data type can be sent to the cache controller along with, for example, a dedicated metadata channel, for example as sideband information, where the metadata indicates the main type of data (such as "texture read", "frame buffer write", "attribute buffer read / write", "tile read / write", etc.).

[0099] Depending on the type of data, the cache controller can then cause the second cache to be used to process the data (where cache lines are allocated for write requests in the manner described above, etc.), or the second cache can be effectively bypassed, where data is written to or read from the memory system without storing the data in the second cache.

[0100] The present invention can be used with any form of output that can be generated using a graphics processing system (tile-based or otherwise). In a preferred embodiment, the present invention is used when the graphics processing system is used to generate images for display, but the present invention can be used with any other form of graphics processing output that can be generated by a graphics processing system, as desired.

[0101] As will be understood from the above, the present invention is preferably implemented in a system comprising a memory system, a buffer system, and a graphics processing unit (GPU). Data for rendering output (e.g., an image to be displayed) is preferably stored in memory in the memory system. The GPU is preferably configured to extract the required data from the memory in the manner described above and store it in the buffer system. The GPU then preferably reads the required data from the buffer system to generate the rendered output (e.g., in the manner described above). After the rendered output is generated in this manner, it is preferably displayed, for example, on a display such as a screen.

[0102] A graphics processing unit (GPU) will, and preferably does, implement and execute a graphics processing pipeline to perform graphics processing.

[0103] In a particularly preferred embodiment, the graphics processing system includes a host processor that executes applications that may require graphics processing by a graphics processing unit (processor). The system preferably also includes appropriate storage (e.g., memory), buffers, etc. as described above.

[0104] The present invention may be used with and for use with any suitable and desired graphics processing systems and processors.

[0105] The present invention is particularly applicable to tile renderers (tile-based graphics processing systems).Thus, in a preferred embodiment, the graphics processor (processing pipeline) is a tile-based graphics processor (processing pipeline).

[0106] The graphics processing unit (processor) (processing pipeline) may include, and preferably does include, any one or more, and preferably all, of the processing stages that a graphics processor (processing pipeline) may typically include. Thus, for example, the graphics processing unit (processor) preferably includes a primitive setup stage, a rasterizer, and a renderer. In a preferred embodiment, the renderer is in the form of or includes a programmable fragment shader (shader core).

[0107] The graphics processor (processing pipeline) preferably also includes one or more programmable shading stages, such as one or more, and preferably all, of a vertex shading stage, a hull shader, a tessellation stage (e.g., where tessellation is performed by executing a shader program), a domain (evaluation) shading stage (shader), a geometry shading stage (shader), and a fragment shader.

[0108] The graphics processor (processing pipeline) may also include any other suitable and desired processing stages that a graphics processing pipeline may include, such as a depth (or depth and stencil) tester, a blender, one or more tile buffers, a write-out unit, and the like.

[0109] The graphics processing system and / or processor preferably also includes, and / or is in communication with, one or more memories and / or memory devices that store data described herein and / or store software for performing the processes described herein. The graphics processing system and / or processor may also be in communication with a host microprocessor and / or a display for displaying images based on data generated by the graphics processor (processing pipeline).

[0110] In a particularly preferred embodiment, the various functions of the present invention are performed on a single graphics processing platform that generates and outputs rendered fragment data, which is written, for example, to a frame buffer of a display device.

[0111] The present invention may be implemented in any suitable system, such as a suitably configured microprocessor-based system. In some embodiments, the present invention is implemented in a computer and / or microprocessor-based system.

[0112] The various functions of the present invention can be performed in any desired and suitable manner. For example, the functions of the present invention can be realized with hardware or software as needed. Therefore, for example, the various functional elements and levels of the present invention can include one or more suitable processors, one or more controllers, functional units, loops / circuits, processing logic, microprocessor settings, etc., which can be used to perform various functions etc. when working, such as suitable dedicated hardware elements (processing loops / circuits) and / or programmable hardware elements (processing loops / circuits) that can be programmed to run in a desired manner.

[0113] It should also be noted here that, as will be understood by those skilled in the art, the various functions of the present invention, etc. may be replicated and / or executed in parallel on a given processor. Likewise, if desired, the various processing stages may share processing loops / circuits, etc.

[0114] Furthermore, any one or more or all of the processing stages of the present invention may be implemented as processing stage loops / circuits, for example, in the form of one or more fixed function units (hardware) (processing loops / circuits), and / or in the form of programmable processing loops / circuits that can be programmed to perform desired operations. Likewise, any one or more of the processing stages and processing stage loops / circuits of the present invention may be provided as separate circuit elements to any one or more other processing stages or processing stage loops / circuits, and / or any one or more or all of the processing stages and processing stage loops / circuits may be formed, at least in part, of shared processing loops / circuits.

[0115] Those skilled in the art will also appreciate that all described embodiments of the present invention may suitably include any one or more or all of the preferred and optional features described herein.

[0116] The method according to the invention can be implemented at least in part using software such as a computer program. Thus, it will be seen that, when viewed from other embodiments, the present invention provides computer software that is particularly suitable for carrying out the methods described herein when installed on a data processing device, a computer program element comprising computer software code portions for carrying out the methods described herein when the program element is run on the data processing device, and a computer program comprising code means suitable for carrying out all steps of one or more methods described herein when the program is run on the data processing device. The data processing system may be a microprocessor, a programmable FPGA (field programmable gate array), or the like.

[0117] The present invention also extends to a computer software carrier comprising such software which, when used to operate a graphics processor, a renderer or other system comprising data processing means, causes the processor, renderer or system, together with the data processing means, to perform the steps of the method of the present invention. Such a computer software carrier may be a physical storage medium such as a ROM chip, CDROM, RAM, flash memory or magnetic disk, or may be a signal such as a wired electronic signal, an optical signal or a radio signal such as a signal to a satellite.

[0118] It will also be understood that not all steps of the method of the present invention need to be performed by computer software. Therefore, according to other broad embodiments, the present invention provides computer software and such software is installed on a computer software carrier to perform at least one of the steps of the method set forth herein.

[0119] Therefore, the present invention can be suitably implemented as a computer program product for use with a computer system. Such an implementation may include a series of computer-readable instructions fixed on a tangible, non-transitory medium, such as a computer-readable medium, for example, a floppy disk, CD ROM, ROM, RAM, flash memory, or hard disk. It may also include a series of computer-readable instructions that can be sent to a computer program via a modem or other interface device through a tangible medium (including but not limited to optical or analog communication lines) or invisibly using wireless technology (including but not limited to microwave, infrared or other transmission technology). The series of computer-readable instructions implements all or part of the functions previously described herein.

[0120] Those skilled in the art will appreciate that such computer-readable instructions can be written in a variety of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions can be stored using any current or future storage technology (including but not limited to semiconductor, magnetic, or optical), or delivered using any current or future communication technology (including but not limited to optical, infrared, or microwave). It is contemplated that such a computer program product can be distributed as a removable medium with accompanying printed or electronic documentation, for example, shrink-wrapped software, pre-installed with a computer system (e.g., on a system ROM or fixed disk), or distributed from a server or electronic bulletin board over a network (e.g., the Internet or the World Wide Web). BRIEF DESCRIPTION OF THE DRAWINGS

[0121] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0122] Figure 1 Schematically illustrates a tile-based graphics processing setup;

[0123] Figure 2 schematically illustrates an arrangement of a graphics processor operable in accordance with the present invention;

[0124] Figure 3 An example of a graphics processing pipeline is shown in some detail;

[0125] Figure 4 Illustrate various data structures that can be used when rendering output in a tile-based graphics processing setting;

[0126] Figure 5 An example of a buffer system according to an embodiment of the present invention is shown;

[0127] Figure 6 illustrates data flow using a buffer system according to an embodiment of the present invention;

[0128] Figure 7 is a flow chart illustrating how to process a request to write to memory using a cache system according to an embodiment;

[0129] Figure 8 is a flow chart illustrating how to process a request to read from a memory using a cache system according to an embodiment;

[0130] Figure 9 is a flow chart illustrating a memory read response according to an embodiment; and

[0131] Figure 10 is a flow chart illustrating a memory write response according to an embodiment. DETAILED DESCRIPTION

[0132] The present embodiment relates to a graphics processing system that uses so-called "tile-based" rendering. In tile-based rendering, the two-dimensional scene to be displayed is subdivided or divided into multiple smaller sub-regions, which are referred to herein as "tiles." The tiles are each rendered individually (typically one after the other), and then the rendered tiles are reassembled to provide a complete frame for display. In such a setup, the scene is typically divided into sub-regions (tiles) of regular size and shape (for example, they are typically square or rectangular), but this is not required.

[0133] In a tile-based rendering system, in a first processing pass, a list of primitives to be rendered (i.e., a "tile list") is thus prepared for each tile, thereby identifying (e.g., by reference to primitive indicators) those primitives that are actually present in a given tile and need to be rendered for that tile. The process of preparing a tile list for a tile typically involves determining (with a desired level of accuracy) the primitives that intersect the tile in question (i.e., will (at least partially) appear in it), and then preparing a list of these primitives for future use by the graphics processing system.

[0134] The process of determining the primitives that should be listed (rendered) for any given tile can be performed at different levels of precision, for example, depending on the efficiency optimization of different parts of the tiling and rendering process. For example, at the highest level of precision, it is possible to determine exactly in which tiles a given primitive will at least partially appear, and then include the primitive in the tile list only for those tiles. This is often referred to as "precise" tileization.

[0135] Figure 1 The exact binning process is illustrated. Figure 1 As shown, the scene to be displayed 1 is divided into 16 regularly sized sub-regions or tiles 2. Then, for each primitive in the scene, the tile or tiles in which the primitive actually appears (falls) are determined. The primitive is added to the tile list of each tile in which the primitive is found to fall. Figure 1 In the example shown, primitive 3 is added to the tile list for tile 4, primitive 5 is included in the tile lists for tiles 6 and 7, primitive 8 is included in the tile lists for tiles 9, 10, 11, and 12, and primitive 13 is included in the tile list for tile 12. It should be noted here that for the purpose of clarity, Figure 1 Only a few tiles and primitives are shown. As will be appreciated by those skilled in the art, in actual graphics processing operations, there will typically be many more primitives and tiles.

[0136] It is also known to prepare tile lists with less precision than can be achieved with exact binning. This can be useful, for example, to simplify the preparation of tile lists. A common "less exact" binning technique is "bounding box" binning. In this case, a so-called "bounding box" is drawn around a primitive or a group of primitives, and then the tiles covered by the bounding box are determined. Then, for each tile that is found to be covered (at least partially) by the bounding box, the one or more primitives represented by (i.e., enclosed by) the bounding box are listed (binned).

[0137] Therefore, this setting uses bounding boxes to determine the tiles for which a given primitive should be listed for rendering, rather than the primitives themselves. This can mean, for example, that a primitive may be listed for rendering for tiles that it does not actually fall into (e.g. if the bounding box does not surround the primitive tightly or precisely enough), but on the other hand, using bounding boxes in this way can simplify the preparation of tile lists.

[0138] In the event that a primitive falls within more than one tile, the primitive is included in a list (bin) for each tile that the primitive falls within. These tile lists may be prepared separately for each tile (so that there is a one-to-one correspondence between tiles and tile lists). However, it will be understood that in some cases, or for at least some of the tiles, a tile list may cover a group of multiple tiles.

[0139] When a list of primitives to be rendered (tile list) has been prepared for each sub-region (tile) in this way, the tile list is stored for use, for example, to allow the system to identify which primitives need to be considered (and rendered) when rendering the tile in question.

[0140] Such tile-based rendering settings have been found to work well, as they can, for example, help avoid regions of the scene where a primitive does not exist while still processing the primitive.

[0141] Figure 2 A graphics processor 20 that can operate according to the present invention is schematically shown. The graphics processor 20 includes a geometry processor 21 and a renderer 22, and can access a memory 23. The memory 23 can be "on chip" with the geometry processor 21 and the renderer 22, or can be an external memory that can be accessed by the geometry processor 21 and the renderer 22. Figure 2 As shown, graphics processor 20 interfaces with memory 23 via a buffer system 24, the operation of which will be described in further detail below.

[0142] The memory 23 is particularly and as Figure 2Shown is a stored set of raw geometry data (provided by, for example, a graphics processor driver or API running on the host system (microprocessor) of graphics processor 20) which is provided as input to geometry processor 21 for processing during an initial processing pass.

[0143] For example, the geometry processor 21 may include, among other things, a programmable vertex shader 27 and a tile list construction unit 28. The programmable vertex shader 27 takes as input the original geometry data stored in the memory 23 and processes the data to provide transformed geometry data (which is the result of various transformations and processing operations performed on the original geometry), the transformed geometry data including geometry data in a form that is ready for two-dimensional ('2D') arrangement in a frame to be displayed. The transformed geometry data includes, for example, transformed vertices (vertex data), etc. The programmable vertex shader 27 and the processing it performs may take any suitable form and may be any suitable and desired such processing.

[0144] The tile list construction unit 28 performs the process of preparing tile lists by assigning primitives to tile lists, which are then used by the renderer 22 to identify the primitives that should be rendered for each tile of the scene to be rendered. To do this, the tile list construction unit 28 takes as its input the transformed and processed vertex data (i.e., the positions of the graphics objects in the scene) from the programmable vertex shader 27, uses this data to build tile lists, and stores these lists as tile lists.

[0145] The transformed geometry data and tile lists generated by the geometry processor 21 during the first processing pass are then written back to the memory 23 so that the data can then be fetched into and used by the renderer 22 to generate rendered output (e.g., frames for display).

[0146] According to an embodiment of the present invention, and as Figure 2 As shown, the data is stored in a buffer system 24.

[0147] To generate rendered output, the renderer 22 will essentially determine which of the primitives should be rendered for a given tile, and then render and store the data for that tile (e.g., in a frame buffer) so that the image of the primitives can be properly displayed, such as on a display device.

[0148] Now refer to Figure 3 Describes the processing of primitives, Figure 3 A graphics processing (rendering) pipeline 31 which may operate in accordance with the present invention is shown schematically. Figure 3The graphics processing pipeline 31 shown in FIG is a tile-based renderer and thus produces tiles of rendered output data arrays (such as output frames to be generated). The rendered output data arrays may typically be output frames intended for display on a display device such as a screen or printer, but may also include, for example, intermediate data intended for use in later rendering passes (also known as "render to texture" output), etc. Of course, other arrangements of the graphics processing pipeline will be possible.

[0149] Figure 3 The main elements and pipeline stages of the graphics processing pipeline 31 are shown. However, as will be appreciated by those skilled in the art, there may be other stages of the graphics processing pipeline. Figure 3 Other elements not shown in the example. It should also be noted here that Figure 3 This is illustrative only, and, for example, in practice the functional units and pipeline stages shown may share significant hardware circuitry even though they are Figure 3 It will also be understood that Figure 3 Each of the illustrated stages, elements, units, etc. of the graphics processing pipeline may be implemented as desired and will accordingly include, for example, appropriate circuits / loops and / or processing logic, etc. for performing the necessary operations and functions.

[0150] Figure 3 The pipeline stages are shown schematically after graphics primitives (polygons) 32 have been generated for input to the rasterization process. Thus, at this point, the graphics data (vertex data) has undergone fragment front-end operations 38, such as transformation and lighting operations (e.g., as Figure 2 ), and a primitive setup stage for setting up primitives to be rendered in response to commands and vertex data provided to the graphics processor.

[0151] like Figure 3 As shown, this portion of the graphics processing pipeline 31 preferably includes multiple stages, including a rasterization stage 33, an early Z (depth) and stencil test stage 34, a fragment shading stage 36, a late Z (depth) and stencil test stage 37, a blending stage 39, a tile buffer 40, and a downsampling and write-back (multi-sample resolution) stage 41.

[0152] The rasterization stage 33 of the graphics processing pipeline 31 operates to rasterize the primitives that make up the rendered output (e.g., an image to be displayed) into individual graphics fragments for processing. To do this, the rasterizer 33 receives graphics primitives 32 for rendering, rasterizes the primitives into sampling points, and generates graphics fragments having appropriate locations (representing appropriate sampling locations) for rendering the primitives.

[0153] The early Z / stencil stage 34 performs a Z (depth) test on the fragments received from the rasterizer 33 to see if any fragments can be discarded (culled) at this stage. To do this, the depth value of the fragment sent from (associated with) the rasterizer 33 is compared with the depth values of the already rendered fragments (these depth values are stored in the depth (Z) buffer that is part of the tile buffer 40) to determine whether the new fragment will be occluded by the already rendered fragments. At the same time, an early stencil test is performed. The early depth and stencil test stage 34 can be configured to perform a single depth and stencil test per clock cycle.

[0154] Fragments that pass the fragment early Z and stencil test stage 34 are then sent to the fragment shading stage 36. The fragment shading stage 36 performs appropriate fragment processing operations on the fragment that passes the early Z and stencil test to process the fragment to generate appropriate fragment data for rendering output (e.g., for display of the fragment), etc.

[0155] The fragment processing may include any suitable and desired fragment shading processing, such as executing a fragment shader program on the fragment, applying a texture to the fragment, applying fog or other operations to the fragment, etc., to generate appropriate fragment data. In the present embodiment, the fragment shading stage 36 is in the form of a shader pipeline (programmable fragment shader), but other arrangements would be possible if desired, such as also using or replacing fixed-function fragment shading units. The fragment shader 36 is configured to always process all samples associated with the fragment it receives as a whole.

[0156] The fragment shading stage 36 has a variation interpolator (variation position evaluator) 42 associated with it that is used to determine the correct variation value for the current fragment. For certain interpolation modes, such as centroid mapping, the variation interpolator uses the fragment's associated coverage mask to select the correct position within the fragment to interpolate the variation data. Therefore, the variation interpolator 42 is configured to process all sample points associated with the fragments it receives in parallel, so that it can select the correct interpolation position for centroid mapping.

[0157] There is then a "late" fragment Z and stencil test stage 37 which, among other things, performs an end-of-pipeline depth test on the shaded fragment to determine whether the rendered fragment will actually be seen in the final image. This depth test uses the Z buffer value for the fragment's position stored in the tile buffer's 40 Z buffer to determine whether the fragment data for the new fragment should replace the already rendered fragment's fragment data by comparing the depth value of the fragment (associated with it) emitted from the fragment shading stage 36 with the depth value of the already rendered fragment (stored in the depth buffer). This late fragment depth and stencil test stage 37 also performs any needed "late" alpha and / or stencil testing on the fragment.

[0158] The fragments that have passed the late fragment test stage 37 may then be subjected to any necessary blending operations in a blender 39 with the fragments already stored in the tile buffer 40, as required. Any other remaining operations required may also be performed on the fragments at this stage, such as dithering etc. (not shown).

[0159] Finally, the (blended) output fragment data (values) are written to a tile buffer 40, from which they can be output to a frame buffer for display, for example. The depth values for the output fragments are also appropriately written to a Z buffer within the tile buffer 40. The tile buffer and the Z buffer will therefore store appropriate colors, etc., or Z values for the sampling points represented by the buffers. The tile buffer stores an array of sample data representing a portion of the rendered output (e.g., an image to be displayed). Multiple tile buffers may be provided. For example, in an embodiment, three tile buffers may be provided, two of which are used to store color (red, green, blue) values for each sampling point (one tile buffer may be used for this purpose, but two are preferred), and one tile buffer is used to store Z (depth) values and stencil values for each sampling point. Of course, other arrangements will be possible. These tile buffers may be provided as separate buffers, or in fact all may be part of the same larger buffer. These tile buffers are located (locally) in the graphics processing pipeline (chip).

[0160] The data from the tile buffer 40 is then input to a downsampling (multi-sample resolution) unit 41 and then output (written back) to an output buffer 43 (tile write back) such as a frame buffer of a display device (not shown) (which may not be on the graphics processing platform itself). The display device may include, for example, a display including an array of pixels, such as a computer monitor or a printer.

[0161] The downsampling unit 41 downsamples the sampled data stored in the tile buffer 40 to an appropriate resolution for the output buffer (device) (i.e., such that an array of pixel data corresponding to the pixels of the output device is generated) to generate output values (pixels) 44 that are output to the output buffer 43. This downsampling can be performed in any suitable manner. In the present embodiment, linear mixing of the data is used to downsample the data. However, other arrangements would be possible if desired. If desired, the downsampling unit 41 may also apply appropriate gamma correction to the data it outputs to the output buffer 43, or this may be performed, for example, as a fragment shading operation or in any other suitable and desired manner.

[0162] When a tile of rendered output has been processed and its data exported to main memory (e.g., to a frame buffer in main memory (not shown)) for storage, the next tile is processed, and so on, until enough tiles have been processed to generate the entire rendered output (e.g., a frame (image) to be displayed), which can then be written to the frame buffer.

[0163] Figure 4 Illustrated are various data structures (buffers) that may be used in tile-based rendering processing as described above, to which data may be alternately written / read from during graphics processing operations. For example, as shown, the vertex shading (IDVS) operation in the geometry processor 21 typically receives (raw) geometry data as input from index buffers, position buffers, and attribute buffers typically stored in memory 23 (although this data is typically pre-fetched and provided to the geometry processor 21 via a buffer system 24). This data is then processed (e.g., by vertex shading operations in the geometry processor 21) to generate transformed position and attribute data, which are written to associated transformed position and transformed attribute buffers. The geometry processing also generates a tile list. This information is then written back from the geometry processor 21 via the buffer system 24. The geometry data is then provided as input to the renderer 22 along with the texture data and processed (e.g., as Figure 3 ) to generate rendered output, which is then written to a frame buffer, for example, for display.

[0164] It will be understood that the transformed geometry data and tile lists are purely intermediate data relevant only to the current processing job. That is, the geometry data is then used by the connected fragment processing job, but does not need to be used again after the connected fragment processing job is completed. Similarly, when a frame buffer is generated, it can be provided as a texture input for the next rendering pass, but it may not need to persist thereafter.

[0165] In some arrangements, an L2 cache may be provided that, when operational, caches any and all data (both read and write data) to be transferred between the graphics processor 20 and the memory 23. However, it has been found that this may not be the most efficient use of cache resources. Therefore, the present invention provides a novel cache arrangement that is capable of more efficiently caching at least some of these intermediate data types generated in a tile-based graphics processing system.

[0166] Specifically, a buffer system is provided that has (at least) a first buffer configured to transfer data to and from the graphics processor 20 and a second buffer provided and configured to transfer data between the first buffer and the memory 23. For example, in this embodiment, Figure 5 As shown, the cache system 24 includes a "first" cache of the cache system 24 in the form of an L2 cache 52 (or more precisely, a group of L2 caches), and a "second" cache of the cache system 24 in the form of an L3 cache 54 arranged between the L2 cache 52 and the memory 23.

[0167] therefore, Figure 5 An example of a memory hierarchy according to an embodiment is shown. Figure 5 As shown, the cache system 24 disposed between the external (e.g., DRAM) memory 23 and the graphics processor 20 includes three cache levels. Specifically, the cache system 24 includes a first cache of the cache system in the form of a set of local L2 caches 53 (for both the graphics processor 20 and the CPU 50), a second cache of the cache system in the form of a shared (system) L3 cache 54 disposed between the L2 cache 53 and the external memory 23, and a set of local L1 caches 52 that interface with the processing core 51 of the graphics processor 20 (and a corresponding set of L1 caches that interface with the processing core of the CPU 50). However, various other arrangements are of course possible. For example, although Figure 5 L3 cache 54 is shown as being shared between graphics processor 20 and CPU 50 of the data processing system of which graphics processor 20 is a part, but it will be understood that this need not be the case and that in embodiments a local L3 cache dedicated to the GPU may be provided.

[0168] A cache controller 55 is also provided which, when operational, determines the type of data to be passed to the cache system and decides whether the data should be processed through the second L3 cache 54 in the manner described below.

[0169] Specifically, the cache system is configured so that only certain (selected) types of data are cached using the L3 cache 54. For example, the cache system 24 is typically configured to more efficiently use the second L3 cache 54. Thus, the L3 cache 54 is configured to cache (only) the type of data that is expected to be efficiently cached in the L3 cache 54. This will typically depend on the size of the L3 cache 54 compared to the expected size of the data to be written to the memory 23 (via the cache system 24).

[0170] For example, applicants have found that for small to medium-sized L3 caches (e.g., approximately 2MB to 4MB), caching only the geometry bandwidth (e.g., transformed positions and attributes, as well as polygon lists and pointer tables) is most beneficial. For example, for these sizes, it is expected that the typical frame buffer bandwidth is too large to fit within the L3 cache 54, and attempting to cache frame buffer data would therefore cause data flows to interfere with each other, resulting in poor cache performance. In this case, caching only the geometry data can yield the highest read hit rate.

[0171] On the other hand, for medium to large sized caches (eg, approximately 8MB to 16MB), caching all writes (including geometry and frame buffer bandwidth) may be the best option.

[0172] Therefore, when the cache controller 55 is in operation, it is used to check whether the data has a data type that should be cached using the second L3 cache 54 when the data is to be written to the memory 23 via the cache system 24, and then process it accordingly, that is, either cache the data in the L3 cache 54, or bypass the L3 cache 54 and reach the memory 23 directly from the L2 cache 52. This can be implemented in various suitable ways. For example, page-based hardware attributes or other similar mechanisms can be used to implement this control. However, other settings are certainly possible. For example, instead of using page-based hardware attributes, a bit set for the physical memory address of the data can be used to indicate the data type. Alternatively, the data type can be sent to the cache controller, for example, along a dedicated metadata channel (not shown) as sideband information.

[0173] Figure 6 The data flows for different types of data services are shown, which illustrate how to process read and write requests depending on the type of data to be read / written. Specifically, Figure 6 The data stream showing both read and write requests can alternatively be processed using the L3 cache 54 (i.e., if the cache controller 55 determines that the data is of a data type that is to be cached in the L3 cache 54 (e.g., geometry and / or optionally frame buffer data)) or passed directly to the memory 23 without storing the data in the L3 cache 54.

[0174] For example, Figure 6As shown, when a write request ('AXI write request') is issued from the (first) L2 cache 53 to the (second) L3 cache 54, it is first checked whether the data to be written is of a data type that should be cached using the L3 cache 54. If not, the request is passed to the memory 23 (via an appropriate bypass buffer ('write bypass buffer')), and the data is not stored in the L3 cache 54, but is written to the memory 23. On the other hand, if the data is of a data type that should be cached using the L3 cache 54, a cache lookup is performed for the data using its associated tag ('write tag buffer'), and in the event of a cache hit ('write hit buffer'), the cache entry for the data is updated (overwritten) with the new data, and a write response ('AXI write response') is returned to the L2 cache 53.

[0175] In the event of a write request cache miss (i.e., no entry for the data exists in the L3 cache 54), a cache line of the L3 cache 54 is allocated for the data, and the data is written to the L3 cache 54 in the usual manner (and if the L3 cache 54 is full, a cache line of the L3 cache 54 may be selected for eviction, e.g., based on least recently used or any other suitable policy, wherein the data in the evicted cache line is written back to the memory 23 to free the cache line to be allocated to new data to be written (a 'write eviction buffer')).

[0176] Figure 7 1 is a flowchart illustrating in greater detail how, in an embodiment, the L3 cache 54 is used to process a request (700) to write data from the L2 cache 53 to the memory. First, the cache controller 55 checks whether the data is of a type that is cached by the L3 cache 54 (701). If the data is not cached by the L3 cache 54 (701—No), the write request is passed directly to the external memory 23 (702) without storing the data in the L3 cache 54.

[0177] However, if the data is of a type that should be cached using the L3 cache 54 (701—Yes), a cache lookup is performed for the data in the L3 cache 54 (703). If there is no entry for the data (703—No), a cache line in the L3 cache 54 is allocated for the data (704) (wherein the cache line is evicted as needed, for example, if the L3 cache 54 is full). The allocated cache line is then updated (705) and the data is written to the cache line. If there is a cache hit, such that an entry for the data already exists in the L3 cache (703—Yes), there is no need to allocate a new cache line, but rather the existing cache line is updated (overwritten) with the new data (705). When the cache line has been updated (705), a write response is returned from the L3 cache 54 to the L2 cache 53 (706).

[0178] Preferably, the L3 cache 54 is allocated as write-only. That is, preferably, cache lines in the L3 cache 54 are allocated only in response to write requests. Therefore, if Figure 6 As shown, read requests are handled differently from write requests. Once again, the cache controller 55 first checks whether the data to be read is of a data type that is to be cached in the L3 cache 54. If not, the read request is passed directly to the memory 23 (via the 'read bypass buffer'), and the requested data can then be written back from the memory 23 (via the 'AXI Read Response' of the 'Read Response Buffer') without being stored in the L3 cache 54.

[0179] On the other hand, when the data has a type of data that is cacheable in the L3 cache 54, a cache lookup is performed for the data ('read tag buffer'). In the event of a cache hit ('read hit buffer'), the data can be read out of the L3 cache 54 in the usual manner. However, in the event of a cache miss ('read miss buffer'), no cache line in the L3 cache 54 is allocated for the data, and the read request is passed directly to the memory 23, and the high data is then read out of the memory 23 without being stored in the L3 cache 54.

[0180] Figure 8 800 is a flowchart illustrating how a request to read data from memory 23 is processed using L3 cache 54. In a first step (801), cache controller 55 checks whether the data is of a type that should be cached in L3 cache 54. If not (801—No), the read request is passed directly down to memory 23 (802) so that the data is retrieved and read from memory 23 without being stored in L3 cache 54. That is, if the read request does not hit in L3 cache 54, the data is not added to L3 cache 54. If the data is of a type that should be cached in L3 cache 54 (801—Yes), a cache lookup is performed. If the read request hits in L3 cache 54 (803—Yes), the data can be read from L3 cache 54 in the usual manner (804), and a read response (805) is provided from L3 cache 54. However, if the read request cache misses (803 - No), then the read request is again passed directly down to the memory 23 (802) without attempting to allocate a cache line for the data (as opposed to the case of a write request cache miss, where a cache line is allocated, as in the case of a write request cache miss). Figure 7 shown).

[0181] Figure 9is a flow chart showing how a read response (900) is passed from memory 23 through L3 cache 54 to L2 cache 53 (901). For example, as discussed above, if a request to read data from L3 cache 54 to L2 cache 53 does not hit in L3 cache 54, the read request is passed to memory 23 to retrieve the data from memory 23 without storing the data in L3 cache 54. In that case, the response to the read request is passed directly back up through the cache system. Therefore, for L2 cache 53, whether the data is retrieved from L3 cache 54 or from memory 23 is invisible.

[0182] Figure 10 54. It is a flow chart showing how to pass a write response from the memory 23 to the L3 cache 54. It is possible that the data has a data type that is not cached in the L3 cache 54 (in this case, the write request is passed to the memory 23, as shown in FIG. Figure 7 702 of ) or because the data has been evicted from the L3 cache 54 (i.e., in Figure 7 704 shown in ). Therefore, the cache controller needs to distinguish between these two cases to know whether the write response needs to be returned to the L2 cache 53. For example, in the first case (904-No), if the data is not processed in the L3 cache 54, but the data is written back to the memory 23, then the write response is sent to the L2 cache 53 to inform this situation (905). On the other hand, in the second case (904-Yes), the data is written to the memory 23 only because the L3 cache 54 is full, and not in direct response to the write request from the L2 cache 53 (that is, the data written back to the memory 23 in this case is not the data that is the subject of the write request that caused the data to be evicted and written back, that is, the data is written back only to free up the cache entry for new data). Therefore, the memory write does not need to be informed to the L2 cache 53 (and therefore No-906).

[0183] It has been found that a cache system operating in the manner described above, such as one with an L3 cache 54 assigned to write-only operation, is particularly effective at caching certain (selected) types of intermediate data generated in tile-based graphics processing systems of the type described above, including geometry data and, depending on the size of the L3 cache 54, framebuffer data. For example, in some tests using a 4MB L3 cache configured to cache only geometry data, it has been found that the cache system described above can achieve a reduction in total read bandwidth per frame of up to approximately 20%. In tests using an 8MB L3 cache to cache all data traffic (i.e., geometry and framebuffer data), a reduction in total read bandwidth of up to 40% has been achieved. Some performance improvements are also achieved due to improved last-level cache hit rates. For example, large amounts of geometry content can place significant pressure on the fragment front-end (i.e., the geometry processing step). Therefore, hits in the last-level cache for geometry bandwidth can benefit the tile list reader and vertex fetcher units, which can overload subsequent pipeline stages, resulting in fewer fragment starvations.

[0184] As will be appreciated by those skilled in the art, the present embodiment (and the present invention) may be implemented in any (eg) tile-based rendering system as desired. The various components and functions of the present embodiment and the present invention may be similarly implemented as desired and using any suitable technology.

[0185] Therefore, while the foregoing detailed description has been presented for purposes of illustration and description, it is not intended to be exhaustive or to limit the technology described herein to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The described embodiments were chosen to best explain the principles of the technology described herein and its practical application, thereby enabling others skilled in the art to best utilize the technology described herein in various embodiments and with various modifications as suited to the particular use contemplated. It is intended that the scope be defined by the claims appended hereto.

Claims

1. A graphics processing system, comprising: Memory system; Graphics processor; as well as a buffer system disposed between the memory system and the graphics processor and configured to transfer data between the memory system and the graphics processor for use by the graphics processor in generating rendering output; The buffer system comprises: a first buffer configured to transfer data to and from the graphics processor for use in generating rendering output, wherein the first buffer is used to cache data to be transferred between the graphics processor and the memory system via the buffer system, regardless of data type; a second buffer arranged and configured to transfer data between the first buffer and the memory system, wherein the second buffer is used to cache only a specific type of data; and A cache controller configured to, when data is to be written from the first cache to the memory system, determine a data type of the data to be written, and, depending on the determined data type, cause the data to be written to the second cache without being written to the memory system, or cause the data to be written to the memory system without being stored in the second cache.

2. The graphics processing system according to claim 1, wherein: The second cache is allocated as write-only, so that in response to a miss in the second cache for a request to write data to the second cache, a cache line of the second cache is allocated for the data so that the data can then be written to the second cache, and in response to a miss in the second cache for a request to read data from the second cache, the cache line of the second cache is not allocated and the read request is passed to the memory system.

3. The graphics processing system according to claim 2, wherein: The first buffer is allocated for reading and writing.

4. The graphics processing system according to claim 1 or 2, wherein: The buffer controller is configured to cause intermediate geometry data generated by the graphics processor when generating rendering output to be written to the second buffer.

5. The graphics processing system according to claim 4, wherein: The buffer controller is configured to cause frame buffer data to be written to the second buffer.

6. The graphics processing system according to claim 1 or 2, wherein: The cache controller is configured to invalidate the second cache in response to completion of a set of one or more processing jobs using the data in the second cache so that the data in the second cache can be evicted without writing the data to the memory system.

7. The graphics processing system according to claim 1 or 2, wherein: When data is to be read from the second cache, the cache controller is configured to determine the data type of the data to be read, and when it is determined that the data has a data type to be cached using the second cache, check whether the data exists in the second cache, and if the data exists in the second cache, read the data from the second cache, otherwise if the data does not exist in the second cache, read the data from the memory system.

8. The graphics processing system according to claim 7, wherein: When it is determined that the data has a data type that is not to be cached using the second buffer, the cache controller is configured to read the data from the memory system without checking the second buffer.

9. A graphics processing system, comprising: Memory system; Graphics processor; as well as a buffer system disposed between the memory system and the graphics processor and configured to transfer data between the memory system and the graphics processor for use by the graphics processor in generating rendering output; The buffer system comprises: a first buffer operative to communicate data to and from the graphics processor for use in generating rendered output, wherein the first buffer is allocated for both reading and writing; and a second cache, the second cache being arranged and configured to transfer data between the first cache and the memory system; wherein the second cache is used to cache only a specific type of data, and wherein the second cache is allocated as write-only, so that in response to a cache miss for a write request in the second cache, a cache line of the second cache is allocated for the data so that the data can then be written to the second cache, and in response to a cache miss for a read request in the second cache, a cache line of the second cache is not allocated and the read request is passed to the memory system.

10. The graphics processing system according to claim 9, wherein: The first buffer is used to buffer data to be transferred between the graphics processor and the memory system through the buffer system regardless of data type.

11. A method for processing graphics using a graphics processing system, the graphics processing system comprising: Memory system; Graphics processor; as well as a buffer system disposed between the memory system and the graphics processor and configured to transfer data between the memory system and the graphics processor for use by the graphics processor in generating rendering output, the buffer system comprising: a first buffer, the first buffer being operative to transfer data to and from the graphics processor for use in generating rendering output, wherein the first buffer is configured to cache data to be transferred between the graphics processor and the memory system via the buffer system, regardless of data type; a second buffer, the second buffer being provided and being operable to transfer data between the first buffer and the memory system, wherein the second buffer is configured to cache only a specific type of data; and Cache Controller, The method comprises the following steps: When data is to be written from the first buffer to the memory system during a graphics processing operation, the cache controller determines a data type of the data to be written and, depending on the determined data type, writes the data to the second buffer without writing the data to the memory system, or writes the data to the memory system without storing the data in the second buffer.

12. The method according to claim 11, comprising the steps of: When data is to be written from the first cache to the memory system, a write request for the data is issued to the second cache, and in response to a miss in the second cache by the write request, a cache line in the second cache is allocated for the data; as well as When data is to be read from the second cache to the first cache, a read request for the data is issued to the second cache, and in response to the read request not hitting in the second cache, the read request is passed to the memory system without allocating a cache line in the second cache.

13. The method according to claim 11 or 12, comprising the steps of: Writing intermediate geometric data generated by the graphics processor when generating rendering output into the second buffer.

14. The method according to claim 13, further comprising the steps of: The frame buffer data is written to the second buffer.

15. The method according to claim 11 or 12, comprising the steps of: When a group of one or more processing jobs using the data in the second buffer is completed, the second buffer is invalidated so that the data in the second buffer can be evicted without writing the data to the memory system.

16. The method according to claim 11 or 12, comprising the steps of: When data is to be read from the second buffer, the data type of the data to be read is determined, and when it is determined that the data has a data type to be cached using the second buffer, it is checked whether the data exists in the second buffer, and if the data exists in the second buffer, the data is read from the second buffer, otherwise if the data does not exist in the second buffer, the data is read from the memory system.

17. The method according to claim 16, wherein When it is determined that the data has a data type that is not to be cached using the second buffer, the data is read from the memory system without checking the second buffer.

18. A method for processing graphics using a graphics processing system, the graphics processing system comprising: Memory system; Graphics processor; as well as A buffer system is provided between the memory system and the graphics processor and is used to transfer data between the memory system and the graphics processor when in operation for use by the graphics processor in generating rendering output, the buffer system comprising: a first buffer, the first buffer being operative to transfer data to and from the graphics processor for use in generating rendered output, wherein the first buffer is allocated for both reading and writing; a second buffer, the second buffer being provided and being operable to transfer data between the first buffer and the memory system, wherein the second buffer is allocated for write-only and is used to cache only a specific type of data; The method comprises the following steps: When data is to be written from the first cache to the memory system, issuing a write request for the data to the second cache, and in response to the write request not hitting in the second cache, allocating a cache line in the second cache for the data; and When data is to be read from the second cache to the first cache, a read request for the data is issued to the second cache, and in response to the read request not hitting in the second cache, the read request is passed to the memory system without allocating a cache line in the second cache.

19. The method according to claim 18, wherein The first buffer is used to buffer data to be transferred between the graphics processor and the memory system through the buffer system regardless of data type.

20. A non-transitory computer-readable storage medium storing software code which, when executed on a data processor, performs the method according to claim 11, 12 or 18.

Images