Cache arrangement for a data processing system

Abstract

The invention is entitled "Cache arrangement for a data processing system". The invention provides a data processing system comprising a cache system configured to transfer data between a processor and a memory system. The cache system comprises a cache. When a block of data stored in compressed form in the memory is to be loaded into the cache, the block of data is stored into a group of one or more cache lines of the cache and associated compression metadata of the compressed block of data is provided as separate sideband data.

Description

BACKGROUND

[0001] The technology described herein relates to data processing systems, and in particular to cache operations in data processing systems such as graphics processing systems.

[0002] Graphics processing operations, which can be performed by a graphics processor (graphics processing unit (GPU)), typically process data in uncompressed form. When such operations have produced a particular output (e.g. a frame), the output data can then be written to an output (e.g. frame) buffer, for example in main memory, for storage prior to further processing (e.g. display of the frame).

[0003] The storage and access of uncompressed data in use can place relatively high memory and / or bandwidth requirements on a graphics processing device (or conversely result in performance loss if such requirements are not met), particularly as the output buffer typically resides in memory external to the graphics processor, for example. This is particularly important for mobile and handheld devices which perform graphics processing, as such devices are inherently limited in terms of their memory, bandwidth and power resources and capabilities, for example.

[0004] To reduce the amount of data which needs to be transferred to and from memory during graphics processing operations, and the associated power cost of moving such data back and forth, the data can be compressed, for example prior to being written to memory. This allows the data to be stored in a compressed (encoded) format. When the data is required for further processing, the compressed data is then read from memory and decompressed (decoded) so that it is then in a suitable format for the graphics processing operation.

[0005] To further assist such data transfer to and from the graphics processor, a cache can be used to store data locally to the graphics processing unit when performing graphics processing operations which use that data. This helps to reduce the need to fetch data from slower data stores such as the main memory of the graphics processing system.

[0006] Although described above in the context of graphics processing, similar considerations apply to various other instances of data processing where it is desirable to reduce the amount of data required to store and / or transfer particular information, and where it can be desirable to store data more locally to the data processing unit, for example in a cache.

[0007] The applicant believes that there is scope for improvement in cache operations in data processing systems. BRIEF DESCRIPTION OF DRAWINGS

[0008] Various embodiments will now be described, by way of example only, with reference to the drawings in which:

[0009] Figure 1An exemplary graphics processing system in which the technology described herein can be implemented is shown;

[0010] Figure 2 Embodiments of the technology described herein are schematically illustrated;

[0011] Figure 3 Embodiments of a cache system of a graphics processing system are shown in more detail; Figure 2

[0012] Figure 4 Another embodiment of a cache system of a graphics processing system is shown in more detail; Figure 2

[0013] Figure 5 Embodiments of a data encoder are shown in more detail;

[0014] Figure 6 An arrangement of data used in embodiments of the technology described herein is shown;

[0015] Figure 7 is a flowchart showing operations in reading data from a cache in embodiments of the technology described herein;

[0016] Figure 8 is a flowchart showing operations in writing data from a graphics processor to a cache in embodiments of the technology described herein;

[0017] Figure 9 is a flowchart showing operations in evicting data from a cache in embodiments of the technology described herein;

[0018] Figure 10 A cache according to one embodiment is shown in more detail; and

[0019] Figure 11 The structure of a cache line according to one embodiment is shown.

[0020] Where appropriate, like reference numbers have been used throughout the drawings to denote like elements. DETAILED DESCRIPTION

[0021] A first embodiment of the technology described herein comprises a method of operating a data processing system, the data processing system comprising:

[0022] a processor;

[0023] a memory system; and

[0024] ​​a cache system configured to transfer data stored in the memory system to the processor for use by the processor in performing data processing operations, and to transfer data from the processor to the memory system;

[0025] The cache system comprises a cache configured to receive data from the memory and provide the data to the processor for use in performing data processing operations, and to receive data from the processor to send to the memory,

[0026] The cache comprises a plurality of cache lines, each cache line being capable of storing a respective data entry;

[0027] The method comprises:

[0028] When a data block stored in compressed form in the memory is to be loaded into the cache, the compressed data block has an associated set of compression metadata:

[0029] storing the data block into a group of one or more cache lines of the cache; and

[0030] providing the compression metadata of the data block as separate sideband data associated with a cache line in the group of one or more cache lines of the cache in which the data block is stored.

[0031] A second embodiment of the technology described herein comprises a data processing system, the data processing system comprising:

[0032] a processor;

[0033] a memory system; and

[0034] a cache system configured to transfer data stored in the memory system to the processor for use by the processor in performing data processing operations, and to transfer data from the processor to the memory system;

[0035] The cache system comprises a cache configured to receive data from the memory and provide the data to the processor for use in performing data processing operations, and to receive data from the processor to send to the memory,

[0036] The cache comprises a plurality of cache lines, each cache line being capable of storing a respective data entry;

[0037] The data processing system further comprises:

[0038] a cache control circuit configured to:

[0039] When a data block stored in compressed form in a memory is to be loaded into a cache, the compressed data block has an associated set of compression metadata:

[0040] storing the data block into a group of one or more cache lines of the cache; and

[0041] obtaining the compression metadata of the data block as separate sideband data.

[0042] In these embodiments, the techniques described herein relate to a data processing system comprising a cache system operable to transfer data from (e.g. main) memory system to a processor that requires the data, and vice versa. For example, the memory system can store data that a data processor can require.

[0043] The data processor can be arranged to perform data processing operations (using data, e.g. in uncompressed format), such as generating a rendered output (e.g. a frame, e.g. for display) in the case of a graphics processor. In order to reduce the amount of data that needs to be transferred to and from memory, the data is stored in compressed form in the memory system. Accordingly, the compressed data has associated “compression metadata” (which can broadly constitute part of “header” data, and thus can also be referred to as “header” data), which may, for example and in one embodiment, comprise compression parameters and the like, indicating how (and if) the data was encoded (compressed) (and correspondingly, how the data should be decoded (decompressed), e.g. when loaded from memory for use by the processor in uncompressed format).

[0044] The cache system comprises a cache arranged to receive and store data from the memory system, to transfer the data from the memory system to the data processor (so that the data processor can use the data to perform data processing operations), and vice versa.

[0045] When data is to be written to (or written out from) the cache (which may, for example and in one embodiment, comprise data of a data array that the processor is processing, the data array comprising an array of data elements each having an associated data value), this is done by writing a corresponding data block (which may, for example, represent a particular region of the data array that the processor is processing) into (or out from) the cache. For example, in the case of graphics processing, the overall data array can be an image (frame), and the data block may, for example, represent a particular region of the data array that the graphics processor is able to operate on (which may, for example, correspond to a tile into which the overall data array (e.g. frame) has been divided for rendering purposes).

[0046] In the techniques described herein, in these embodiments, when a data block (e.g., of a data array) that is to be stored in memory in compressed form is loaded from memory into a cache, the data block (payload) is stored in a respective set of one or more cache lines in the cache. At the same time, compression metadata associated with the compressed data block is provided to the cache as separate "sideband" data, and is stored as separate sideband data associated with the cache line(s) in the set of one or more cache lines in which the data block is stored.

[0047] The compression metadata provided as separate sideband data in this manner can then be read (e.g., by a controller of the cache) and used to determine how and whether the data block should be processed (decoded) into, for example, uncompressed form in which the data block can be used by a processor.

[0048] For example, in one embodiment, data is stored in uncompressed form in the cache, and in one embodiment, data is encoded (compressed) when written out from the cache to the memory system (and correspondingly, decoded (decompressed) when written from the memory system to the cache), as will be explained further below.

[0049] In one embodiment, a block-based encoding (compression) scheme is used to write (and store) data blocks in memory (and in one embodiment, the data blocks thus correspond to compression units, with each block being encoded / decoded individually).

[0050] Thus, the compression metadata associated with a data block and each data block can include compression parameters for the data block, etc., that indicate how and whether the data block should be decoded (decompressed), e.g., when it is written into the cache.

[0051] Thus, the associated compression metadata for a data block provided as such sideband data can be read during a memory read transaction, and used to determine whether and how to process (decode) the data block.

[0052] Correspondingly, when a data block (e.g., of a data array) that is resident in the cache is to be written out from the cache into memory to be stored in compressed format, the compressed data block (i.e., the "payload") is written into a respective data structure (e.g., a region of memory) in the memory system.

[0053] For example, after a data block has been loaded from memory into cache, once the data block has been used, the data block can then be selected for eviction, and evicted, to free space in the cache for new data, after which the data block is compressed as it is written out of the cache to memory, and thus in an embodiment, a new (updated) set of compression metadata is generated for the data block.

[0054] The (updated) compression metadata for the data block is then stored in a corresponding separate header data structure (e.g., in memory) (such that the header data for the block, and in an embodiment, each block, includes the compression metadata stored in a separate data structure, e.g., in a separate area of memory, to the data block itself (payload)), and in an embodiment, any other suitable “header” data for the data block can advantageously be stored in this manner.

