Accessing an encoded data block

Abstract

A method of storing an encoded data block in a memory includes encoding a block of data elements and determining a memory location (26) in which the encoded data block is to be stored. The memory location (26) is then indicated in a header (406) for the encoded data block by including a memory address value (407) in the header and a modification value (500) which represents a modification to be applied to the memory address value (407) when determining the memory location (26). When the encoded data block is to be retrieved, the header (406) is read and processed to determine the memory location (26).

Description

Technical Field

[0001] The technology described herein relates to a method for storing coded data blocks in a memory and an apparatus for storing coded data blocks in a memory. It also relates to a corresponding method for retrieving data from a coded data block from a memory and an apparatus for retrieving data from a coded data block from a memory. Background Technology

[0002] A common practice in data processing systems is to encode arrays of data elements, such as arrays of image data values ​​(e.g., frames of video data or graphic data used for display), in order to compress the data and reduce bandwidth and memory consumption. This is particularly necessary in data processing devices, such as portable devices where processing resources and power may be limited.

[0003] To encode an array of data elements, the array is typically divided into smaller blocks (sub-regions) of data elements and encoded on a block-by-block basis. The encoded versions of the data blocks can then be stored in memory. An example of an efficient lossless encoding technique is described in U.S. Patent No. 8,542,939 (Arm Limited). However, various other examples of encoding schemes suitable for encoding data blocks exist.

[0004] When coded data blocks are stored in memory, headers are provided for the coded data blocks, indicating their location in memory. When a particular coded block needs to be decoded, the associated headers can then be read to determine its memory location, and the coded block can then be retrieved accordingly for decoding.

[0005] The applicant believes that there is still room for improvement in the technology used to encode arrays of data elements. Summary of the Invention

[0006] In a first aspect, this application relates to a method for storing an encoded data block in a memory, the method comprising: encoding data element blocks of a data element array to generate an encoded data block representing the data element blocks; determining a memory location in which the encoded data block is to be stored; generating a header for the encoded data block, the header indicating the memory location in which the encoded data block is stored, wherein, in determining the memory location, the memory location is indicated by including a memory address value and a modification value in the header, the modification value indicating a modification amount to be applied to the memory address value; and writing the header and the encoded data block into the memory, wherein the encoded data block is stored in the memory at the location indicated in the header for the encoded data block.

[0007] In a second aspect, this application relates to a data processing apparatus for retrieving data from a coded data block from a memory, the data processing apparatus comprising: a read control circuit configured to: upon determining a memory location for the coded data block, the coded data block representing a block of data elements in a data element array, wherein the header includes a memory address value and a modification amount value indicating a modification to be applied to the memory address value; determine a memory location for the coded data block by applying the modification amount to the memory address value; and read data from the memory of the coded data block from the determined memory location; and a decoding circuit configured to: decode the coded data block to derive at least one data value of a data element of the coded data block.

[0008] In a third aspect, this application relates to a computer-readable storage medium for storing software code that, when executed on a data processor, performs the method described in the first aspect. Attached Figure Description

[0009] Various embodiments of the technology described herein will now be described by way of example only, with reference to the accompanying drawings, wherein: Figure 1 A data array that can be encoded according to an embodiment of the technology described herein is illustrated schematically; Figure 2 A graphics processor according to an embodiment of the technology described herein is illustrated schematically; Figure 3 A graphics processing pipeline is shown in an embodiment of the technology described herein; Figure 4A An array of data elements encoded according to an embodiment of the technology described herein is shown; Figure 4B The storage of a data array is schematically illustrated in one embodiment; Figure 4C The data structure, including the header and the corresponding encoded data block, is shown. Figure 5A The header data structure is shown in more detail, and Figure 5B The header data structure of an embodiment according to the technology described herein is shown; Figure 6 A flowchart illustrating a header generation technique according to an embodiment of the technology described herein is provided; and Figure 7 A flowchart illustrating a decoding technique according to an embodiment of the technique described herein is provided. Detailed Implementation

[0010] A first embodiment of the technology described herein includes a method for storing coded data blocks in a memory, the method comprising: Encode the data element blocks of the data element array to generate encoded data blocks representing those data element blocks; Determine the memory location where the encoded data block should be stored; Generate a header for the encoded data block, the header indicating the memory location where the encoded data block is stored, wherein, in determining the memory location, the memory location is indicated by including a memory address value and a modification value in the header, the modification value indicating the amount of modification to be applied to the memory address value; and The header and the encoded data block are written to the memory, wherein the encoded data block is stored in the memory at the location indicated in the header for the encoded data block.

[0011] A second embodiment of the technology described herein includes a device for storing coded data blocks in a memory, the device comprising: An encoding circuit configured to encode data element blocks of a data element array to generate encoded data blocks representing the data element blocks; A header generation circuit is configured to: determine a memory location in which the encoded data block is to be stored; and generate a header for the encoded data block, wherein the header indicates the memory location where the encoded data block is stored, wherein, when determining the memory location, the memory location indicated by the header generation circuit includes a memory address value and a modification value in the header, the modification value indicating the amount of modification to be applied to the memory address value; and A write control circuit is configured to write the header and the encoded data block to a memory, wherein the encoded data block is stored in the memory at the location indicated in the header for the encoded data block.

[0012] The techniques described herein relate to techniques for encoding data blocks of an array of data elements (where the array of data elements may, for example, include frames or a portion of frames).

[0013] When an encoded data block is stored in memory, a header is provided for the encoded data block, which indicates the location in memory where the encoded data block is stored.

[0014] Correspondingly, when it is expected that the encoded data block will be retrieved from memory later, the associated header can be read to first determine the memory location where the encoded data block is stored, and then the data can be read from the indicated memory location accordingly.

[0015] Therefore, the header for the encoded data block indicates the location in memory where the encoded data block is stored. Subject to the specific requirements of the technology described herein, this indication may generally take any desired and suitable form; for example, it may typically be included in the header for the purpose of indicating memory location.

[0016] Specifically, in the technology described herein, the indication includes a memory address value that can be used to determine the memory location where the encoded data block is to be stored, for example, as will be explained further below.

[0017] The memory address value itself can take any suitable and desired form. For example, the memory address value itself can be used to indicate a memory address. However, in an implementation, the memory address value is used to indicate a memory location based on a memory offset (e.g., starting from a buffer, such as a buffer storing encoded data of multiple blocks of encoded data). In this case, a pointer (e.g., pointing to the beginning of the buffer) along with the offset can be used to determine the memory location.

[0018] The header for an encoded data block typically has a fixed size, and therefore a fixed number of bits available for storing memory address values ​​(and in one implementation, as is the case in the technique described herein). This means that in a more conventional header arrangement, the range of memory addresses that can be indicated in the header is strictly limited by the number of bits available for storing memory address values.

[0019] The number of bits used to indicate a memory location can vary depending on factors such as the data format, but in typical examples, a memory address value can be a 32-bit value. In some cases, this is acceptable and will provide a sufficiently large range of memory addresses.

[0020] However, since there is a limited range of memory addresses that can be indicated by the memory address values ​​themselves, this means that without increasing the size of the header (which may be undesirable), the encoding technique cannot support the encoding of larger and / or higher resolution data structures (e.g., larger frame sizes, such as 64k×64k frames, which may be increasingly used in modern graphics processing applications).

[0021] Therefore, in a more conventional header arrangement, the (fixed) size of the memory address value field in the header introduces a limitation on the range of memory locations in which encoded data blocks can be stored, and thus limits the size of the data structures that can be encoded (therefore there may be a maximum frame size that an encoding technique can support, making that encoding technique incompatible with data structures larger than that frame size limit).

[0022] To address this, according to the techniques described herein, a modification value is included in the header along with the memory address value, wherein the modification value represents a "modifier" (e.g., an offset) to be applied to the memory address value when determining the memory location. As will be further explained below, the modification value can therefore be appropriately applied to the memory address value to modify it, for example, and in one embodiment, by adding a value represented by the memory address value itself, thereby expanding the range of memory addresses that can be indicated by the header.

[0023] In this way, a larger range of memory addresses can be accessed, and in one implementation, it is not necessary to increase the header size or otherwise significantly modify the header structure. This, in turn, allows encoding techniques to support the encoding of larger data structures. Therefore, the techniques described herein provide a relatively simple and inexpensive method for extending encoding techniques to larger data structures.

[0024] The modifications described herein may include any suitable and desired modifications that can be applied to memory address values ​​to expand the available range of memory addresses. In one embodiment, these modifications include scaling factors (e.g., multipliers). Thus, and in one embodiment, the modification value represents a scaling factor (multiplier) to be applied to the memory address value when determining the memory location.

[0025] In other words, instead of simply indicating the memory address in the header by the memory address value itself (whether based on an absolute memory address or a memory address offset), as might be the case in a more conventional header arrangement, the memory address is represented in the header based on the memory address value and a corresponding modification, such as a scaling factor (multiplier), which can be applied to the memory address value to determine the memory address.

[0026] Therefore, including the modification value in the header indicates which modification should be applied to the memory address value when determining the memory location.

[0027] When it is desired to retrieve a block of encoded data, the header can be read, and the memory location can then be calculated by appropriately applying the corresponding modification amount indicated by the modification amount value included in the header for the associated memory address value.

[0028] For example, in some implementations, the memory address value includes, for example, a memory offset starting from a buffer, which may be a header buffer that stores headers for multiple coded data blocks for an array of data elements.

[0029] In this case, the complete memory location for storing the encoded data block can typically be determined (e.g., without modifications to the techniques described herein): Memory location = header_pointer + offset Here, 'header_pointer' is a suitable pointer that points to, for example, the beginning of a buffer at an offset defined by its name.

[0030] Conversely, in the techniques described herein, the modification amount is applied to the offset in one embodiment. For example, in one embodiment, the offset is multiplied by the modification amount, such that the complete memory location used to store the encoded data block is instead determined as: Memory location = header_pointer + offset Modification amount.

[0031] For example, when the modification includes a scaling factor (e.g., 1x, 16x, 64x, 256x multiplier), the memory location is determined by first multiplying the offset (memory address value) by the relevant scaling factor to determine the scaling offset, and then using the scaling offset and the header pointer to determine the memory location.

[0032] Similarly, when the memory location is defined based on the memory address value itself (rather than on the offset), the memory address can be determined by multiplying the memory address value by the relevant scaling factor to determine the proportional memory location.

[0033] Therefore, in the implementation, the modified value represents the scaling factor (e.g., multiplier) to be applied to the memory address value to determine the proportion of the memory address value that can be used to determine the memory location.

[0034] Applying such modifications (e.g., scaling factors) typically reduces the resolution of memory addresses indicated at that resolution (e.g., because when a 256x multiplier is applied, memory addresses can only be indicated in 256 levels). However, it should be understood that these levels are still relatively small compared to the overall range of memory addresses that can be indicated (e.g., using 30-bit memory address values), and therefore this still provides sufficient resolution for storing blocks of encoded data, specifically when the encoded data blocks are stored in memory in a “sparse” manner, such as where data blocks (e.g., and in one embodiment at regularly spaced intervals) are stored at predefined locations in a buffer of encoded data, as will be explained further below.

[0035] Other arrangements are also possible, and the modification amount need not include the scaling factor (e.g., multiplier) applied to the memory address value in the manner described above, but may include any other suitable modification amount that can be applied to the memory address value in any suitable manner, for example, to expand the available memory address range. For example, instead of multiplying the memory address value by a suitable scaling factor or multiplier, the modification amount may include an addition or shift applied to the memory address value to expand the available memory address range.

[0036] In this way, by applying appropriate modifications to the memory address values ​​within the header, the range of addresses indicated by the header can be extended beyond the range that might be indicated using the memory address values ​​themselves.

[0037] Furthermore, the extension of the memory address range provided by the technology described herein achieves minimal additional overhead or modification relative to existing header structures in one implementation. For example, in one implementation, there is a set of multiple available modification values, and it is determined during header generation which of these available modification values ​​should be applied to the memory address value. This means that the actual modification value itself does not need to be stored in the header; rather, and in one implementation, the modification value represents and encodes which of these available modification values ​​should be applied.

[0038] Therefore, the modification value included in the header represents a corresponding modification (e.g., a scaling factor) from a set of multiple available modification values. Thus, in an embodiment, the method includes (header generation circuitry) determining from the multiple available modification values ​​which one of the multiple available modification values ​​should be used with a memory address value to indicate the memory location where the coded data block is to be stored, and including in the header a modification value representing the determined modification value and the memory address value.

[0039] The modification to be applied (e.g., a scaling factor) can therefore be encoded using a relatively small number of bits, for example, and in one embodiment, two bits. Thus, in one embodiment, the modification value comprises a 2-bit modification value capable of representing one of a set of four available modification values. For example, in one embodiment, the modification value encodes one of a set of four different scaling factors (such as 1x, 16x, 64x, and 256x scaling factors), which can be applied to appropriately scale memory address values ​​to extend the range of accessible memory.

[0040] The encoding of different modification amounts (scale factors) can be stored, for example, in a suitable lookup table, so that the required modification amount can be determined from the modification amount value accordingly (e.g., where the modification amount value "00" represents a 1x scale factor, the modification amount value "01" represents a 16x scale factor, etc.).

[0041] Available modifications may include any suitable and desired modifications. In one implementation, they are scaling factors (e.g., multipliers), as described above, but other modifications may also be used.

[0042] In one implementation, one of these available modifiers is a "zero" modifier, which, when applied to a memory address value, does not change the memory address value. For example, when the modifier includes a scaling factor or multiplier, one of these modifiers in one implementation includes a 1x multiplier.

[0043] As will be further explained below, this facilitates the dynamic expansion of the memory address range when storing multiple coded data blocks of an array of data elements, for example, allowing the memory address range to be expanded as needed and as required. This also makes the method described herein readily compatible with smaller data arrays (frames), for example, where expanding the memory address range is not required.

[0044] Specifically, in one implementation, when it is necessary to expand the memory address range, for example when it is determined that the memory location used to store a particular (next) data block will exceed the originally accessible memory address range (e.g., based on the current modification value), the modification amount (e.g., a scaling factor) is dynamically used during the encoding process, provided that the encoded data block is stored in memory.

[0045] For example, while the embodiments described above relate to storing a single coded data block, it should be understood that, for example, for a given array of data elements (e.g., a given frame), there may be multiple coded data blocks to be stored in memory. These multiple coded data blocks can be written to sequential memory locations, for example, such that the memory address monotonically increases as the data element array (e.g., a frame) is processed. In the embodiments, the modification value is dynamically updated when a new coded data block is written to memory.

[0046] Specifically, in one implementation, the modification amount is initially set to a "zero" modification amount (e.g., 1x scaling factor), and the encoded data block is written to memory, where the memory location is effectively indicated in the header solely by the memory address value (because a zero modification amount does not change the memory address value). For each new encoded data block to be written to the storage device, the complete memory location is calculated, and when it is determined based on the current modification amount that the memory location will exceed the available memory address range, the modification amount can then be increased accordingly to expand the available memory address range.

[0047] The encoded data block can then be written to a memory location within an extended memory address range. When the extended memory address range is exceeded, the modification amount can be increased again to further extend the memory address range, and so on.