[0055] Storing and providing the compression metadata as separate “sideband” data can provide various benefits (e.g., as compared to storing the compression metadata with the payload data, e.g., together as part of a single data structure, in a dedicated header block), as will be further explained below.

[0056] In particular, storing the compression metadata as separate sideband data can provide various benefits when the processor operates to write out (or read in) multiple such data blocks that are arranged together (in memory) as a corresponding data structure, e.g., and in an embodiment, corresponding to a single “page” of physical memory.

[0057] Thus, in an embodiment, a corresponding group of multiple such blocks are grouped together, and arranged in memory as a single corresponding data structure, e.g., and in an embodiment, corresponding to a “page” of the memory system, e.g., that will be written out (or read in) in a single memory transaction.

[0058] For example, in an embodiment, the data structure (memory page) in the memory in which the multiple data blocks are stored comprises a set of contiguous (physical) memory addresses. Arranging the data structure in this manner, e.g., with the data structure storing multiple data blocks organized in a memory page, and e.g., with the data structure (e.g., memory page) having a single physical base address, can facilitate, e.g., simplifying physical addressing needed for use relative to the data blocks in memory, etc.

[0059] Thus, while embodiments have been described above with respect to a single data block to be written to (or written out from) the cache, it will be appreciated that multiple data blocks (e.g. corresponding to a single data structure, such as a memory page) can be written to (or written out from) the cache together in an embodiment.

[0060] Each of the plurality of data blocks (across the data structure, e.g. a memory page) is then stored in the same way as described above. Thus, in the techniques described herein, the compression metadata (header data) for each data block stored in the cache is stored separately from the data block, and is provided as (separate) sideband information appropriately associated with the data block.

[0061] Thus, in embodiments, the techniques described herein comprise loading a plurality of compressed data blocks from a memory system into a cache, each compressed data block having a respective set of associated compression metadata, wherein the compression metadata for each block is provided as separate sideband data. In this case, each of the plurality of data blocks is stored into a respective set of one or more cache lines of the cache, and the respective compression metadata for each block is provided as separate sideband data associated with the cache lines in the set of one or more cache lines of the cache in which the respective data block is stored.

[0062] This means that, rather than storing the compression metadata (header data) in the cache with the payload, for example, it is stored in a dedicated header block containing the associated compression metadata for a plurality of data blocks (e.g. corresponding to a single memory “page”), and in an embodiment the compression metadata (header data) can be stored and provided separately for each data block stored in the cache (in a sideband data structure).

[0063] In this way, by storing the compression metadata for a block as separate sideband information associated with each data block (and more specifically, with the set of cache lines in which each data block is stored), the memory addressing scheme can be further simplified, e.g. as there is no need to leave space in the data structure (memory page) to store the compression metadata. This in turn facilitates more regular addressing logic.

[0064] Storing the compression metadata in this way can also simplify cache “slicing” integration, e.g. where the cache is divided into a plurality of separate physical portions (“slices”), with each slice storing respective data, e.g. for a respective processing core of a processor (and the cache being “sliced” in embodiments of the techniques described herein).

[0065] For example, in an embodiment, a single physical "page" of memory can be divided into multiple data blocks, with different data blocks striped into different cache slices. Each data block is stored using a set of cache lines that reside in the same cache slice. Since the compression metadata for a given data block is stored as sideband information associated with the set of cache lines in which the data block is stored, the compression metadata can be accessed locally to the slice, such that no communication across different cache slices is needed (e.g., which can be the case if the compression metadata is stored in the cache, e.g., in a dedicated header block, which can reside in a different cache slice than the given data block).

[0066] Furthermore, storing the compression metadata in a separate sideband data structure can allow better utilization of available cache space. For example, in an embodiment, each data block corresponds to an integer number of cache lines in size, with each data block in an embodiment being the same size, e.g., to simplify addressing. However, the associated compression metadata for a block (or a collection of blocks within a data structure, e.g., a memory page) can not typically fill an entire set of cache lines.

[0067] Accordingly, storing the compression metadata in a dedicated header block in the cache along with the payload can mean that the set of cache lines storing the header block is not fully utilized. In contrast, in the techniques described herein, the cache lines can be (more) fully utilized for storing payload data.

[0068] Accordingly, the techniques described herein recognize that storing the compression metadata as a separate sideband of information can facilitate improved cache operation, e.g., as compared to other approaches for storing associated header data at least in the above-described contexts.

[0069] The sideband header data can be stored in a separate physical region of memory (the same as) the data block, or the header data can reside in a separate memory, e.g., in a dedicated cache for storing such data.

[0070] The sideband data structure in which the compression metadata is stored / provided can be any suitable sideband data structure that can be associated with a cache line.

[0071] The sideband data structure in which the compression metadata is stored / provided can be any suitable sideband data structure that can be associated with a cache line.

[0072] In one embodiment, the sideband data structure is a separate data structure that is stored apart from the cache line itself.

[0073] For example, and in some embodiments, the compression metadata can be stored in a dedicated memory portion allocated for storing (physically "carving out") the compression metadata. Thus, the compression metadata can be provided, for example, in the form of a "tag" as an additional sideband signal along with its associated cache line from its dedicated memory portion. The compression metadata can also be cached at some point in the data processing system in a suitable compression metadata cache, which, for example, in one embodiment is separate from the cache used to store the data blocks themselves.

[0074] In other embodiments, the compression metadata for a cache line can be stored as part of the metadata stored with (in) the cache line itself, for example, in the cache line tag (or "key") that identifies the data stored in the cache line.

[0075] For example, each cache line will typically be associated with appropriate metadata, including an identifier (cache line tag or key) that identifies the data stored in the cache line (e.g., in the form of a memory address). The cache line metadata may, for example, include a plurality of data fields (each data field including a plurality of bits), and in some embodiments, one such data field, such as a portion of the cache line tag (key), is used to signal the compression metadata in the cache line metadata. However, other arrangements for storing / providing would be possible.

[0076] In this regard, the techniques described herein also recognize that there can be existing sideband data structures or data fields in such data structures that can be (re)used to store header information, and in one embodiment, are.

[0077] Thus, in some embodiments, each (compressed) data block can generally have associated header data structures that include one or more data fields for storing any suitable and desired header data for the data block. In embodiments, one or more of such data fields are used to store compression metadata that would otherwise be used to signal other information (but the techniques described herein do not require the other information).

[0078] For example, in one embodiment, a memory "tag" provided for the purpose of mitigating memory security violations is used to store compression metadata (re-purposed). For example, memory locations can be "tagged" by adding metadata (memory tag) of multiple bits to each region of physical memory (e.g., four bits per 16 bytes of physical memory).

[0079] When such memory tagging is enabled, the memory tag enables lock-and-key access to memory locations. For example, when data is written to a memory location (physical memory address), a "lock" can be set, and a "key" provided during memory access. For example, the pointer (and hence the virtual address / cache line) can be suitably modified to include the key. Thus, each cache line can have an associated plurality of bits for signaling the memory tag. If the key matches the lock, the memory access is allowed. If it does not, an error is reported.

[0080] An exemplary use case for such memory tagging would be for buffer coloring, for example to avoid buffer overruns / under-runs. However, for use cases that do not use buffer coloring, the techniques described herein recognize that the memory tag bits can be used to signal associated header data, for example for data stored in that cache line (or a group of cache lines including that cache line).

[0081] Thus, such memory tagging can be selectively enabled. In cases where memory tagging is not needed (and hence not enabled), the memory tag (i.e. bits) will nonetheless be transmitted for the cache line. Thus, embodiments of the techniques described herein recognize that these existing memory tag bits can advantageously be re-purposed, for example in the manner described above, to store associated header data.

[0082] It is a benefit that these data structures (e.g. memory tags) are implicitly available, such that no additional sideband data structures or side channels need to be introduced into the data processing system for storing compression metadata in the manner of the techniques described herein. However, various other arrangements would be possible.

[0083] In one embodiment, the sideband data structure (e.g. memory tag) including the compression metadata for a given block is associated with (and only with) one of the group of cache lines storing the data block, and in one embodiment is associated with the first cache line. Thus, in one embodiment, when the data block is accessed, the first cache line of the group of cache lines of the data block, for example, and its associated sideband data is always read, for example to read the compression metadata and determine how to process the data block and whether to process the data block. This then avoids the need for a separate header lookup or the like.

[0084] However, other arrangements would be possible, and the compression metadata can be stored in respective sideband data structures associated with more than one or all of the cache lines in the group of cache lines. This can be desirable, for example, if the compression metadata does not fit in the available bits of the memory tag of a single cache line.

[0085] It is believed that storing compressed metadata in existing data fields in the manner described above can be novel and advantageous in itself.

[0086] Another embodiment of the technology described herein includes a method of operating a data processing system, the data processing system comprising:

[0087] a processor; and

[0088] a memory system;

[0089] The method comprises:

[0090] When a data block is to be stored in compressed form in the memory, the compressed data block has an associated set of compression metadata:

[0091] storing the data block into a respective data structure in the memory; and

[0092] storing the compression metadata in a separate header data structure, the header data structure comprising one or more data fields, and wherein the compression metadata is stored in a data field that will be used for other information in a different mode of operation.

[0093] Another embodiment of the technology described herein includes a data processing system, the data processing system comprising:

[0094] a processor; and

[0095] a memory system; and

[0096] control circuitry configured to:

[0097] When a data block is to be stored in compressed form in the memory, the compressed data block has an associated set of compression metadata:

[0098] storing the data block into a respective data structure in the memory; and

[0099] storing the compression metadata in a separate header data structure, the header data structure comprising one or more data fields, and wherein the compression metadata is stored in a data field that will be used for other information in a different mode of operation.

[0100] It will be appreciated that the technology described herein according to these embodiments can generally include any (or all) of the features described above in relation to other aspects and embodiments of the technology described herein, at least to the extent that they are not mutually exclusive.

[0101] For example, in one embodiment, the data processing system in these additional embodiments comprises a cache system comprising a cache operating in one embodiment in the manner described above.

[0102] In addition, the header data structure in these further embodiments can comprise a data structure as described above in an implementation. In this case, the data field may, for example, comprise a data field that is otherwise used to store a memory tag of the type described above.

[0103] Thus, it can be seen that embodiments of the technology described herein relate to improved mechanisms for storing compressed metadata, in particular in cases where the compressed metadata is stored and separately provided to the payload data (in one embodiment, by reusing existing data structures). The data processing system of the technology described herein comprises a memory system, a data processor, and a cache system.

[0104] The memory of the data processing system (memory system) can comprise any suitable and desired memory and memory system of the data processing system, such as and in one embodiment, a main memory for the particular processor under consideration (e.g., where there is a separate memory system for the processor), or a main memory of the data processing system that is shared with other elements of the data processing system, such as a host processor (CPU).

[0105] The processor of the data processing system can comprise any suitable and desired processor of the data processing system, such as a CPU (central processing unit), a GPU (graphics processing unit), a DPU (display processing unit), a VPU (video processing unit), an ISP (image signal processor), etc. In one embodiment, it comprises a GPU (graphics processing unit).

[0106] The processor should and in one embodiment does comprise one or more processing cores (and in one embodiment, a plurality of), which are operable to perform processing operations on data to be processed by the processor.

[0107] Correspondingly, the cache system and cache are configured in one embodiment to provide data to the one or more processing cores of the processor for use in performing processing operations, and to receive data from the one or more processing cores of the processor for sending to the memory system, respectively.

[0108] The data transferred using the cache, as well as the data blocks to be written into the cache, can be any suitable and desired data and blocks of that data on which the data processor can operate. For example, and in one embodiment, the data blocks to be written into the cache comprise data blocks of a (larger) data array that the data processor is processing, which data array and data blocks (each) comprise an array of data elements, each data element having an associated data value.

[0109] In the case of a graphics processor, the data array can include, in one embodiment, for example, an image being processed by the graphics processor, and thus the data will include appropriate (e.g., color) values for the data elements (sample locations) of the data array; and the image is the image represented by the data array. In this case, the data array can include, for example, a frame (frame buffer) being processed by the graphics processor, e.g., for display; and / or data used or generated by the graphics processor, such as a graphics texture. In other arrangements, the data can include geometry data, such as geometry data for vertices and / or primitives being processed by the graphics processor. Thus, in one embodiment, the data stored in the cache and processed in the manner described herein includes image data (e.g., a texture or frame) or geometry data (locations and / or attributes).

[0110] Thus, in one embodiment, the data array to be stored in the memory and the data blocks processed in the manner described herein include image data (e.g., a texture or frame) or geometry data (locations and / or attributes). Thus, in one embodiment, the data blocks (to be) stored in the cache and for which the associated header data is stored in the above-described manner include image or geometry data blocks (e.g., tiles) representing particular regions of a frame of image data.

[0111] The data processing operation being performed by the (e.g., graphics) processor using the data array can correspondingly be any suitable and desired (e.g., graphics) processing operation that the (e.g., graphics) processor can perform. Thus, it can be, for example, an appropriate graphics geometry processing operation or a fragment (pixel) shading operation, etc. In one embodiment, the processing operation is a graphics shading operation, such as a geometry shading, vertex shading, or fragment shading operation. The operation can also be a compute shading operation, where the (e.g., graphics) processor is performing a compute shading operation.

[0112] The data block (written to the data structure and for which the header data is stored) can represent any suitable and desired region of the data array. For example, the data block can represent the entire data array (e.g., only a single data block can be written out for the entire data array).

[0113] However, in one embodiment, the data block represents a portion (less than the entirety) of the data array. In one embodiment, the data array includes a plurality of data blocks. In one embodiment, the plurality of data blocks represent a respective plurality of regions (zones) of the data array.

[0114] Accordingly, in one embodiment, the method is performed (and the processor is configured to, inter alia, write out data blocks and store associated header data in respective sideband data structures) for a plurality of blocks (e.g., each of which) that make up some or all of the overall data array. As described below, there are a number of different ways in which this can be achieved.

[0115] In one embodiment, the data array comprises a data array of a stream of data arrays (e.g., a stream of frames of image data) that are to be processed in the manner described herein. Accordingly, in one embodiment, the method is performed (and the processor is configured to, inter alia, write out data blocks and store associated headers) for a plurality of data arrays (e.g., each of which) of the stream of data arrays.

[0116] When the data array is to be represented by a plurality of data blocks, in one embodiment, the method comprises (and the processor is configured to) divide the data array into a plurality of data blocks. Each of the plurality of data blocks can then be processed in accordance with the method of the technology described herein.

[0117] The data blocks into which the data array is divided can each represent any suitable and desired region (area, e.g., tile) of the data array (e.g., frame of image data) on which the processor is able to operate. In one embodiment, each data block represents a different region of the overall data array (although the blocks can overlap, if desired). Each block should represent an appropriate region (zone) of the data array, such as a plurality of data locations (e.g., pixels of image data) within the array.

[0118] In one embodiment, the data blocks of the data array are rectangular in shape, e.g., square. The rectangular blocks can be of any suitable and desired size. In one embodiment, the rectangular blocks each have a size of between 4 x 4 data elements (sample locations, e.g., pixels) and 64 x 64 data elements, inclusive, in one embodiment, each edge of the rectangular blocks has a size of 2n data elements, where n is an integer (e.g., between 2 and 6, inclusive). For example, the blocks can correspond to rendered tiles (e.g., 16 x 16 sample locations) of, e.g., a frame of image data. Of course, other arrangements and sizes are possible. n

[0119] As noted above, in embodiments, a plurality of such data blocks are arranged together as part of a single data structure, e.g., and in one embodiment, corresponding to a single "page" of memory.

[0120] ​In one embodiment, each data block in the data structure has the same particular (e.g., predefined) size. In one embodiment, the size of each data block is based on and corresponds to the amount of data that can be processed in a respective memory transaction (burst) in the processing system. Thus, in one embodiment, each data block in its uncompressed form corresponds to an integer number of cache lines, such as and in one embodiment, four cache lines.

[0121] In one embodiment, the data structure comprises a single (e.g., 4 kB) page of memory (e.g., comprising a set of contiguous memory addresses). The (e.g., 4 kB) page of memory can be arranged in any suitable and desired manner. In one embodiment, the data structure (e.g., the page of memory) comprises 16 (e.g., 256B) regions of "payload" blocks (for (e.g., graphics) processing operations) for storing data of a data array. In the techniques described herein, each region (data block) has associated ("sideband") header information stored in a respective independent data structure.

[0122] A given data array (e.g., representing an image or a region of an image) can then be divided and stored, for example, as one or more (e.g., multiple) such pages (e.g., pages of size 4 kB) in memory, for example, as a buffer. Of course, other sizes of memory pages and blocks are possible.

[0123] In the techniques described herein, in embodiments using a block-based encoding (compression) scheme, the data blocks are written (and stored) in memory in an encoded (e.g., compressed) format.

[0124] Thus, as described above, the data blocks in the embodiments correspond to compression units, with each block thus being encoded / decoded individually. In this case, the (each) block in the embodiments (when uncompressed) corresponds to an integer number of cache lines that make a read request to the cache of, for example, 4 or 8 cache lines. (Thus, in terms of 64 byte cache lines, each data block in its uncompressed form can for example comprise and be stored as a 256 or 512 byte data block.)

[0125] Encoding of the data blocks can be performed by any suitable and desired element (e.g., processing unit) of or associated with the processor. For example, the encoding can be performed by a shader core of the (e.g., graphics) processor or by an (e.g., external) encoder associated with the processor or memory.

[0126] However, in one embodiment, encoding is performed by a data encoder associated with the cache, as will be explained further below. In one embodiment, data is thus stored in the cache in unencoded (e.g., uncompressed) format, and is encoded (compressed) when it is written from the cache to the memory. Correspondingly, data is decoded (decompressed) when it is written from the memory to the cache.