[0048] Therefore, in one implementation, when multiple coded data blocks are stored in memory, these blocks are written sequentially to increase the memory location. In one implementation, the modification amount is initially set to a "zero" modification amount (so that the memory address value is not modified, e.g., a 1x scaling factor), and thus the memory address value itself is initially used to indicate the memory location for the coded data block at the beginning of the sequence without modification (e.g., as would typically be the case if the techniques described herein were not used). Since more coded data blocks are processed to store in memory, this will require larger memory addresses. Therefore, when it is determined that the memory location of a coded data block will exceed the range of available memory address values ​​indicated in the header by the currently applied (e.g., zero) modification amount, the modification amount is increased to expand the available address range.

[0049] Therefore, for each block of coded data to be stored in memory, the memory location can be calculated first. When the memory location can be indicated using a memory address value and the current modification (the memory location falls within the range of memory addresses accessible using the current modification), the memory address value is then set accordingly based on the current modification. On the other hand, when the memory location cannot be indicated using a memory address value and the current modification (the memory location falls outside the range of memory addresses accessible using the current modification), the modification can be increased, and the memory address value is then set accordingly based on the increased modification.

[0050] Therefore, in one implementation, the amount of modification gradually increases as the required memory address range increases, as more blocks of the array need to be encoded / stored.

[0051] For example, in an embodiment where the memory address value includes an offset and the modification includes a scaling factor, when multiple coded data blocks are stored in memory, wherein the coded data blocks are stored in increasing memory locations, encoding in one embodiment begins with a scaling factor of 1x and the coded data blocks are initially stored at memory locations within the available memory address range provided by the (unmodified) memory address value itself.

[0052] Once the calculated address of a memory location exceeds this range, a next scaling factor (e.g., 16x) can be applied to expand the available memory address range, and so on.

[0053] The modification value can be included separately from the memory address value in the header; for example, the modification value can be in a separate dedicated field of the header data structure. That is, there can be a dedicated set of (e.g., two) bits that are always used to store the modification value.

[0054] However, in the implementation, a certain number of bits from the address value field itself are reused to store the modification value. That is, a certain number of bits that would originally (without performing the techniques described herein) be used to indicate the memory address value itself are used to encode the modification amount of the techniques described herein.

[0055] In this regard, the techniques described herein recognize that in some cases, there are bits in the address value field that are expected to always be zero, and therefore these can be reused accordingly to encode the modifications described herein.

[0056] This could specifically refer to a case where encoding is performed in a “sparse” manner, such that encoded data blocks are stored in a buffer of encoded data (e.g., in a predefined order, corresponding in one embodiment to the order in which headers are stored in a header buffer) at predefined locations. In this case, a fixed amount of space can be allocated in the buffer for each encoded data block. For example, the same amount of space that would be needed to store uncompressed data blocks can be allocated to each encoded data block. Thus, the same amount of space can be allocated in the buffer for each encoded data block, where in one embodiment there are a certain number of equally spaced boundaries defining the memory location for the respective encoded data blocks. This then means that the memory location of the encoded data block only needs to be indicated by its respective boundaries, and the boundaries will have a fixed spacing in the buffer.

[0057] Therefore, in the implementation, a fixed amount of space is allocated in memory for each of the coded data blocks, and they are stored in memory at predefined locations aligned with the corresponding boundaries of the allocated amount of space (i.e., using a “sparse” layout).

[0058] When using such a "sparse" layout to store coded data blocks, where the memory locations storing the coded data blocks are equally spaced within the buffer, this means that a certain number of least significant bits of the memory address values ​​will always be zero, for example, when only the location of the corresponding boundary within the buffer is needed, rather than a more precise memory location. Typically, the number of zero least significant bits will depend on the size of the data block; for example, because more space needs to be allocated in the buffer for larger data blocks, the intervals between memory location boundaries will be larger.

[0059] This means that when encoding is performed in a “sparse” manner, there is a certain number of redundant bits (because they will always be zero), and these bits can therefore be reused to store the modified value of the technique described herein. Therefore, and in an implementation, the memory address value can be truncated, for example, by removing a certain number of least significant bits. Truncating the memory address value in this way allows a corresponding number of bits to be used to store the modified value. For example, in one implementation, (e.g., two) least significant bits in the memory address value are truncated. These least significant bits can then be used to store the modified value. In one implementation, since a corresponding number of bits have been discarded, the memory address value is shifted toward a smaller number of significant bits, and the modified value is stored in the most significant bits. Various other arrangements are possible in this regard.

[0060] When memory address values ​​are truncated in this way, the least significant bit (i.e., zero) that was truncated can be reinserted when the memory location is determined during the retrieval of the encoded data block. Therefore, determining the memory location may involve modifying the memory address value (by reinserting any missing bits) before applying the modification. However, this is generally unnecessary, as the truncated memory address value and the modification can be used appropriately to encode the memory address.

[0061] Truncating memory address values ​​in this way means that fewer bits are available to store the memory address value itself (e.g., the offset), which reduces the range of memory addresses that can be indicated by the memory address value. However, this is compensated for by the much larger range of memory addresses provided by the techniques described herein.

[0062] Therefore, the techniques described herein provide a relatively simple and inexpensive method for extending the header format of headers generated in encoding techniques that use headers to indicate the memory location for storing encoded data blocks to span a large range of memory addresses, and thus allow such encoding techniques to support larger data structures (e.g., frames).

[0063] This is accomplished by including an appropriate modification value along with a memory address value in the header. This appropriate modification value represents the amount of modification to be applied to the memory address value to determine the memory location (e.g., as described above). When it is necessary to retrieve an encoded data block from its memory location, the header can thus be read appropriately and the memory address value and modification value used to determine the memory location. The encoded data block can then be read from its memory location and decoded for use, for example, in a normal manner.

[0064] Therefore, the technique described in this paper offers various improvements compared to other methods.

[0065] An array of data elements (originally unencoded) encoded by an encoding circuit can be any suitable data array. It typically includes multiple data elements (entries), each occupying a different position within the array. The data array can be an image (representing an image). In various embodiments, the data array is, for example, a frame of (image) (e.g., color) data used for display or graphic texture. The data element array can also include other graphic data arrays, such as depth data arrays or non-graphic data arrays.

[0066] In one implementation, the data element array is a frame generated by a graphics processing system, for example, for display of an application (such as a game). Each data element array (frame) accordingly includes an image to be displayed in one implementation. The data element array is divided into a certain number of blocks for individual encoding. Typically, the data element array will be divided into multiple blocks for encoding.

[0067] In these arrangements, the overall data array is divided into blocks for encoding purposes, which can take any suitable and desired form. Each block should include a subset of the data elements (locations) in the array, that is, a specific region of the array.

[0068] These blocks can have any suitable and desired size. In one embodiment, these blocks correspond to the block size that will be used in other ways in the data processing system in question. Thus, in the case of a slice-based graphics processing system, these blocks in one embodiment correspond to slices (having the same size and configuration as these slices) on which the rendering process of the graphics processing system operates. However, the encoding blocks do not necessarily correspond to these slices. For example, in an embodiment, the block size used for encoding techniques is smaller than the rendering slice size.