[0127] Thus, in one embodiment, the cache system further comprises a data encoder associated with the cache. In one embodiment, the data encoder is arranged to encode (compress) uncompressed data from the cache when that data is to be written from the cache to the memory system, and to send the compressed data to the memory system for storage. In one embodiment, the data encoder is also arranged to decode (decompress) compressed data from the memory system when that data is to be read (retrieved) from the memory system into the cache (and written into the cache), for storage in uncompressed format in the cache. Thus, in one embodiment, the encoder reads in data from the memory system in uncompressed form into the cache and stores it in the cache, and returns the data to the memory system in compressed form.

[0128] It will be appreciated that by providing a data encoder / decoder and associating (e.g., integrating) it with the cache, this allows compression (encoding) and decompression (decoding) of data (as appropriate) that is to be transferred (and stored, e.g., temporarily in the cache while used by the graphics processor) between the graphics processor and the memory system to be performed by the cache system itself. This helps facilitate use of the graphics processing system with newer APIs (application programming interfaces) such as Vulkan, while maintaining proper synchronization of compressed data stored in the memory system.

[0129] One or more blocks of the data array can be encoded (compressed) using any suitable and desired encoding (compression) technique. In one set of embodiments, the method comprises (and the processor is configured to) encode one or more blocks of the data array using the frame buffer compression techniques described in Applicant’s patents US 8,542,939 B2, US 9,014,496 B2, US 8,990,518 B2, and US 9,116,790 B2. In one set of embodiments, the method comprises (and the processor is configured to) additionally or alternatively (and in one embodiment also) encode one or more blocks of the data array using a fixed rate compression technique.

[0130] Thus, the data encoder can be configured to perform any suitable and desired encoding (e.g., compression) and decoding (e.g., decompression) operations, e.g., depending on the compression format that can be used for the data.

[0131] Thus, the data encoder should and in one embodiment does comprise a suitable codec (data encoder / decoder) which is operable and configured to encode (compress) data to be written from the cache to the memory system, and to decode (decompress) data to be read from the memory system into the cache.

[0132] As mentioned above, a compressed data block has associated compression metadata which in one embodiment is stored as part of a sideband header data structure for the data block.

[0133] Thus, the compression metadata for a given data block can in one embodiment comprise one or more of, and in one embodiment all of: an indication of whether the data block is stored in compressed format in the memory; any required compression parameters / state, such as an indication of the compression format that has been used for the data block; and an indication of the number of memory transactions (bursts) that will be required to read the (compressed) data of the data block under consideration from the memory (this can be appropriate where a variable rate compression scheme is used, so it is desirable to indicate how much data needs to be fetched from the memory for each individual data block).

[0134] In addition to the compression metadata, any other suitable and desirable data that can be appropriate for the data block can be stored as header data in the sideband header data structure for the data block.

[0135] For example, the header data for a data block can also in one embodiment comprise, inter alia, a signature of the respective indicated contents of the block, for example in the form of a cyclic redundancy check (CRC).

[0136] From the above it will be appreciated that embodiments of the technology described herein can thus provide improved cache operation, for example and in one embodiment simplifying the physical addressing that needs to be used in respect of data blocks in the memory etc.

[0137] The cache system can be any suitable and desirable cache system which is operable and configured to hold data between the processor(s) (one or more processing cores of the processor) and the memory system. Thus, it can be for example a system cache which is shared between multiple processors, or a cache for a particular processor.

[0138] The cache system can comprise a single cache "level", in which case it will be a cache level which is operated in the manner of the technology described herein.

[0139] In an embodiment, the cache system comprises multiple cache levels (a cache hierarchy), such as LI and L2 caches. In this case, the cache operating in the manner of the technology described herein is a cache level, is a level of the cache system, and in an embodiment, is a cache level closer to the graphics processor (processing core of the graphics processor), and in an embodiment, is a cache level from which data is provided to and received from the processing core of the graphics processor of the cache hierarchy, such as and in an embodiment, an L2 cache.

[0140] Thus, in an embodiment, the cache is an L2 cache of the cache system, configured to receive data from the memory system to provide data to the graphics processor for use in performing graphics processing operations, and to receive data from the graphics processor for sending to the memory system, and operates in the manner of the technology described herein.

[0141] Correspondingly, in an embodiment, the data encoder associated with the cache (if provided) is between the L2 cache of the graphics processor and the (external) memory system; and in an embodiment, is integrated into the L2 cache system of the graphics processor.

[0142] In this regard, it will be appreciated that where the cache system comprises multiple cache levels, with only one of the cache levels (e.g. the L2 cache) operating in the manner of the technology described herein, then writing data from the cache to the memory system and reading data from the memory system to the cache (which operates in the manner of the technology described herein) can comprise writing and reading the data from and to a cache level closer to the memory system as appropriate (where the required data can and / or already is cached at a level closer to the memory system itself in the cache system).

[0143] In other words, when reading data from the memory system to the cache in the operation of the technology described herein, the data can be read from a cache level closer to the memory system, and if the data is already available in a cache closer to the memory system, it does not necessarily need to be retrieved from the memory system itself. Correspondingly, when writing data from the cache to the memory system, the operation in the manner of the technology described herein involves an operation in which data is written from the cache towards the memory system, but the data can remain in the cache system at a higher level, closer to the memory system than to the memory system itself.

[0144] Thus, references to writing data from the cache to the memory system and reading data from the memory system into the cache in compressed format generally refer to writing data "towards" the memory system and reading data into the cache, and thus encompass writing data to and / or reading data from a level of the cache system closer to the memory system (e.g. the L3 cache), without necessarily requiring the data to reach the memory system or to be taken from the memory system (although the purpose will generally be for the data to reach or to come from the memory system, the cache system operation will merely avoid the need to actually reach the memory system when writing / reading the data).

[0145] In the case where the cache system comprises multiple cache levels, then the cache system (multiple cache levels) is in one embodiment configured and arranged to be "coherent", i.e. such that all copies of the same data in the cache system (across the cache levels) are kept in sync (ensured to be identical (i.e. such that when one copy of the data changes, the other copies within the cache system and the memory system change to reflect the change)).

[0146] The cache system can operate in any suitable and desired manner otherwise in accordance with the techniques described herein, such as and in one embodiment in accordance with the normal manner of cache operation in the graphics processing system under consideration.

[0147] For example, when the graphics processor requires some input data residing in the memory system, a read request for this data is first issued to the cache system, with the read request passing through the cache and memory hierarchy, i.e. from the graphics processor to the cache system and ultimately to the memory system as required.

[0148] That is, when the requested data exists in the cache of the techniques described herein, the data can then be provided to the graphics processor for processing thereby. On the other hand, when the requested data does not exist in the cache of the techniques described herein, the data must first be fetched from the memory system into the cache (by issuing a memory read request).

[0149] In this case, the data block can then be loaded from the memory into the cache, for example as described above, with the associated compression metadata being provided as separate sideband data. The compression metadata can then be read, and in one embodiment then used to process (e.g. decode) the compressed data block, for example so that it can be stored in the cache in uncompressed form as appropriate.

[0150] In one embodiment, data that has been loaded into the cache is subsequently provided from the cache to the processor for its use. Once the data block has been used, the cache line can be freed up for eviction and the data block written back to memory if required.

[0151] In one embodiment, the eviction (write back) process can include checking whether any data (cache lines) to be read (evicted) has been modified (is "manipulated"). If not, in one embodiment no write back operation is performed and the lines selected for eviction are simply invalidated to make them available for reuse. This avoids performing a write back operation in the case where a copy of the data already exists in the memory system (unmodified).

[0152] On the other hand, if at least some of the data (one of the cache lines) read by the data encoder for eviction has been modified (is "manipulated"), the data needs and should be written back to the memory system because the data in the cache will differ from the data in the memory system.

[0153] In one embodiment, the eviction (write back) process also includes appropriately updating the compression metadata for the data (e.g., data block) written back to the memory system.

[0154] Thus, in one embodiment, the data is appropriately encoded (compressed) to provide a new compressed version of the block. The new compressed version of the block is then written back to the appropriate block of the data structure in memory (to replace the existing version of the block). The compression metadata stored for the block should be appropriately updated and then written out to its appropriate header data structure. Thus, in one embodiment, it is at least updated to indicate how many memory transactions are required to fetch the compressed data block being written back. It can also be updated to indicate additional compression state that can be required for a subsequent decoding (decompression) operation, such as a solid color indication, etc.

[0155] Correspondingly, when the graphics processor has data to write to the memory system, the graphics processor will issue a write request to write that data to the cache and the data will be written to the cache. Then, when the data in the cache falls to be evicted from the cache, that data will be written back to the memory system. At the same time, the updated compression metadata is written back to its corresponding data structure (e.g., in memory).

[0156] The cache can be configured in any suitable and desired manner, e.g., according to the normal cache arrangement of the graphics processor and graphics processing system under consideration.

[0157] Thus, in one embodiment, the cache will comprise a plurality of cache lines, each cache line being able to store a respective one or more data entries. Each cache line will also be associated with appropriate (cache) metadata, such as and in one embodiment one or more of, and in one embodiment all of: an identifier for the data stored in the cache line (a "cache line tag" or key used when performing cache lookups); a "valid" flag (bit) to indicate that the data in the cache line is valid; a "free" flag (bit) to indicate that the cache line is available for allocation to store data; and a "dirty" flag (bit) to indicate that the data in the cache line has been modified since it was written to the cache line from memory. As noted above, in embodiments, compression metadata is stored / provided as part of the cache line tag.

[0158] There can be a single physical cache, or the cache can be divided into a plurality of separate physical parts ("slices"), with each slice storing, for example, respective data, for example for a respective processing core of a processor.

[0159] The cache making the read request can interact with the processor (processing core of the processor) so as to be able to transfer data between them in any suitable and desired manner. In one embodiment, there is an appropriate interconnect, such as an Asynchronous Switched Network (ASN), interfacing between the cache (e.g. L2 cache) and the processor (one or more processing cores of the processor).

[0160] As will be appreciated from the above, in one embodiment, the techniques described herein are implemented in a graphics processing system comprising a memory system, a cache system and a graphics processor (graphics processing unit (GPU)). Data for performing a graphics processing operation (e.g. to generate a rendered output (e.g. an image to be displayed)) is stored in memory of the memory system. The graphics processor is arranged to trigger fetching of the required data from the memory and its storage in the cache system. The graphics processor then reads the required data from the cache system for performing the graphics processing operation (e.g. generating the rendered output). The output from the graphics processing operation (e.g. the rendered output) once generated in this way is then written back to the memory system via the cache system and in one embodiment displayed on a display (such as a phone, tablet, television, computer screen etc.) of an electronic device, for example.

[0161] The graphics processor (graphics processing unit) can and in one embodiment does implement and execute a graphics processing pipeline to perform graphics processing operations.

[0162] The graphics processing pipeline can include, and in one embodiment does include, any one or more of the processing stages that a graphics processing pipeline can typically include, and in one embodiment includes all of the processing stages, such as and in one embodiment including a setup stage, a rasterizer, a renderer (in one embodiment in the form of or including a programmable fragment shader (shader core)).

[0163] In one embodiment, the graphics processor (processing pipeline) also includes one or more programmable shading stages, such as and in one embodiment including all of one or more of a vertex shading stage, a hull shader, a tessellation stage (e.g., in which tessellation is performed by executing a shader program), a domain (evaluation) shading stage (shader), a geometry shading stage (shader), and a fragment shader.

[0164] The graphics processor (processing pipeline) can also include any other suitable and desirable processing stages that a graphics processing pipeline can include, such as a depth (or depth and stencil) tester, a blender, one or more tile buffers, a write out unit, etc.

[0165] In one embodiment, the graphics processing system includes a host processor that executes an application program that can require graphics processing by the graphics processor. In one embodiment, the system also includes suitable storage (e.g., memory), cache, etc., as described above.

[0166] In one embodiment, the various functions of the techniques described herein are performed on a single processing platform.

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

[0168] The techniques described herein can be implemented in any suitable system, such as a suitably configured microprocessor-based system. In some embodiments, the techniques described herein are implemented in a computer and / or microprocessor-based system.

[0169] The various functions of the technology described herein can be performed in any desired and suitable manner. For example, the functions of the technology described herein can be implemented in hardware or software as needed. Thus, for example, the various functional elements and levels of the technology described herein may include one or more suitable processors, one or more controllers, functional units, circuits, processing logic, microprocessor arrangements, etc., operable to perform various functions, such as appropriate dedicated hardware elements (processing circuits) and / or programmable hardware elements (processing circuits) that can be programmed to operate in a desired manner.

[0170] It should also be noted here that, as those skilled in the art will understand, the various functions of the techniques described herein can be copied and / or executed in parallel on a given processor. Similarly, processing levels can share processing circuitry when needed.

[0171] Furthermore, any one or more processing levels of the technology described herein may be embodied as processing level circuitry, for example, in the form of one or more fixed-function units (hardware) (processing circuitry), and / or in the form of programmable processing circuitry that can be programmed to perform desired operations. Similarly, any one or more of the processing levels and processing level circuitry of the technology described herein may be provided as independent circuit elements to other processing levels or processing level circuitry, and / or any one or more or all of the processing levels and processing level circuitry may be formed at least partially by shared processing circuitry.

[0172] Those skilled in the art should also understand that all embodiments of the technology described herein may include any one or more or all of the features described herein, as appropriate.

[0173] The methods described herein can be implemented at least in part using software, such as computer programs. Therefore, it can be seen that, when viewed from another embodiment, the techniques described herein provide: computer software particularly suitable for performing the methods described herein when installed on a data processor; computer program elements including computer software code portions for performing the methods described herein when the program elements are run on a data processor; and a computer program including code suitable for performing all steps of one or more methods described herein when the program is run on a data processing system. The data processing system may be a microprocessor, a programmable FPGA (Field-Programmable Gate Array), etc.

[0174] The techniques described herein also extend to computer software carriers that, when used to operate a graphics processor, renderer, or other system including a data processor, cause said processor, renderer, or system to perform the steps of the methods described herein in conjunction with said data processor. Such computer software carriers can be physical storage media, such as ROM chips, CD-ROMs, RAM, flash memory, or disks, or they can be signals, such as electronic signals transmitted through wires, optical signals, or radio signals, such as signals to satellites.

[0175] It should also be understood that not all steps of the method described herein need to be performed by computer software. Therefore, in contrast to another broad implementation, the technology described herein provides computer software and such software installed on a computer software carrier for performing at least one step of the method described herein.

[0176] Therefore, the techniques described herein may suitably be embodied as a computer program product used with a computer system. Such embodiments may include a series of computer-readable instructions fixed on a tangible, non-transitory medium, such as a computer-readable medium, for example, a disk, CD-ROM, ROM, RAM, flash memory, or hard disk. It may also include a series of computer-readable instructions that can be invisibly transmitted to a computer system via a modem or other interface device, through a tangible medium (including but not limited to optical or analog communication lines), or using wireless technologies (including but not limited to microwave, infrared, or other transmission technologies). This series of computer-readable instructions embodies all or part of the functions previously described herein.

[0177] Those skilled in the art will understand that such computer-readable instructions can be written in a variety of programming languages ​​to be used with many computer architectures or operating systems. Furthermore, such instructions can be stored using any current or future memory technology (including, but not limited to, semiconductor, magnetic, or optical technologies), or transmitted using any current or future communication technology (including, but not limited to, optical, infrared, or microwave technologies). It is conceivable that such computer program products can be distributed as removable media with accompanying printed or electronic documentation (e.g., shrink-wrapped software), pre-loaded onto a computer system (e.g., system ROM or fixed disk), or distributed from servers or electronic bulletin boards via networks (e.g., the Internet or the World Wide Web).

[0178] Several implementations of the techniques described herein will now be described in the context of graphics processing systems.

[0179] Figure 1 An exemplary graphics processing system in which the techniques described herein and this embodiment can be implemented is shown.

[0180] Figure 1 The exemplary graphics processing system shown includes a host processor, which includes a central processing unit (CPU) 1, a graphics processing unit (GPU) 10, a video codec 2, a display controller 3, and a memory controller 4. Figure 1 As shown, these units communicate via interconnect 5 and have access to an off-chip memory system (memory) 6. In this system, the GPU 10, video codec 2, and / or CPU 1 generate frames (images) to be displayed, and the display controller 3 then provides the frames to the display 7 for display.

[0181] In the use of this system, an application 8 (such as a game) executing on the host processor (CPU) 1 will, for example, need to display frames on the display 7. To do this, the application 8 will send appropriate commands and data to the driver 9 executing on the CPU 1 for the graphics processing unit 10. The driver 9 will then generate appropriate commands and data to cause the graphics processing unit 10 to render appropriate frames for display and store those frames in appropriate frame buffers, such as in main memory 6. The display controller 3 will then read these frames into the display's buffer, then read them from the buffer and display them on the display panel of the display 7.

[0182] As part of this process, the graphics processor 10 reads data (such as textures, geometry to be rendered, etc.) from the memory 6, processes the data, and then returns the data to the memory 6 (e.g., in the form of processed textures and / or frames to be displayed). This data is then further read from the memory (e.g., by the display controller 3) for display on the display 7, as discussed above. Therefore, data will need to be transferred to and from the graphics processor 10 (particularly to and from the processing core of the graphics processor 10) and the memory 6.

[0183] To facilitate this, and to reduce the amount of data that needs to be transferred to and from memory during graphics processing operations, data can be stored in memory in a compressed form.