[0069] The data values ​​of the data array elements can take any suitable and desired form, and will depend on the nature of the data array being encoded (e.g., whether it is a texture, image, frame, etc.). In the case where the nature is texture, for example, the data values ​​of the data array elements should be texture data (meta values). Such texture data may include, for example, a set of color values ​​(red, green, blue (RGB), a set of color and transparency values ​​(red, green, blue, α (RGBa)), a set of luminance and chromaticity values, a set of shadow (light) mapping values, a set of normal mapping (bump mapping) values, z-values ​​(depth values), stencil values, luminance values ​​(luminance texture), luminance α texture, and / or gloss texture, etc.

[0070] In the case where the property is an image or frame for display, the data values ​​of the data array elements should be pixel and / or sampling location data (data values). Such pixel data may include, for example, appropriate color (RGB) values ​​or luminance and chrominance values.

[0071] The data element array can be generated in any suitable manner. The data element array can be generated by a processing unit (and the data processing system can include such a processing unit), which may include, for example, a graphics processing unit (GPU), a video processor / codec or video engine (video processing unit (VPU)), a digital camera image signal processor (ISP), an image processor, and / or a central processing unit (CPU). More than one processing unit may be present if desired. In one embodiment, the processing unit is a graphics processor or a video processor.

[0072] The processing unit should generate its array in an appropriate manner, such as by rendering the array if the processing unit is a graphics processor, by appropriately decoding the input encoded video data if the processing unit is a video processor, or by generating its array from captured images if the processing unit is a digital camera image signal processor (ISP), and so on.

[0073] Once generated, the array of data elements should (and in one implementation) be provided (sent) to the encoding circuit for encoding.

[0074] The encoding circuit may include any suitable circuit of this kind that is operable to encode an array of data elements to produce an encoded version of the array of data elements, and may encode the array of data elements in any suitable manner.

[0075] In one embodiment, the encoding circuitry is operable to encode an array of data elements generated by the processing unit. Therefore, in one embodiment, the method includes encoding circuitry that encodes the array of data elements generated by the processing unit. The encoding circuitry may encode only a portion of the overall data array (e.g., a frame, image, or texture) generated by the processing unit, but in one embodiment, the entire array (e.g., a frame, image, or texture) generated by the processing unit is encoded.

[0076] To facilitate this, the encoding circuitry can (and in various embodiments) be part of the processing unit, such as the (integrated) encoding circuitry of a graphics processing unit (GPU), video processor / codec or video engine (video processing unit (VPU)), digital camera image signal processor (ISP), image processor and / or central processing unit (CPU), etc. Thus, in these embodiments, the processing unit both generates an array of data elements and encodes the array (using its encoding circuitry).

[0077] In various other implementations, the encoding circuitry may be separate from the processing unit, for example, it may be a separate circuit (e.g., an integrated circuit), and may include a “standalone” encoding unit, for example, the encoding unit being configured to receive (and encode) an array of data elements from the processing circuitry.

[0078] Once generated (encoded), the encoded data element array can be stored in memory (e.g., in a buffer such as a frame buffer), and then the encoded data element array can be read from that memory (e.g., via decoding circuitry). The memory capable of storing the encoded array can include any suitable memory and can be configured in any suitable and desired manner. For example, it can be memory mounted on the chip with the encoding circuitry, or it can be external memory. In one embodiment, it resides in external memory (such as the main memory of the overall image processing system). It can be dedicated memory for this purpose, or it can be part of memory used for other data.

[0079] The actual encoding of data blocks can be performed in any suitable and desired manner.

[0080] In the implementation, the coding is performed according to the technology described in U.S. Patent No. 8,542,939 (Arm Limited).

[0081] For example, in one implementation, the encoding circuitry is operable to encode an array of data elements in order to generate an encoded version of the data element array by dividing the data element array into multiple separate blocks, generating a corresponding tree representation for each different block into which the data element array is divided, and generating data representing each tree representation in order to represent the data element array as an encoded version of the data element array.

[0082] However, other encoding techniques and representations may be used (and in various implementations).

[0083] As described above, a header is provided for each encoded data block. The header indicates the memory location used to store the encoded data block. The header may also include any other suitable data that is expected to be stored for the encoded data block, such as compression metadata, for example, which indicates the data size of the encoded data block or indicates the compression scheme that has been used.

[0084] The header can have any desired and suitable data size. The data size can be represented in bits or bytes. For example, the header can include 32 bits or 4 bytes, indicating the location in memory used to encode the data block. The header can also include 96 bits or 12 bytes (e.g., 6 bits for each sub-block in a 4×4 sub-block), indicating, for example, the data size of the encoded data block and / or data sub-blocks. Therefore, the header can be a total size of 128 bits or 16 bytes.

[0085] Once the header has been properly generated, the encoded data block can be written to the memory location indicated in the header for storage. Therefore, in one embodiment, the method also includes writing the header for the encoded data block to memory, and writing the encoded data block to memory, wherein the encoded data block is stored in memory at the location indicated in the header for the encoded data block. This is performed in one embodiment by suitable write control circuitry of the encoder device.

[0086] The header can be stored in any desired and suitable manner. For example, and in one embodiment, the header is stored in a header buffer. In another embodiment, the header is stored, for example, in a predetermined order at predictable locations within the header buffer. In this respect, various arrangements will be possible.

[0087] Similarly, encoded data blocks can be stored in any desired and suitable manner. In one implementation, as described above, a “sparse” layout is used to store the encoded data blocks. Therefore, a fixed-size portion of the buffer can be allocated to each encoded data block, corresponding to the amount of space required to store the data block in its raw, unencoded format. This means that the encoded data blocks will be aligned with the corresponding boundaries within the buffer. This, in turn, means that gaps will exist within the buffer, as the encoded data blocks will typically not fill the allocated portion of the buffer. However, various other arrangements for storing encoded data blocks will be possible.

[0088] When the encoded data block is subsequently needed, for example, for use, it can therefore be retrieved from its memory location in memory. Specifically, this is done by taking a first reading in the relevant header, and then using that header to determine the memory location in which the encoded data block is stored.

[0089] Therefore, although the techniques described herein have been specifically described above with reference to stored encoded data blocks, it should be understood that the techniques described herein also extend to the corresponding process in which data of an encoded data block is retrieved from memory and then decoded to derive the data values ​​of the data elements of the encoded data block.

[0090] Therefore, another embodiment of the technology described herein includes a method for retrieving data from a block of encoded data from a memory, the method comprising: When the memory location for the encoded data block is determined, a header for the encoded data block, which represents a data element block of a data element array, is read from the memory, wherein the header includes a memory address value and a modification value indicating the amount of modification to be applied to the memory address value; The memory location for the encoded data block is determined by applying this modification to the memory address value; Read the data from the coded data block from the memory at the determined memory location; and Decode the encoded data block to extract at least one data value of the data element of the encoded data block.

[0091] Another embodiment of the technology described herein includes a data processing apparatus for retrieving data from a memory encoded data block, the apparatus comprising: The read control circuit is configured as follows: When the memory location for the encoded data block is determined, a header for the encoded data block, which represents a data element block of a data element array, is read from the memory, wherein the header includes a memory address value and a modification value indicating the amount of modification to be applied to the memory address value; The memory location for the encoded data block is determined by applying this modification to the memory address value; and Read the data from the memory for that coded data block from the determined memory location; and Decoding circuit, which is configured as follows: Decode the encoded data block to extract at least one data value of the data element of the encoded data block.

[0092] As will be understood, these embodiments for retrieving data from a block of encoded data from memory may (and in some embodiments) include, as appropriate, any one or all of the optional features of the techniques described herein, as set forth herein in any embodiment.

[0093] Therefore, for example, an implementation may include (e.g., a device or system) storing coded data blocks in a manner described herein using the techniques described herein, as described herein in any implementation, and may also include retrieving data from coded data blocks in a manner described herein using the techniques described herein, as described herein in any implementation.

[0094] Similarly, (raw and / or encoded and / or decoded) data values, data elements, blocks of data elements, arrays of data elements, headers, regions, etc., may take any desired and suitable form or format, for example, as described herein in any implementation.

[0095] In an implementation of reading the header of an encoded data block from memory, reading the header of the encoded data block from memory can be performed in any desired and suitable manner.

[0096] Reading data from memory into encoded data blocks can also be performed in any expected and appropriate manner.

[0097] In embodiments that assign different regions of a memory location to corresponding sets of adjacent data element blocks, the different regions of the memory location can be accessed in any desired and suitable manner. In these embodiments, the different regions of the memory location can be accessed using memory addresses or memory offsets of the different regions of the memory location in question. As discussed above, the relevant memory addresses or memory offsets can be indicated in the header for the coded data block.

[0098] In any of the above embodiments, the decoding scheme used to derive the data values ​​of the data elements of the encoded data block can take any desired and suitable form, for example, corresponding to the encoding scheme. The decoding operations that may be used in one embodiment are described in more detail in U.S. Patent No. 8,542,939 (Arm Limited), which is incorporated herein by reference.

[0099] Therefore, in one embodiment, the decoding circuitry is operable to decode the data array in the manner described in U.S. Patent No. 8,542,939 (ArmLimited). Thus, the method may include decoding at least a portion of an encoded version of a data element array by using data representing representations of some or all data elements of the data array to determine a value for each of the data elements in the data array.

[0100] The decoding circuit may include any suitable circuit or circuit system of that kind, operable to decode an encoded version of the data element array, and may decode the encoded version of the data element array in any suitable manner.

[0101] In one embodiment, the decoding circuit is operable to decode an array of data elements encoded by the encoding circuit. To do this, in one embodiment, the decoding circuit receives at least a portion of an encoded version of the data element array, for example, by reading the encoded array from a memory storing the encoded array.

[0102] The decoded version of the data element array generated by the decoding circuit should (and in one embodiment does) include a decoded version of at least a portion of the data element array generated by the processing unit, and in one embodiment, a decoded version of all the data element arrays generated by the processing unit.

[0103] In various other implementations, the encoding circuitry may be separated from the processing circuitry that uses (decoded) data values. For example, it may be a separate circuit (e.g., an integrated circuit), which may include a "standalone" decoding unit that is configured to decode and provide (send) an array of data elements to the processing circuitry that uses the data values.

[0104] As will be understood, any of the above retrieval procedures performed relative to the header and / or coded block and / or sub-block and / or data element block slice and / or data element block set may in practice be performed separately for each (e.g., each) of the multiple header and / or coded block and / or sub-block and / or block slice and / or block set of the data element array.

[0105] Similarly, as will be understood, any of the above-described decoding processes performed relative to the data values ​​or data elements of the encoded block and / or sub-block may in practice be performed for each (e.g., each) of the multiple data values ​​or data elements of the encoded block and / or sub-block.

[0106] In any of the above implementation schemes, once determined, the (decoded) data values ​​of the data elements of the encoded block can be used in any desired and appropriate manner.

[0107] The data values ​​can be further processed, for example by processing circuitry (e.g., a graphics processor), which processes the array of data elements in blocks, for example, rather than rows.

[0108] When exporting additional data values, the data values ​​can be used (e.g., via a graphics processor's texture mapper). In these implementations, the array of data elements may correspond to a graphics texture, and the data values ​​may correspond to one or more textures.

[0109] The data values ​​may also be used, or alternatively, for further processing, for example by processing circuitry (e.g., an output (e.g., a display) processor) that processes the array of data elements row by row, for example, rather than block by block.

[0110] Data values ​​(or other data values) can be output (e.g., via an output (e.g., display) processor) for display purposes. In these embodiments, the array of data elements may correspond to frames of graphic data, and the data values ​​may correspond to one or more pixels. In these embodiments, the data values ​​may form part of an output array of data elements. The output array of data elements may be a rotational output relative to a (encoded) stored array of data elements.

[0111] Therefore, the techniques described herein (at least in their implementations) offer various improvements compared to existing methods for storing (and retrieving) coded data blocks from memory.

[0112] In one implementation, operation using the techniques described herein may be selectively activated. However, in another implementation, operation using the techniques described herein is always activated. As mentioned above, the methods of the techniques described herein are readily compatible with data arrays of any size, for example, when the applied modification may include a 'zero' modification (e.g., a 1x scaling factor), in which case addressing can be performed normally.

[0113] In addition to the specific units and components required to operate in the manner described herein, the data processing system may also (and indeed in one embodiment) include one or more (and in one embodiment all) of any other suitable and desirable components, units, processors, etc., that the data processing system may include. Therefore, the data processing system may include one or more (and in one embodiment all) of: a central processing unit, a host processor (or multiple host processors), a graphics processing unit, a video processor, an image signal processor, a camera, a system bus, and a memory controller. In one embodiment, the data processing system includes one or more memory and / or memory devices for storing the data described herein and / or storing software for performing the processes described herein, and / or communicating with said one or more memory and / or memory devices.

[0114] The methods and apparatus of the techniques described herein can be implemented in any suitable manner, such as in hardware or software, and in (and included therein) any suitable device or component.

[0115] The actual apparatus or component used to store data in the manner described herein will depend, for example, on the nature of the data array being stored. Thus, for example, in the case of a graphical texture, a suitable processor such as a personal computer can be used to generate and store the texture in the manner described herein (e.g., by an application developer), and the texture thus stored can then be provided, for example, as part of the game content. In the case where the stored data array is a frame for display, it can accordingly be a graphics processor that generates and stores the data in the desired manner.

[0116] Similarly, from the data reading (decoding) side of the operation, for example, in the case of texture data, it could be a graphics processor that reads (decodes) an array of stored data, and in the case of frames for display, it could be a display controller that reads (decodes) an array of stored data for the display.

[0117] In one embodiment, the techniques described herein are implemented in a graphics processor, display controller, image signal processor, video decoder, or video encoder, and therefore the techniques described herein also extend to graphics processors, display controllers, image signal processors, video decoders, or video encoders configured to operate using methods or devices incorporating the techniques described herein, or methods according to any one or more embodiments of the techniques described herein. Subject to any hardware requiring the performance of the specific functions discussed above, such graphics processors, display controllers, image signal processors, video decoders, or video encoders may additionally include any one or more or all of the generally functional units that a graphics processor, display controller, image signal processor, video decoder, or video encoder may include. In one embodiment, the methods and devices of the techniques described herein are implemented in hardware; in another embodiment, they are implemented in a single semiconductor platform.

[0118] The techniques described herein are specifically, but not exclusively, applicable to low-power and portable devices. Therefore, in one embodiment, the techniques described herein are implemented in a portable device, such as a mobile phone or PDA.

[0119] Similarly, the memory storing data representing coded data blocks in the data array can include any suitable such memory and can be configured in any suitable and desired manner. For example, it can be an on-chip buffer, or it can be external memory (and indeed, it is more likely to be external memory). Similarly, it can be dedicated memory for this purpose, or it can be part of memory used for other data. In one embodiment, the data is stored in the main memory of the system combined with the graphics processor.

[0120] In the case of a texture data array, the memory in one embodiment is a texture buffer for the graphics processing system (which may be on-chip, for example, or in external memory, as needed). Similarly, in the case of a frame for display, the memory in one embodiment is a frame buffer for the graphics processing system and / or for the output of the graphics processing system to be provided to the display therein.

[0121] Of course, other memory arrangements will be possible.

[0122] The techniques described herein can be implemented in any suitable system, such as a properly configured microprocessor-based system. In one embodiment, the techniques described herein are implemented in a computer and / or microprocessor-based system.

[0123] 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 of the technology described herein may include one or more suitable processors, one or more controllers, functional units, circuits / circuit systems, processing logic units, microprocessor arrangements, etc., which are operable to perform various functions, such as appropriate dedicated hardware elements and / or programmable hardware elements that can be programmed to operate in a desired manner.

[0124] 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, various processing stages can share processing circuitry / circuits, etc., if desired.

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

[0126] 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 optional features of the technology described herein, as appropriate.

[0127] The methods described herein can be implemented at least in part using software, such as computer programs. Therefore, it can be seen that embodiments of the techniques described herein include: computer software, particularly suitable for executing the methods described herein when installed on a data processor; computer program elements including computer software code portions for executing the methods described herein when the program elements are run on a data processor; and a computer program including code suitable for executing 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.

[0128] The techniques described herein also extend to computer software carriers that include such software, when used to manipulate data (e.g., graphics), processors, renderers, or other systems including data processors, 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, RAM, flash memory, CD-ROMs, or disks.

[0129] It should also be understood that not all steps of the methods described herein need to be performed by computer software; therefore, other broad embodiments of the techniques described herein include computer software and such software installed on a computer software carrier for performing at least one step of the methods described herein.

[0130] Therefore, the techniques described herein may suitably be embodied as a computer program product used with a computer system. Such implementations may include a set 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. This set of computer-readable instructions embodies all or part of the functionality previously described herein.

[0131] 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-wrapping software), pre-loaded with a computer system on, for example, a system ROM or a fixed disk, or distributed via a network (e.g., the Internet or the World Wide Web) from a server or electronic bulletin board.

[0132] Various implementations of the technology described herein will now be described by way of example only, with reference to the accompanying drawings.

[0133] The accompanying drawings illustrate elements of a data processing apparatus and system related to embodiments of the technology described herein. As those skilled in the art will understand, other elements of the data processing apparatus that are not shown in the drawings may be present. It should also be noted here that the drawings are merely illustrative, and that, for example in practice, even if the elements shown are schematically depicted as separate elements in the drawings, these elements may share essential hardware circuitry.

[0134] As described above, embodiments of the technology described herein involve an arrangement that includes storing coded data blocks in memory. A header is generated for each coded data block.

[0135] Various implementations of the techniques described herein will now be described in the context of processing graphical data used for display. However, the concepts described herein can also be applied to the context of accessing other types of data arrays.

[0136] Figure 1 An embodiment of a data processing system 100 is illustrated schematically, which can store and retrieve data from an array of encoded data elements in a manner described herein.

[0137] In this embodiment, system 100 includes a data processing device in the form of a system-on-a-chip (SoC) 102. System 100 also includes off-chip (main) memory 116 and a display device 118.

[0138] The SoC 102 includes a central processing unit (CPU) 104, a graphics processing unit (GPU) 106, a video codec 108, a display controller 110, an interconnect 112, and a memory controller 114.

[0139] like Figure 1 As shown, CPU 104, GPU 106, video codec 108, and display controller 110 communicate with each other via interconnect 112, and communicate with memory 116 via interconnect 112 and memory controller 114. Display controller 110 also communicates with display device 118.

[0140] In the following implementation, GPU 106 generates and stores encoded graphics data. The encoded graphics data is then read, decoded, and output for display, for example, via display device 118. In other implementations, video codec 108 may encode the graphics data and then store the encoded graphics data and / or may read the encoded graphics data and then decode the encoded graphics data.

[0141] Figure 2 Further details of GPU 106 are shown. In this embodiment, GPU 106 includes a data generator 200 that generates frames of graphics data. In this embodiment, the data generator 200 uses a graphics processing pipeline to generate the graphics data.

[0142] GPU 106 also includes an encoder 202 for encoding graphics data. In doing so, encoder 202 divides frames of graphics data into multiple non-overlapping blocks of similar shape, and then encodes each of those blocks individually. The encoded graphics data blocks are then written to memory 116 via interface 206 through write controller 204. The process of generating and storing encoded data blocks is described in more detail below.

[0143] GPU 106 also includes a read controller 208 that reads data of encoded texture blocks from memory 116 via interface 206. The encoded data of the blocks is then decoded by decoder 210 before being used by texture mapper 212 of data generator 200. The process of retrieving and decoding the data of encoded data blocks is described in more detail below.

[0144] Now refer to Figure 3 A more detailed description of the graphics processing pipeline and rendering process.

[0145] like Figure 3 As shown, the pipeline 300 includes a sequence of different stages, each stage performing different operations on the "primitives" (e.g., polygons) of the surfaces that constitute the features of the frame to prepare them for output.

[0146] The first step in pipeline 300 is vertex shader 302, whose vertex shading primitives are used for the generated output. Vertex shader 302 receives input data values ​​associated with vertices defined for the output to be generated, and processes those data values ​​to generate a set of vertex shading attribute data values ​​for use by subsequent stages of the graphics processing pipeline 300.

[0147] Then, rasterizer 304 operates to rasterize the primitives that constitute the rendering elements output to individual graphics fragments for processing. To do this, when rasterizer 304 receives graphics primitives for rendering, it rasterizes these primitives into sample points and generates graphics fragments representing the appropriate sample locations for the rendering primitives. The fragments generated by rasterizer 304 are then forwarded to the rest of pipeline 300 for processing.

[0148] The graphic fragments generated by rasterizer 304 are then passed to renderer 306 for shading. The output of renderer 306 is a set of color values, for example, for the sampled positions of the frame, appropriately shaded. The output of renderer 306 is then stored in frame buffer 310 of memory 116.

[0149] The renderer 306 includes a number of different processing units, such as a fragment shader, a mixer, and a texture mapper 212. Specifically, as... Figure 3As shown, renderer 306 specifically accesses encoded textures stored in texture buffer 308, which is accessible by GPU 106, in order to apply the relevant textures to the fragments it is rendering. The memory where texture buffer 308 resides may be on-chip or in external memory (e.g., memory 116), which is accessible by GPU 106.

[0150] GPU 106 uses the retrieval process of the embodiment described herein relative to the encoded texture stored in texture buffer 308. Therefore, when renderer 306 needs to access texture values, texture buffer 308 is read by read controller 208 in the manner described herein.

[0151] GPU 106 also uses the stored procedures of the embodiment described herein for the encoded output data to be stored in frame buffer 310. Thus, when the generated output data from GPU 106 is written to frame buffer 310, the data is encoded by encoder 202 and then written to frame buffer 310 by write controller 204 in the manner described herein.

[0152] The encoded output data can then be read from frame buffer 310 in the manner described herein and decoded, for example, by display controller 110 for display device 118 on which the frame to be displayed. Therefore, in this embodiment, display controller 110 includes a read controller and decoder similar to GPU 106. In other embodiments, video codec 108 may include a read controller and decoder and / or a write controller and encoder similar to GPU 106.

[0153] Of course, other arrangements of the data processing system 100 are also possible. For example, the rendering performed may include ray tracing, hybrid ray tracing, or any other suitable rendering technique as needed, in which case the processing (rendering) of the set of geometry may be performed accordingly.

[0154] Now refer to Figures 4A to 7 The process of encoding and storing blocks of data elements (such as textures or frames of graphics data) is described in more detail.

[0155] Figure 4AAn array 400 of data elements to be encoded and stored is shown. In this embodiment, the data element array 400 is part of a frame of graphic data and has a size of 128×128 data elements. In this embodiment, each data element has an RGBX8 format. Therefore, each data element includes 8 bits of red (R) data value, 8 bits of green (G) data value, 8 bits of blue (B) data value, and 8 bits of transparency (α) data value, giving a total of 32 bits per data element. Of course, other array sizes and data element formats can be used as needed.

[0156] like Figure 4A As shown, for encoding purposes, the data element array 400 is divided into 64 (i.e., 8×8) blocks 402. In this embodiment, each block 402 is 16×16 data elements in size. Therefore, in these embodiments, each block is 1024 bytes in size (i.e., 16×16×32 / 8). For example, these square block implementations may be particularly effective when the data element array is rotatable (e.g., for display) and / or can be further processed by a processing circuitry system (e.g., a graphics processor) that typically processes data element arrays by blocks rather than by rows.

[0157] Of course, other block sizes can be used as needed, such as data element blocks of 32×8 data elements. For example, these rectangular block implementations may be more efficient when the data element array may not be rotated (e.g., for display) and / or can be further processed by processing circuitry (e.g., output (e.g., display) processors) that typically process data element arrays row by row rather than block by block, while still being efficient if the data element array happens to be rotated and / or processed by processing circuitry (e.g., graphics processors) that typically process data element arrays block by block rather than row by block.

[0158] For example Figure 4A As shown, for encoding purposes, the data element block is further divided into 16 (i.e., 4×4) sub-blocks 404. In this implementation, each sub-block 404 is 4×4 data elements in size. Therefore, in these implementations, each sub-block is 64 bytes in size (i.e., 4×4×32 / 8). Other sub-block sizes can also be used as needed.

[0159] In this embodiment, the encoding scheme used to encode block 402 of array 400 is, in particular, a lossless entropy encoding scheme that determines the minimum data value and difference value set for each data element of block 402 and sub-block 404 for each type of data value represented by the data elements of block 402 (i.e., for each of R, G, B, and α). Therefore, the encoded version of block 402 includes the minimum data value and difference value set for each data element of block 402 and sub-block 404.

[0160] In this implementation, the data size of the encoded version of a block is not fixed and is based on the specific data values ​​of the block. For example, a block 402 with substantially uniform color will have a smaller data size when compressed into an encoded block than a block 402 with more highly varied colors.

[0161] Further details of suitable encoding schemes can be found, for example, in U.S. Patent No. 8,542,939 (Arm Limited) or U.S. Patent No. 9,014,496 (Arm Limited), the entire contents of which are incorporated herein by reference. Other encoding schemes may, of course, be used as needed.

[0162] As will be understood, the encoding process is repeated for each block 402 to be encoded.

[0163] Figure 4B An embodiment of a data array for storing the generated data to represent the technology described herein in memory is schematically illustrated.

[0164] Figure 4B The raw data array 20 is illustrated again. This raw data array is a two-dimensional data array containing multiple data elements (data entries at multiple specific locations within the array) and is to be encoded, compressed, and stored. As discussed herein, data array 20 can be any suitable and desired data array, but in the context of graphics processing, it may be, for example, a texture map (i.e., an array of texture (meta) elements) or a data array representing a frame to be displayed (in this case, the data array could be an array of pixels to be displayed). In the case of a texture map, each data entry (location) in the data array will represent an appropriate meta value (e.g., a set of color values, such as RGBa, or luminance and chrominance, meta values). In the case of a frame for display, each data entry (location) in the array will indicate a set of color values ​​(e.g., RGB values) to be used to display the frame on the display.

[0165] like Figure 4B As shown, in order to store the data array 20 in memory, the data array 20 is first divided into multiple non-overlapping, equally sized, and uniform blocks 21, each block corresponding to a specific region of the data array 20. As discussed above, in this embodiment, each block 21 of the data array corresponds to a block of 16×16 elements (positions) within the data array 20 (i.e., a block of 16×16 pixels in the case of texture mapping). (Other arrangements are, of course, possible.)

[0166] The data array 20 is further subdivided into blocks 21, each of which is a set of sixteen non-overlapping, uniform, and equal-sized sub-blocks 22. In this case, while each block 21 corresponds to a 16×16 element (position) within the data array, each sub-block 22 correspondingly corresponds to a 4×4 data element region within block 21 (e.g., a 4×4 texture in the case of a texture map). (For simplicity, Figure 4B Only some blocks 21 of the data array 20 are shown being divided into sub-blocks. However, each block 21 into which the original data array 20 is divided is correspondingly subdivided into a set of multiple sub-blocks 22.

[0167] To store the data array 20 in memory, header data blocks 23 are first stored for each block 21 into which the data array 20 has been divided. These header data blocks are stored in a header buffer 24 in memory. The header buffer 24 begins at a starting address A in memory, and each header data block 23 is stored at a predictable memory address within the header buffer 24.

[0168] Figure 4B The blocks 21 into which the data array 20 is divided indicate the locations of header data blocks 23 in the header buffer 24. Each block 21 into which the data array 20 is divided has a corresponding header data block 23 in the header buffer 24. The location of each header data block 23 stored in the header buffer 24 is determined (predicted) from the location within the data array of the block 21 (to which the header data block 23 is associated).

[0169] In this embodiment, each header data block 23 in the header buffer 24 has the same fixed size, which corresponds to the burst size used by the data processing system of the data array to be used in it. This means that the header data block 23 has a size that can be obtained using a system-friendly burst size.

[0170] The corresponding header data block 23 is stored in the header buffer 24 for each block 21 into which the original data 20 is divided. The data storage arrangement of this embodiment also stores data for each sub-block 22 into which a given data block is divided. This sub-block data is stored in memory within a sub-block storage body block 35, which in this embodiment includes an alignment block of 1024 bytes. (Having the body block store sub-block data in a 1024-bit sub-block storage block provides the ability to encode the data array in parallel with several different encoders by allocating new blocks from a central repository each time space is exhausted.) In this embodiment, the body block 35 is stored directly after the header buffer 24 (but this could occur in a random order). This allows pointer data in the header data block to be in the form of an offset from the end of the header buffer 24. (This is not required, and the body block 35 can reside anywhere in memory if needed.)

[0171] The set of data for each corresponding sub-block is stored one after another in the main block, such as... Figure 4B As shown. Then, doing so has the following effect: the data of a given set of sub-blocks 22 of a 16×16 block 21 can span two different main blocks 35 (e.g., Figure 4B (See Figure 27 for the set of sub-block data).

[0172] Figure 4C A header 406 and an encoded data block 408 are shown. In this example, the header 406 will be stored in a "header buffer" of memory 116, and the encoded data block 408 will be stored in a "body buffer" of memory 116. The header buffer and the body buffer may, for example, form part of a frame buffer or a texture buffer.

[0173] In this example, such as Figure 5A As shown, header 406 includes a 32-bit memory address value field 407, which stores the offset from the beginning of the header buffer to the corresponding encoded data block in the body buffer. This offset allows the encoded data block to reside in memory. Header 406 also contains a number of other fields, but these are not relevant to the discussion of this embodiment (and therefore will not be described here).

[0174] In this example, the memory location (payload address) for storing the encoded data block is therefore calculated as follows: Payload_address = header_pointer + offset.

[0175] It should be understood that the size of the offset value (32 bits in this example) thus limits the range of memory addresses that can be indicated in the header. This means that the encoding techniques described above may not support larger frame sizes, and there are frame size limitations to which the encoding techniques can be applied. Frame size limitations can typically depend on the data format.

[0176] Therefore, this implementation modifies the header to include a scaling factor that can be applied to the offset in order to expand the range of accessible memory addresses, as will be explained further below.

[0177] therefore, Figure 5B A modified header 506 for an encoded data block is shown according to an embodiment of the technology described herein. In this embodiment, a set of bits from the 32-bit offset field 407 (in this example, the two most significant bits) is reused to store an indication of the scaling factor 500 to be applied.

[0178] The scaling factor 500 is a 2-bit code for a set of scaling factors (1x, 16x, 64x, and 256x), which can be encoded using the corresponding modification values ​​00, 01, 10, and 11. Therefore, the payload address can be calculated using the scaling factor as follows: Payload_address = header_pointer + offset Scale factor.

[0179] Then, a scaling factor is dynamically applied to each block in the frame. Thus, the scaling factor is initially set to 1x (modifying the value "00") at the beginning of the block and is only increased if the calculated offset exceeds the available address range.

[0180] This method also means according to Figure 5B The new header format is backward compatible with smaller frames because, in this case, a 1x scaling factor is sufficient.

[0181] Figure 6 The overall header generation process according to the implementation of the technology described herein is illustrated.

[0182] For the coded data block to be stored in memory, the complete address offset is first calculated (step 600). Based on this complete address offset, an appropriate scaling factor is then determined (step 601).

[0183] The full address offset is then encoded into the header using the scaling factor, with the encoded offset 407 and scaling factor 500 appropriately included in the header (step 602). The header can then be written to the header buffer and the encoded data block can be written to the indicated memory location.

[0184] When a block of data needs to be encoded subsequently, it is then retrieved from its memory location and decoded, etc., for use. Figure 7 The overall decoding process corresponding to the implementation scheme according to the technology described herein is shown.

[0185] For the required encoded data block, the decoding circuit first reads the associated header and extracts the encoded offset 407 and the associated scaling factor 500 (step 700). Then, by applying the indicated scaling factor, the complete address offset is calculated accordingly based on the encoded offset (step 701). The payload address can then be appropriately determined based on the complete address offset (step 702).

[0186] Once the payload address is determined, the payload can be acquired (step 703) and decoded (step 704). The decoded data can then be output accordingly, for example, for use and / or for display as needed.

[0187] As can be seen from the above description, the technology described herein, in its implementation, provides at least an efficient way to extend the range of accessible memory addresses, which can be indicated within the header of the coded data block. Furthermore, this can be accomplished with minimal additional overhead and without significantly modifying the existing header structure. Therefore, the technology described herein offers various benefits compared to other methods.

[0188] The specific embodiments described above are presented for illustrative and descriptive purposes only. They are 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 teachings above. 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 storing coded data blocks in a memory, the method comprising: Encode the data element blocks of the data element array to generate encoded data blocks representing the data element blocks; Determine the memory location where the encoded data block will be stored; Generate a header for the encoded data block, the header indicating the memory location where the encoded data block is stored, wherein, when determining the memory location, the memory location is indicated by including a memory address value and a modification value in the header, the modification value indicating the amount of modification to be applied to the memory address value; as well as The header and the encoded data block are written to the memory, wherein the encoded data block is stored in the memory at the location indicated in the header for the encoded data block.

2. The method of claim 1, wherein the modification value represents a scaling factor to be applied to the memory address value when determining the memory location.

3. The method according to claim 1 or 2, wherein the memory address value represents an offset, and wherein the modification can be applied to the offset to generate a modified offset, the modified offset being used to determine the memory location.

4. The method according to claim 1 or 2, comprising: The header includes a value representing the determined modification and the memory address value. The header is used to determine which of the multiple available modification values ​​should be used with the memory address value to indicate the memory location where the encoded data block is to be stored.

5. The method of claim 4, wherein one of the available modification quantities includes a zero modification quantity that does not modify the memory address value.

6. The method of claim 1 or 2, further comprising storing a plurality of encoded data blocks sequentially in corresponding memory locations, wherein the encoded data blocks are stored in progressively increasing memory locations, and wherein the method comprises initially setting the modification value to zero modification, and increasing the modification value when the memory location for the encoded data block exceeds a range of memory addresses accessible with the zero modification.

7. The method of claim 1 or 2, wherein a number of bits from a memory address field are used to store the modified value, the number of bits originally intended to store the memory address value.

8. The method according to claim 1 or 2, wherein each of the encoded data blocks is allocated a fixed amount of space in the memory and stored in the memory at a predefined location, the predefined location being aligned with the corresponding boundary of the allocated amount of space.

9. The method of claim 1, wherein the memory corresponds to a frame buffer for a graphics processing system and / or for the output of the graphics processing system to be provided to a display therein.

10. A method for retrieving data from a coded data block of memory, the method comprising: When the memory location for the encoded data block is determined, a header for the encoded data block, which represents a data element block of a data element array, is read from the memory, wherein the header includes a memory address value and a modification value indicating the amount of modification to be applied to the memory address value; The memory location for the encoded data block is determined by applying the modification amount to the memory address value; Read the coded data block from the memory from the determined memory location; as well as The encoded data block is decoded to extract at least one data value of a data element of the encoded data block.

11. The method of claim 10, wherein the modified value represents a scaling factor to be applied to the memory address value to determine the memory location.

12. The method of claim 10 or 11, wherein the memory address value represents an offset, and wherein the modification can be applied to the offset to generate a modified offset, the modified offset being used to determine the memory location.

13. The method of claim 10, wherein the memory corresponds to a frame buffer for a graphics processing system and / or for the output of the graphics processing system to be provided to a display therein.

14. An apparatus for storing coded data blocks in a memory, the apparatus comprising: An encoding circuit configured to encode data element blocks of a data element array to generate encoded data blocks representing the data element blocks; A header generation circuit is configured to: determine a memory location in which the encoded data block is to be stored; and generate a header for the encoded data block, wherein the header indicates the memory location where the encoded data block is stored, wherein, when determining the memory location, the memory location indicated by the header generation circuit includes a memory address value and a modification value in the header, the modification value indicating the amount of modification to be applied to the memory address value; and A write control circuit configured to write the header and the encoded data block to a memory, wherein the encoded data block is stored in the memory at the location indicated in the header for the encoded data block.

15. The device of claim 14, wherein the modification value represents a scaling factor to be applied to the memory address value when determining the memory location.

16. The device of claim 14 or 15, wherein the memory address value represents an offset, and wherein the modification can be applied to the offset to generate a modified offset, the modified offset being used to determine the memory location.

17. The apparatus of claim 14 or 15, wherein the header generation circuitry is configured to: determine from a plurality of available modification amounts which one of the plurality of available modification amounts should be used with the memory address value to indicate the memory location in which the encoded data block is to be stored, and include in the header the modification amount value representing the determined modification amount and the memory address value.

18. The device of claim 17, wherein one of the available modification quantities includes a zero modification quantity that does not modify the memory address value.

19. The apparatus of claim 14 or 15, wherein when a plurality of encoded data blocks are stored sequentially in corresponding memory locations, wherein the encoded data blocks are stored in progressively increasing memory locations, the header generation apparatus is configured to initially set the modification value to zero modification, and to increase the modification value when the memory location for the encoded data block exceeds the range of memory addresses accessible with the zero modification.

20. The device of claim 14 or 15, wherein a number of bits from a memory address field are used to store the modified value, the number of bits originally intended to store the memory address value.

21. The device of claim 14 or 15, wherein each of the coded data blocks is allocated a fixed amount of space in the memory and stored in the memory at a predefined location, the predefined location being aligned with the corresponding boundary of the allocated amount of space.

22. The device of claim 14, wherein the memory corresponds to a frame buffer for a graphics processing system and / or for the output of the graphics processing system to be provided to a display therein.

23. A data processing apparatus for retrieving data from a memory encoded data block, the data processing apparatus comprising: The read control circuit is configured to: When the memory location for the encoded data block is determined, a header for the encoded data block, which represents a data element block of a data element array, is read from the memory, wherein the header includes a memory address value and a modification value indicating the amount of modification to be applied to the memory address value; The memory location for the encoded data block is determined by applying the modification amount to the memory address value; and Read the coded data block from the memory from the determined memory location; and Decoding circuit, the decoding circuit being configured as follows: The encoded data block is decoded to extract at least one data value of a data element of the encoded data block.

24. The data processing apparatus of claim 23, wherein the modification value represents a scaling factor to be applied to the memory address value to determine the memory location.

25. The data processing apparatus of claim 23 or 24, wherein the memory address value represents an offset, and wherein the modification can be applied to the offset to generate a modified offset, the modified offset being used to determine the memory location.

26. The data processing apparatus of claim 23, wherein the memory corresponds to a frame buffer for a graphics processing system and / or for the output of the graphics processing system to be provided to a display therein.

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

Images