[0184] Since the graphics processor 10 needs to operate on (and will produce) data in uncompressed form, this means that data stored in compressed form in memory will first need to be decompressed before being processed by the graphics processor. Correspondingly, the data produced by the graphics processor 10 will first need to be compressed before being (finally) stored in memory 6.

[0185] Specifically, this implementation relates to improved techniques for performing such compression and decompression of data between memory 6 and graphics processor 10.

[0186] Figure 2 The components of a graphics processing system, schematically and in more detail, are related to the operation of this embodiment and specifically to the transfer of data to and from the memory system 6 and the graphics processor 10 in compressed form. As those skilled in the art will understand, the system may have... Figure 2 Other components not shown in the diagram, etc.

[0187] Figure 2 The memory system 6 and the graphics processor 10 are shown. (See diagram.) Figure 2 As shown, between the memory system 6 and the graphics processor 10, there is a cache system 20 that is operable to transfer data from the memory system 6 to the graphics processor 10 (and specifically to the processing core (shader core) 25 of the graphics processor 10), and conversely, to transfer data generated by the processing core 25 of the graphics processor 10 back to the memory 6.

[0188] Figure 2 The cache system shown is illustrated as comprising two cache levels: an L3 cache 21 closer to memory 6, and an L2 cache 24 closer to the graphics processor 10 (from which data is supplied to the shader core 25). Other cache hierarchy arrangements are possible if desired, such as including only a single cache level (L2 cache) or more than two cache levels.

[0189] like Figure 2 As shown, in this embodiment, data is transferred from memory system 6 to L3 cache 21, then from L3 cache 21 to L2 cache 24, and from L2 cache 24 to shader core 25 (and vice versa).

[0190] To facilitate the processing of compressed data from memory system 6 when needed (and for returning compressed data to memory system 6), such as Figure 2 As shown, the L2 cache 24 has a data encoder 22 associated with it (in the form of a memory page compression unit (MPC)).

[0191] As will be discussed further below, the data encoder is operable to decompress data received from the memory system 6 via the L3 cache 21 and then store the data in uncompressed form in the L2 cache system 24 for use by the graphics processor's shader core 25. Conversely, it is operable to compress data to be evicted from the L2 cache system 24 and then write the data back to the memory system 6 (again via the L3 cache 21). The operation of the data encoder (MPC) 22 will be discussed in more detail below.

[0192] like Figure 2 As shown, the L2 cache 24 also includes appropriate interconnects 23 (in this case, in the form of an asynchronous switching network) for transferring data between the L2 cache 24 and the shader core 25.

[0193] To facilitate operation between the L2 cache and the data encoder (MPC) 22, each cache line in the L2 cache has an appropriate tag and data associated with it to indicate whether the cache line should be processed by the data encoder (MPC) 22.

[0194] Figure 3 and Figure 4 The arrangement of the L2 cache 24, the data encoder (memory page compression unit) 22 and the shader core 25 in two possible specific implementations of this embodiment are shown in more detail.

[0195] exist Figure 3 and Figure 4 Of the two, L2 cache 24 is shown as being configured as a corresponding separate physical cache portion (slice) 30. Figure 3 In this arrangement, each corresponding L2 slice has its own associated data encoder 22. Figure 4 In the arrangement shown, instead of each L2 cache slice 30 having its own associated data encoder 22, there is a single data encoder 23 operating for all L2 cache slices 30, which is instead coupled to and associated with the interconnect 23 that operates between the L2 cache 24 and the shader core 25 of the graphics processor.

[0196] Figure 5 An embodiment of the data encoder (memory page compression unit) 22 in this embodiment is shown. For example... Figure 5 As shown, the data encoder (and each data encoder) includes a corresponding read unit 60 and write unit 61 (circuit), operable to read data from the L2 cache and memory system, and to write data to the L2 cache and memory system, respectively. The data encoder 22 also includes a suitable control unit (circuit) 62 that receives read and write requests from the shader core and the L2 cache controller, and controls the data encoder 22 to respond appropriately to those requests.

[0197] like Figure 5 As shown, the data encoder 22 also includes a set of one or more codecs 63, 64 and data buffers 65 for temporarily storing data in the data encoder 22 while processing the data and / or while waiting to write the data to the L2 cache or memory system.

[0198] The data encoder 22 may include any desired number of codecs, each operable to perform a different encoding (compression) scheme. For example, one codec may be configured to perform an appropriate variable-rate compression scheme, while another codec is configured to perform an alternative, such as a fixed-rate compression scheme. Of course, other arrangements are also possible.

[0199] In this embodiment, the data processed by the graphics processor (e.g., a data array) is stored in memory 6 as corresponding data blocks (blocks of the data array), wherein each data block is stored in memory 6 in compressed form, but in L2 cache 24 in uncompressed form for use by the shader core 25 of the graphics processor 10.

[0200] To facilitate this operation, in this embodiment, the data array is stored and organized in memory as a group of multiple data blocks, with each data block corresponding to a single memory "page".

[0201] Figure 6 This is shown, and a set 70 of sixteen data blocks 72 that will be stored together as a single memory “page” is shown.

[0202] exist Figure 6 In this embodiment, each data block 72 is stored in the cache (in uncompressed form) using a set of four cache lines 73. In this embodiment, the header data (i.e., compressed metadata) associated with each data block in the data block 72 is stored in a corresponding sideband data structure as a memory “tag” (MTE) 74 associated with the first cache line 73-1 in the set of cache lines 73 storing the data block 72.

[0203] Memory tags consist of multiple bits (e.g., four bits per 16 bytes, so a 64-byte cache line has 16 bits). Such memory tags could be provided, for example, for purposes such as mitigating memory security breaches. However, in this embodiment, memory tags are disabled, and the bits are reused to store compressed metadata.

[0204] Therefore, as Figure 6 As shown, compressed metadata (header data) is locally associated with each data block 72. This helps facilitate cache integration. For example, in Figure 6 In this context, each cache line 73 can be stored in a separate cache "slice".

[0205] This also means that all cache lines can be used entirely to store payload data (and the size of the memory pages and the data blocks into which the memory pages are divided can be selected, making this possible).

[0206] The corresponding memory tag 74 of data block 72 may include any suitable and desired header data to be stored for data block 72. This may include, for example, an indication for each corresponding data block: whether the data block is stored in compressed form (and (some) the compression state required to decode (decompress) the block if necessary), and / or how many memory transactions (bursts) will be required to retrieve the data of that block from memory (in its compressed form). (The latter may be desirable because while each data block is configured to occupy an integer number of cache lines in its uncompressed form, when compressed, especially if a variable-rate compression scheme is used, the data can be compressed to a different (and smaller) number of cache lines (and therefore the corresponding memory transactions), and the data can differ between blocks. Therefore, it is useful if the header block indicates how many memory transactions are required to retrieve the complete compressed data set of (each) data block from memory.)

[0207] In this embodiment, to further facilitate operation in the manner described herein, each data block 72 corresponds in its uncompressed form to an integer number of cache lines of L2 cache 24, in this case four, such that each individual data block will include 256 bytes when each cache line includes 64 bytes.

[0208] These sixteen data blocks therefore comprise 4 kilobytes of memory pages (and will be stored and adapted within the same memory page). This then facilitates the addressing of the data blocks, as they will all use the same single physical memory address.

[0209] If needed, other configurations can be used to achieve this arrangement, for example, depending on the relative cache line and memory page size used in the graphics processing system under consideration.

[0210] Figure 7 , Figure 8 and Figure 9 The operation of this embodiment is illustrated when reading data from L2 cache 24, writing data to L2 cache 24, or evicting data from L2 cache 24. Figure 7 This illustrates the operation when data is read from L2 cache 24 for use by the graphics processor's shader core 25. Figure 8 This illustrates the operation when data is written from shader core 25 to L2 cache 24. Figure 9 An implementation scheme for evicting data from L2 cache 24 back to main memory system 6 is shown.

[0211] Figure 7 This illustrates the operation when data is read from L2 cache 24 for use by the graphics processor's shader core 25.

[0212] When shader core 25 needs data for a processing operation it will perform, it will attempt to read the data from L2 cache 24 by issuing a read request to the L2 cache.

[0213] If the data exists in the L2 cache (i.e., there is a "hit" in the L2 cache), the shader core can read the data from the L2 cache normally and process the data accordingly.

[0214] However, if the data is not present in the L2 cache (i.e., there is a read "miss" in the L2 cache), the data needs to be fetched from the memory system 6 into the L2 cache 24 for use by the shader core 25 of the graphics processor 10.

[0215] In this scenario, the L2 cache (the controller for the L2 cache) will first determine whether the data that needs to be retrieved from the memory system for use by the shader core is indicated to be processed by the data encoder 22 (indicating whether it needs to be processed by the data encoder 22). If not, the L2 cache controller will request the data from the memory system 6 and retrieve it into L2 in the normal manner for the graphics processing and cache system under consideration.

[0216] On the other hand, if data is indicated to be processed by data encoder 22, the L2 cache (cache controller) registers the required data for data encoder 22 to process, so that data encoder 22 can then retrieve and process the data and write it appropriately into L2 cache 24.

[0217] In such Figure 7 The read miss operation is performed in the embodiment shown.

[0218] Therefore, as Figure 7 As shown, when there is a read miss in the L2 cache (step 100), and the "miss" data will be processed by the data encoder 22, the L2 cache 24 (the controller for the L2 cache) notifies (signals) the data encoder 22 that the entire data block, including the required data (the miss that triggered the read), needs to be acquired, decoded, and stored in the L2 cache (step 101).

[0219] Then, the data encoder 22 will first read the header data of the block from its corresponding sideband data structure (i.e., memory tag 74) to acquire and decode it (step 102), and determine from it how many external memory transactions are required to acquire the compressed data (step 103).

[0220] The data encoder 22 then operates to read an appropriate amount of compressed data representing the block from memory (step 105) (e.g., based on an indication of how many memory transactions are needed to retrieve the complete block from the header data). The read compressed data is stored in the data buffer 65 of the data encoder 22 while it is processed by the data encoder 22 (and before it is written to the L2 cache 24).

[0221] Then, the data encoder 22 operates to decode the acquired compressed data, thereby providing four lines of uncompressed data (as in this embodiment, each uncompressed data block corresponds to four cache lines of data) (step 106), and then writes the four lines of uncompressed data into the L2 cache (step 107) (and, if appropriate, marks the lines thus written as unmanipulated).

[0222] Therefore, the data encoder 22 will operate to read compressed data blocks from memory 6 along with their associated sideband compressed metadata (i.e., memory tag 74), but then decode the data and write the data in the block into L2 cache 24 in uncompressed form for use by the graphics processor 10.

[0223] It should also be pointed out here that, in cases such as Figure 7 In the operation shown, regardless of how much data actually needs to be written from memory to the L2 cache, the data is always written from memory 6 to L2 cache 24 as a complete block. This helps ensure synchronization between the data in memory and the data in the L2 cache.

[0224] (It should be understood that loading data into the L2 cache may include first allocating an appropriate line in the L2 cache for the data, and / or evicting data lines already present in the L2 cache to make available lines for storing new data blocks. Cache line allocation, eviction, and other such processes may be performed in any suitable and desirable manner, such as normal cache operations in those aspects of the graphics processing system under consideration (operations in the manner described herein).)

[0225] Figure 8 The operation of this embodiment is illustrated, in which data is written from shader core 25 to L2 cache 24. This could be, for example, a situation where the shader core has performed some processing on data from the data array in memory 6 and now wishes to return the modified data to the memory system. In this case, the data from shader core 25 would first be written to L2 cache 24 and then written back from it to memory system 6 as needed.

[0226] When data is written from shader core 25 to L2 cache 24, write requests from shader cores are sent to L2 cache 24.

[0227] Therefore, as Figure 8 As shown, the write process begins with an appropriate write request from shader core 25 to the L2 cache (step 110).

[0228] Then determine whether the line (entry) of the data being written already exists in the L2 cache (i.e., whether there is a write "hit" in the L2 cache (step 111)).

[0229] If a write request hit exists in L2 cache 24 (i.e., the line of data being written already exists in L2 cache), then new data from shader core 25 can simply be written to the appropriate line in L2 cache accordingly (step 112).

[0230] On the other hand, such as Figure 8 As shown, if a write request in L2 cache 24 is lost, it is determined whether the data being written can withstand external reads and snooping in the L2 cache (step 113).

[0231] This can be determined, for example, from the appropriate indication (marker) in the MMU page table (which may be propagated, for example, along with the write transaction to the L2 cache where the indication will be checked).

[0232] In cases where the memory pages under consideration can be shared with other components in the system beyond the graphics processor itself, the data being written can be marked as subject to external reads and snooping in the L2 cache. These components are, for example, one or more CPUs, such that the memory pages are contiguous only with other components in the system (and not just internally within the graphics processor (its L2 cache and lower-level caches)). (If the memory pages are contiguous beyond the graphics processor itself, then the data can be subject to external reads and snooping from other components in the system (the cache systems of those other components) in the graphics processor's L2 cache for that purpose.)

[0233] Once it is determined that the data being written is in the L2 cache and has not been read or spied on externally, the new data can simply be written to the L2 cache (once a cache line allocated for that data exists) (step 112).

[0234] On the other hand, when it is determined that the data to be written to the L2 cache will be subject to external reads and snooping of the L2 cache, the new data is not simply written to the L2 cache itself. The data encoder 22 operates to retrieve and decompress the remaining data of the data block involved in the new data being written to the L2 cache from the memory system 6 (step 114), and then combines the data retrieved from the memory system with the new data to be written to the L2 cache 24 so as to write the complete (uncompressed) data block (including the new data) to the L2 cache (step 112).

[0235] This has the effect of enhancing system coherence by ensuring that complete data blocks are stored in the L2 cache, even if the write request itself only involves a portion of the data block. This then avoids any external snooping on the data block under consideration, such as the L2 cache, which would otherwise require external reads (other than reads from the L2 cache) (which could otherwise lead to deadlock risks, for example, on the interconnect).

[0236] (Similarly, in the event of a write miss in the L2 cache, the write operation will first allocate a line in the L2 cache to store the new data (and, for example, the complete data block where appropriate), and then write that data to the L2 cache. New data to be written to the L2 cache and any other blocks of data retrieved from memory can be appropriately buffered while the data is processed and awaits being written to the L2 cache.)

[0237] Figure 9 The operation of this embodiment is illustrated, in which data is evicted (written) from L2 cache 24 back to memory system 6.

[0238] like Figure 9 As shown, the process begins when a line in the L2 cache is selected for eviction (and is triggered to eviction) (step 120).

[0239] In this scenario, the L2 cache (the controller for the L2 cache) will first determine whether the line to be evicted from the L2 cache is indicated to be processed by the data encoder 22 (i.e., whether it needs to be processed by the data encoder 22). If not, the L2 cache controller will evict the line from the L2 cache to the memory system 6 in the normal manner.

[0240] On the other hand, if a cache line (data) is indicated to be processed by the data encoder 22, the L2 cache (cache controller) registers an entire data block including the data (line) being evicted for processing by the data encoder 22, so that the data encoder 22 can subsequently read those cache lines from the L2 cache, process the data block and write it back to memory 6 appropriately (step 121).

[0241] Then, the data encoder 22 will attempt to read all lines related to the block under consideration from the L2 cache (therefore including lines selected for eviction, and any cache lines of blocks not selected for eviction) (step 122). The data of the cache lines read from the L2 cache (if present in the L2 cache) is stored in the data buffer 65 of the data encoder 22, awaiting processing and writing the data back to memory 6.

[0242] As part of this process, the L2 cache will return to the data encoder 22 an indication of which cache lines it has attempted to read from the L2 cache have been marked as "manipulated" (i.e., modified since they were loaded into the cache from memory), and an indication of which lines in the L2 cache were "missed" (i.e., those lines of the considered block that are not present in the L2 cache).

[0243] Any line read from the L2 cache is also invalid (marked as invalid) (and therefore reusable). (This operation is completed once the L2 cache read operation is finished, so the line is available for reuse at this point (and before the eviction process in data encoder 22 is complete).)

[0244] Then determine whether any lines attempted to be read from the L2 cache for that block are marked as manipulated (i.e., modified because they were retrieved from the L2 cache) (step 123).

[0245] like Figure 9 As shown, if no line in the L2 cache is "manipulated" (i.e., the data has not been modified while it exists in the L2 cache), the eviction operation can be terminated without writing the data back to memory (because there is no need to write unmodified data back to memory). Therefore, in this case, any data read from the L2 cache will be discarded.

[0246] On the other hand, such as Figure 9 As shown, if any line read from the cache is "manipulated" (i.e., L2 cache 24 is storing modified data of the data block, such that the data of the data block needs to be written back to memory system 6), then it is determined whether the data encoder 22 encountered a line miss when attempting to read all lines of the block from the L2 cache, or whether any line read was only partially valid (step 124). Therefore, the data encoder 22 effectively determines whether all data of the data block under consideration exists in the L2 cache.

[0247] If all the data exists in the L2 cache (and is therefore read by the data encoder when it attempts to read the data from the L2 cache), the data encoder 22 encodes (compresses) the uncompressed data of the block it has read from the L2 cache (step 125), and then writes the compressed data (compressed cache line) back to memory 6 (step 126).

[0248] The data encoder will update the header data of each data block under consideration accordingly, for example to indicate new compressed metadata, such as the number of memory transactions required to obtain the compressed data of the block (step 127).

[0249] If it is determined that not all the data of the block under consideration is stored in the L2 cache (i.e., it is determined at step 124 that there are line misses or only partially valid lines in the L2 cache), then the data encoder 22 reads the header data of the block under consideration to determine whether the block should be stored in the memory system 6 in compressed form (steps 128 and 129).

[0250] If it is determined that the block will not be stored in memory in compressed form, the data encoder simply operates to write the uncompressed lines of the block read from the L2 cache back to memory system 6 (step 131).

[0251] Therefore, in this case, the data encoder writes the uncompressed data of the block read from the L2 cache back to the memory system, where any data of the block not present in the L2 cache simply remains "as is" in the memory system 6.

[0252] On the other hand, when it is determined that the block is stored in memory in compressed form, the data encoder 22 operates to read the compressed data of the (entire) block stored in memory and decodes (decompresses) the data (step 130) to provide the uncompressed form of the block stored in memory. The block data is stored in the data buffer 65 of the data encoder 22.

[0253] This therefore provides the data encoder with the data in the uncompressed form of the "missed" blocks in the L2 cache (because there are rows that are either missing or only partially valid in the L2 cache).

[0254] Then, data encoder 22 combines the new uncompressed data of the block read from the L2 cache with the required remaining uncompressed data for the block read and decoded from memory system 6 to provide a new complete (and modified) uncompressed dataset for the block, and then appropriately encodes (compresses) the data to provide a new compressed version of the block (step 125). The new compressed version of the block is then written back to memory system 6 (step 126), and the header data of the set of blocks under consideration is updated appropriately (step 127).

[0255] Therefore, instead of simply writing the “new” data of the data block back to the memory system from the L2 cache, the complete new compressed version of the block is written back to the memory system.

[0256] This then ensures that when data from the L2 cache is written back to the memory system in compressed form, the complete compressed data block is written back to the memory system. This also helps ensure the coherence and synchronization of data blocks as they are transferred to and from the L2 cache.

[0257] As should be understood from the above, in the techniques described herein, compressed metadata (i.e., header data) is stored to / provided to the cache as corresponding “sideband” data, for example, instead of storing the header data together with the payload (in the same data structure, such as a memory page).

[0258] Figure 10 The integration of the MPC 22 unit within the L2 cache 24 is illustrated. The cache line tag pipeline 26 issues a request (“RequestIF”) to the MPC 22 on eviction / line filling operations, providing the cache line tag (key) used during cache lookups. External traffic to the MPC is routed directly to the external AXI port 27. Internal traffic to the MPC is routed to the L2 input arbitrator and placed in the appropriate queues 29 (multiple queues corresponding to write / read operations on the ASN and MPC may exist, as shown). Figure 10 As shown, there exists a separate header cache 28 for storing the provided compressed metadata, for example, in the memory tag data field, as described above.

[0259] When data is loaded from memory into L2 cache 24, compressed metadata is thus provided to the cache as additional sideband information (separate from cache line tag pipe 26) on the AXI interface. Therefore, MPC 22 can read the memory tag 74 provided in this way to determine how many memory bursts, etc., need to be read in the remainder of the data block. The decoded data block can then be appropriately written to the cache, and the header data is stored in header cache 28.

[0260] Figure 11The structure of a cache entry in L2 cache 24 according to this embodiment is shown. The cache line has a key (i.e., a cache line tag) 80, which in this case includes a memory address and some associated data stored in the 64-byte cache line in this embodiment. The cache entry also includes a validity mask 84 indicating which bytes of data are valid, a manipulation mask 86 indicating which bytes of data are manipulated, a sharer mask 88 indicating (in the case of coherent caching) which lower-level sharer retains a copy of the cache line, and a cache line state 89 containing information about its coherence and general state (common coherent caching protocols include, but are not limited to, INVALID, SHARED_VALID, UNIQUE_DIRTY).

[0261] Memory tag 74 (which is read as a side channel and stores compressed metadata on the external AXI port) is not stored in the L2 cache line, but in a separate header cache 28, such as... Figure 10 As shown, this is because it contains information associated with the entire compressed block (i.e., four cache lines in a 256B (or appropriately sized) block).

[0262] Therefore, as can be seen from the above, the technology described herein, in its implementation, provides at least an effective and efficient mechanism for transferring compressed data between a memory system and a graphics processor that processes the data in uncompressed form.

[0263] Although this embodiment has been discussed above with particular reference to cache operations of a graphics processor in a graphics processing system, the applicant recognizes that the use of a cache data encoder in the manner described in this embodiment above can be used in other cache arrangements and systems, not just in the context of a graphics processor.

[0264] For example, it may be advantageous to integrate a data encoder with a system cache serving multiple processors, such as a graphics processor, display processor, video processor, and image signal processor (ISP), in the manner described herein, whereby the system cache presents data to the main memory system in compressed form and decompresses it to a processor (main processor) connected to the system cache.

[0265] 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 forms disclosed. Many modifications and variations are possible in accordance with the foregoing 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 suitable for the particular intended use. The scope of the invention is intended to be defined by the appended claims.

Claims

1. A method for operating a data processing system, the data processing system comprising: processor; Memory system; and A cache system configured to transfer data stored in the memory system to the processor for use by the processor when performing data processing operations, and to transfer data from the processor to the memory system; The cache system includes a cache configured to receive data from memory and provide the data to the processor for use during data processing operations, and to receive data from the processor for transmission to the memory. The cache includes multiple cache lines, each cache line being able to store a corresponding data entry, wherein the cache lines among the multiple cache lines are associated with a corresponding individual sideband data structure; The method includes: When a data block stored in compressed form in the memory is to be loaded into the cache, the compressed data block has an associated set of compressed metadata: Store the data block into a group of one or more cache lines of the cache; and The compressed metadata of the data block is provided in a corresponding sideband data structure associated with a cache line in the group of one or more cache lines of the cache storing the data block, thereby providing the compressed metadata as separate sideband data.

2. The method of claim 1, wherein the compressed metadata of the data block is provided as separate sideband data associated with a first cache line in the group of cache lines, the data block being stored in the group of cache lines.

3. The method of claim 1 or 2, further comprising loading a plurality of compressed data blocks from the memory system into the cache, wherein each of the plurality of compressed data blocks is stored in a corresponding group of one or more cache lines of the cache, and corresponding compressed metadata for each block is provided as separate sideband data associated with a cache line in the group of one or more cache lines of the cache, the corresponding data block being stored in the cache.

4. The method of claim 3, wherein the plurality of compressed data blocks correspond to a single memory page.

5. The method of claim 1 or 2, wherein the cache system includes a data encoder, wherein when a data block stored in the memory in compressed form is to be loaded into the cache, the method includes decoding the compressed data from the memory system and storing the data in the cache in an uncompressed format.

6. The method of claim 1 or 2, wherein the compressed metadata is stored in one or more data fields of a sideband data structure that will be used to store other information in another operating mode.

7. The method according to claim 1 or 2, wherein the processor is a graphics processor, and wherein the data is data required for graphics processing operations performed by the graphics processor.

8. A computer-readable storage medium for storing software code, which, when executed on a data processor, performs the method according to claim 1.

9. A data processing system, comprising: processor; Memory system; and A cache system configured to transfer data stored in the memory system to the processor for use by the processor when performing data processing operations, and to transfer data from the processor to the memory system; The cache system includes a cache configured to receive data from memory and provide the data to the processor for use during data processing operations, and to receive data from the processor for transmission to the memory. The cache includes multiple cache lines, each cache line being able to store a corresponding data entry, wherein the cache lines among the multiple cache lines are associated with a corresponding individual sideband data structure; The data processing system also includes: The cache control circuit is configured to: When a data block stored in compressed form in the memory is to be loaded into the cache, the compressed data block has an associated set of compressed metadata: Store the data block into a group of one or more cache lines of the cache; and The compressed metadata of the data block is obtained from the corresponding sideband data structure associated with a cache line in the group of one or more cache lines of the cache storing the data block, thereby providing the compressed metadata as separate sideband data.

10. The system of claim 9, wherein the compressed metadata of the data block is provided as separate sideband data associated with a first cache line in the group of cache lines, the data block being stored in the group of cache lines.

11. The system of claim 9 or 10, wherein the cache control circuitry is configured to load a plurality of compressed data blocks from the memory system into the cache, wherein each of the plurality of compressed data blocks is stored in a corresponding group of one or more cache lines of the cache, and the corresponding compressed metadata of each block is provided as separate sideband data associated with a cache line in the group of one or more cache lines of the cache, the corresponding data block being stored in the cache.

12. The system of claim 11, wherein the plurality of compressed data blocks correspond to a single memory page.

13. The system of claim 9 or 10, wherein the cache system includes a data encoder configured to: When data needs to be written from the cache to the memory system, the uncompressed data from the cache is encoded for storage in the memory system in a compressed format, and the data is sent to the memory system in the compressed format for storage; and When compressed data needs to be read from the memory system into the cache, the compressed data from the memory system is decoded and the data is stored in the cache in an uncompressed format.

14. The system of claim 9 or 10, wherein the compressed metadata is stored in one or more data fields of a sideband data structure that will be used to store other information in another operating mode.

15. The system of claim 9 or 10, wherein the processor is a graphics processor, and wherein the data is data required for graphics processing operations performed by the graphics processor.

Images