Patent Description:
Textures are used heavily within the field of graphics processing. Textures may be used to represent surface properties, illumination (e.g. within the environment of a scene being imaged) or to apply surface detail to an object being rendered. Textures may require relatively large amounts of memory storage, and texture accesses can contribute a significant proportion of a graphics device's memory bandwidth. As such, it is often desirable to compress texture data.

One texture compression format is known as Adaptive Scalable Texture Compression (ASTC).

In ASTC, a compressed image, or texture, is subdivided into a plurality of data blocks, where each data block represents the texture data for a block of texels forming the texture. Each block of data has a fixed memory footprint (i.e. has a fixed size) of <NUM> bits. However, the data blocks are capable of representing the texture data for a varying number of texels. The number of texels represented by a single data block may be referred to as the block footprint. The block footprint may be fixed for a given texture. The block footprint's height and width (in texels) are generally selectable from a number of predefined sizes. The footprint may be rectangular, and in some cases the block's footprint may be square. For <NUM>-D textures, examples of block footprints include <NUM> x <NUM> texels; <NUM> x <NUM> texels; <NUM> x <NUM> texels and <NUM> x <NUM> texels (giving compression rates of <NUM> bits per pixel (bpp); <NUM> bpp; <NUM> bpp and <NUM> bpp respectively).

The colour of each texel within a block is defined as a point on a linear gradient between a pair of colours. This pair of colours is referred to as a pair of "colour endpoints". Colours for each texel can be calculated by interpolating between a pair of colour endpoints. An interpolant weight can be used to specify a weighted average of the two colour endpoints (i.e. the position on the linear gradient between those colour endpoints) to thereby define the colour for that texel. This process is illustrated schematically in <FIG>, which shows a pair of colour endpoints A (denoted <NUM>) and B (denoted <NUM>) in a red-blue (RB) colour space denoted <NUM>. In this example, each texel can have one of five weights: <NUM>/<NUM> (corresponding to colour A); <NUM>/<NUM>; <NUM>/<NUM>; <NUM>/<NUM>; or <NUM>/<NUM> (corresponding to colour B). An example of the texel weights for each texel of a <NUM> by <NUM> block is shown in <FIG>. Though shown for the simple example of an RB colour space, the same approach is applied when working in different colour spaces such as RGB or RGBA.

Each colour endpoint may be composed of one or more colour values. A colour endpoint may be composed of up to a maximum of four colour values. When decoding a texel, colour values are decoded from the data block and those values are then converted into colour endpoints. The way colour values are converted into colour endpoints is defined by a parameter known as the colour endpoint mode. Information on the colour endpoint mode for a texel is encoded within the data block. The ASTC specification defines <NUM> possible colour endpoint modes, which vary from computing a colour endpoint from a single colour value up to computing a colour endpoint from four colour values.

The interpolant weights may be stored in the form of a weight grid, which is a <NUM>-D grid of weight values corresponding to the block of texels represented in the data block. In certain encodings, an interpolant weight may be stored for each texel in the data block (i.e. the dimensions of the weight grid correspond to the dimensions of the block footprint). However, for data blocks that represent texture data for a larger number of texels (e.g. <NUM> x <NUM> texels), there may not be enough data within the block to store an interpolant weight for each texel. In this case, a sparser weight grid may be stored that contains fewer weights than the number of texels within each data block. A weight for each texel in the data block can then be calculated from an interpolation of this sparser weight grid.

In order to do this, the coordinates of a texel within the block are first scaled to the dimensions of the weight grid. The coordinates are scaled by a scale factor that scales the dimensions of the weight grid to the dimensions of the block footprint. The re-scaled position of the texel with respect to the weight grid is then used to select a subset of weights of the weight grid and to interpolate those to calculate a weight for the texel. For example, four weights from the weight grid may be selected and interpolated to calculate the weight for a texel.

In certain cases, a single pair of colour endpoints can be used to calculate the colour for each texel within a data block. However, in other cases, a block may represent texels which have a mixture of different colours that cannot reasonably be represented by interpolating between a single pair of colour endpoints. To get around this problem, each texel in the data block can be assigned to one of up to four partitions, where each partition is associated with its own colour endpoint pair. To determine the colour of a texel within the block, the partition that the texel belongs to is determined and the colour calculated from the interpolant weight for that texel and the colour end point pairs associated with the partition. The interpolant weight can be stored and encoded within the data block independently of the colour end point pair (i.e. independently of the partition to which the texel belongs).

This is illustrated schematically in <FIG> shows a first colour endpoint pair <NUM> formed of endpoint colours A and B, and a second colour endpoint pair <NUM> formed of endpoint colours C and D within an RB colour space <NUM>. The first endpoint pair belongs to a first partition and the second endpoint pair belongs to a second partition. Thus in this example there are two partitions. Each colour endpoint pair can be interpolated between with five weights. <FIG> shows a block of texels <NUM> represented by a block of texture data. A partitioning mask is shown overlaid on the block of texels indicating which partition each texel belongs to. The partitioning mask is a grid of values, where each value indicates which partition a texel belongs to. Each value may as such be referred to as a partition index. In particular, a value of <NUM> indicates a texel belongs to the first partition (associated with colour endpoint pair <NUM>); and a value of <NUM> indicates a texel belongs to the second partition (associated with colour endpoint pair <NUM>). The weights for each texel are also shown. To determine the colour for a texel, the partition index is used to identify the colour endpoint pair, and the weight is used to interpolate between that pair. For example, texel <NUM> has a partition index of <NUM>, and a weight of <NUM>/<NUM> and thus has a colour defined by the position <NUM> in RB colour space. Texel <NUM> has a partition index of <NUM> and a weight of <NUM>/<NUM> and so has a colour defined by the position <NUM> in RB colour space.

Whilst ASTC can provide an effective way of compressing texture data, the decoding of texture data that is compressed in accordance with ASTC can suffer from certain drawbacks.

Texture data compressed in accordance with the ASTC format can be decoded, or decompressed, by an ASTC decoder. Typically, these decoders operate to decode a single texel from a block of data (where that data block contains data for at least a <NUM> x <NUM> block of texels). This means that if it is desired to decode more than one texel from the block at the same time (for example to use the decoded texels in a filtering operation), multiple decoders are needed to decode the block of data in parallel. This may costly in terms of hardware resources and silicon area.

"<NPL>et al. is an ASTC specification document intended to be a complete and correct specification of all ASTC features. <CIT> relates to a decoding system and method operable on encoded texture element blocks. The decoders described in <CIT> are designed to be suitable to handle texel blocks encoded according to "PLANAR". "<NPL> investigates low-bitrate compression of scalar textures such as alpha maps.

According to the present invention there is provided a decoder configured to decode a plurality of texels from a received block of texture data encoded according to the Adaptive Scalable Texture Compression (ASTC) format as claimed in claim <NUM>.

According to a second aspect of the present disclosure there is provided a method of decoding, using a decoder, a plurality of texels from a received block of texture data encoded according to the Adaptive Scalable Texture Compression (ASTC) format as claimed in claim <NUM>.

The present disclosure will now be described by way of example with reference to the accompanying drawings. In the drawings:.

The present disclosure is directed to a multi-output decoder that is capable of decoding multiple texels from a block of texture data compressed according to the Adaptive Scalable Texture Compression (ASTC) format. The block of texture data may represent, or encode, an n by m block of texels. The size of the n by m texel block (as governed by the values of n and m) may be referred to as the block's footprint, and is selectable from a number of predefined sizes specified by the ASTC standard. The size of the texture data block (referred to as its memory footprint) is fixed at <NUM> bits. The multi-output decoder is capable of decoding a number of texels nt in the range <NUM> ≤ nt ≤ nm from a single received data block. For example, the multi-output decoder may decode a block of p by q texels from the texture data block, where p ≤ n and q ≤ m.

In order to decode texels from the texture data block, intermediate data is decoded from the received data block that is used during the decoding process in order to decode the final texel colour values. The intermediate data is data decoded from the block that is used during part of the decoding process, but may not itself represent a final decoded texel colour. Part of this intermediate data is common to the decoding of at least a subset (i.e. one or more texels) of the plurality of texels being decoded from the received data block. Part of this intermediate data may be independent of the texels being decoded from the block - that is, part of the intermediate data for a given data block is the same regardless of how many, or which, texels from that block are being decoded. In other words, a part of the intermediate data is common to the decoding of each texel from the texture data block. This data is data that is specified per block.

Examples of this common intermediate data will be explained in more detail below, but include for example the number of partitions of the data, the number of texture planes and the range of weight values. It has been appreciated that for a multi-output decoder, some or all of this common decoded intermediate data may be used for the decoding of at least two of the plurality of texels being decoded from the data block. In some cases, a portion or all of the common intermediate data may used for the decoding of each of the plurality of texels. That is, rather than decode this intermediate data for each of the texels being decoded from the block, the intermediate data can in some cases be decoded only once and that same data then used as part of the decoding of each of the plurality of texels from the texture data block. Thus, the same instance of per-block data may be used as part of the decoding of each of the plurality of texels from the texture data block. This allows the same hardware in the decoder to be used as part of the decoding of each of the multiple texels. This in turn means the multi-output decoder can operate to decode multiple texels from the block in parallel without commensurate increases in the size of the decoding hardware compared to operating a plurality of conventional ASTC decoders in parallel which each only decode only a single texel from a block of texture data.

<FIG> shows a schematic illustration of a multi-output decoder <NUM> for decoding a plurality of texels from a block of texture data encoded according to an ASTC format.

The decoder comprises a parameter decode unit <NUM>, a colour decode unit <NUM>, a weight decode unit <NUM> and at least one interpolator unit <NUM>. It is to be understood that, in embodiments of the claimed invention, the texels represented by the block are partitioned into np partitions and the decoder comprises np interpolator units. References herein to decoders not comprising np interpolator units are not according to the claimed invention and are present for illustration purposes only. The parameter decode unit is coupled to the colour decode unit and the weight decode unit. In particular, an output of the parameter decode unit is coupled to an input of both the weight decode unit and colour decode unit. Each of the colour decode unit and the weight decode unit are coupled to the at least one interpolator unit. More specifically, an output of the weight and colour decode units is coupled to an input of the interpolator unit(s).

The decoder <NUM> is configured to receive as an input a block of ASTC-encoded texture data, shown at <NUM>. As mentioned above, the block has a size, or memory footprint, of <NUM> bits. The texture data block <NUM> encodes texel colours for an n by m block of texels. That n by m block of texels may form part of a compressed image, or texture. The texture may be composed of a plurality of such texture blocks, with each of those blocks being encoded in a respective <NUM>-bit data block. The number of texels represented by block of texture data is referred to as the block footprint. The dimensions of the block (i.e. the values of n and m) are selectable from a number of fixed alternatives specified by the ASTC standard.

The decoder is capable of decoding a plurality of texels from the texture block <NUM>. The maximum number of texels capable of being decoded from the single received block <NUM> is denoted nt. The decoder decodes a plurality of texels in parallel. The decoder may for instance comprise a plurality of outputs for outputting a respective decoded texel. The decoder may operate to decode the plurality of texels according to a decoding process. That decoding process may comprise a series of decoding steps, or operations. The series of steps undergone to decode a particular texel may be referred to as a decoding pipeline. Thus, the decoder <NUM> may operate to decode a plurality of texels from block <NUM>, where each texel is decoded according to decoding pipeline. As will be appreciated from the following, the decoder <NUM> may be configured to, or be capable of, decoding any number of texels from the block <NUM>. That is, <NUM> ≤ nt ≤ nm. The value of nt may vary by implementation. The decoder may decode a contiguous p by q block of texels from the block of data <NUM>, where p ≤ n and q ≤ m.

In the following example, for the purposes of illustration the block of texture data <NUM> represents a <NUM> by <NUM> block of texels, and the decoder operates to decode nt texels from the data block <NUM>, with the nt texels being arranged as a <NUM> by <NUM> sub-block of texels. Though just an example, decoding a <NUM> by <NUM> sub-block of texels from the data block <NUM> may be particularly useful due to the use of <NUM> by <NUM> texel blocks in a variety of filtering operations including, for example, bi-linear filtering, tri-linear filtering and anisotropic filtering. The blocks of textures are illustrated schematically in <FIG>. Here, the block footprint of the data block <NUM> is illustrated at <NUM>, which is the n by m block of texels represented by the block of data <NUM>. The p by q sub-block of texels to be decoded by the decoder <NUM> is shown at <NUM>, and is formed of texels <NUM>A,B,C,D. The texture data represented by the data block may be partitioned into a plurality of partitions.

The parameter decode unit <NUM> receives the data block <NUM>. The parameter decode unit operates to decode configuration data for the block <NUM>. The configuration data may be data that specifies parameters of the texture data and its encoding within the block <NUM>. The configuration data could include, for example: the size of the weight grid and/or the range of the weight values; an indication of whether the texture data is single plane or dual plane; the partition count (i.e. the number of partitions for the data block <NUM>) and the colour endpoint modes.

The colour decode unit <NUM> decodes colour endpoint data for each of the nt texels being decoded from the block <NUM> using the configuration data decoded from the data block <NUM>. The colour endpoint data includes a pair of colour endpoints for each of the texels being decoded. If the block of data has a partition count of one, then each of the texels being decoded is associated with the same colour endpoint pair. The colour endpoint data may include up to eight colour endpoints forming four colour endpoint pairs (for a partition count of four - i.e. one colour endpoint pair per partition). One or more of the colour endpoints may be associated with multiple texels of the group of texels being decoded from the data block <NUM>; i.e. some of the texels being decoded may share a common colour endpoint, or common colour endpoint pair. For example, if more than four texels are being decoded in parallel from the data block <NUM>, at least two of those texels will share a common colour endpoint or colour endpoint pair because the ASTC standard limits the number of partitions to a maximum of four (and thus the number of colour endpoint pairs is limited to a maximum of four).

The weight decode unit <NUM> decodes interpolation weight data for each of the nt texels being decoded from the block <NUM> using the configuration data decoded by the parameter decode unit <NUM>. The interpolation weight data for a given texel could be a single weight (e.g. if the texture data in the block is single plane) or a pair of weights (e.g. if the texture data in the block is dual-plane). Thus the weight decode unit may decode a weight for each texel being decoded from the block <NUM>, or a pair of weights for each texel being decoded from the block <NUM>. These weight values are received by the interpolation unit(s) <NUM>.

The interpolation units <NUM> calculate a colour value for each of the texels nt being decoded using the colour endpoint data for each texel and the weight value for each texel.

The decoder <NUM> may then output the decoded colour values for each of the nt texels. That is, the decoder may output nt texel colour values. These may be outputted in parallel.

An example of the parameter decode unit <NUM> is shown in more detail in <FIG>. As shown, the parameter decode unit <NUM> comprises a block mode unit <NUM>; a colour endpoint unit <NUM> and a partition index unit <NUM>.

The block mode unit <NUM> is configured to decode a portion of the configuration data including the weight grid size (its height and width, i.e. its dimensions) and the range of weight values that can be occupied by the weights of the weight grid.

The partition index unit <NUM> is configured to calculate a partition index for each of the texels to be decoded from the block <NUM> (in this example, texels <NUM>A-D). The partition index identifies which partition each texel belongs to, and is an example of a configuration parameter.

The partition index for each texel is computed from a seed, the partition count and the coordinate of the texel within the block <NUM>. The seed, partition count and texel coordinates may be referred to as intermediate configuration data since they are examples of data that are used in order to decode a configuration parameter (the partition index), but are themselves not configuration parameters. The partition count is decoded from the data block <NUM> by a partition count unit <NUM> that forms part of the partition index unit <NUM>. The seed is computed by a seed computation block <NUM> from a partition pattern index decoded from the data block <NUM>. The coordinates of the texels are computed by a texel coordinate unit (TCU) <NUM>. The TCU <NUM> may comprise hardware for calculating the coordinates of each of the texels <NUM>A-D in parallel. The partition index unit comprises an index calculator <NUM> for calculating the partition index from the seed, partition count and texel coordinates. The index calculator calculates a partition index for each of the texels <NUM>A-D being decoded.

The colour endpoint unit <NUM> is configured to decode the colour endpoint modes from the data block <NUM>. In the case that the texture data has a partition count greater than one (i.e. there are multiple partitions), the colour endpoint unit may decode the colour endpoint mode for each partition. As described above, the colour endpoint modes specify how colour values decoded from the block <NUM> are to be converted into colour endpoints. In general, the ASTC specification specifies <NUM> possible colour endpoint modes, where the modes require differing numbers of colour values to form a colour endpoint. In particular, four of the modes form a single colour endpoint from a single colour value (e.g. luminance), and thus require two colour values for each colour endpoint pair; four of the modes form a single colour endpoint from two colour values, and thus require four colour values for each colour endpoint pair; four of the modes require three colour values to form each colour endpoint, and thus require <NUM> colour values for each colour endpoint pair; and four of the modes require four colour values to form a single colour endpoint (e.g. RGBα), and thus require <NUM> colour values for each colour endpoint pair.

A portion of the configuration data decoded and/or calculated by the parameter decode unit <NUM> is independent of the texels being decoded from the data block <NUM>. That is, a portion of the configuration data for the block <NUM> is the same regardless of the texels being decoded from that block. The portion of configuration data is therefore common to the decoding of each of the plurality of texels being decoded from the texture data block. This data can be said to be specified per data block, rather than per texel. In some cases, this portion of 'per-data-block' configuration data may form a substantial portion of the configuration data.

Conveniently, this per-block configuration data decoded by the parameter decode unit may be used by the colour decode unit <NUM> and weight decode unit <NUM> as part of the decoding process for each of the texels <NUM>A-D (i.e. for each of the nt texels being decoded). A first subset, or portion of the per-block configuration data may be used by the colour decode unit and a second subset, or portion, of the per-block configuration data may be used by the weight decode unit. That is, the colour decode unit may use a first portion of the per-block configuration data to decode the endpoint data for all the texels <NUM>A-D; and the weight decode unit may use a second portion of the per-block configuration data to decode the interpolation weight data for all the texels <NUM>A-D. This means that the parameter decode unit need not decode the per-block configuration data nt times when the decoder <NUM> is to decode nt texels from the block in parallel. Instead, the parameter decode unit <NUM> only decodes the per-block configuration data once when the decoder <NUM> decodes nt texels in parallel from the block <NUM>. This in turn means the parameter decode unit <NUM> does not need hardware to decode the per-block configuration data nt times in parallel, leading to potential hardware savings.

In this particular example, the weight grid size and the range of weight values are examples of configuration data that are independent of the texels being decoded from the block <NUM>, and thus these same configuration parameters are used in the decoding of each of the texels <NUM>A-D. Thus the block mode unit <NUM> is formed of substantially the same hardware as if the decoder <NUM> were only a single-output decoder. Put another way, the block mode unit <NUM> can be shared across, or used as part of, the decoding pipelines for each of the texels to be decoded from the block <NUM>.

The colour endpoint mode data decoded by the colour endpoint unit <NUM> is also independent of the texels being decoded from the block <NUM>. Thus the same colour endpoint mode data decoded by this unit is used in the decoding of each of the texels <NUM>A-D. In other words, this data is shared across the decoding pipelines for each of the texels being decoded.

With respect to the partition index unit <NUM>, both the partition count and the seed (generated from the partition pattern index decoded from the data block <NUM>) are per-block parameters independent of the texels being decoded. Thus the same seed and decoded partition count can be used in the calculation of the partition index for each of the texels <NUM>A-D, and so the seed computation unit <NUM> and the partition count unit <NUM> can be shared across the decoding pipelines for each of these texels being decoded.

The hardware resources of the parameter decode unit <NUM> can therefore be reduced compared to a multi-decoder formed from a plurality of conventional ASTC decoders operating in parallel.

An example structure of the colour decode unit <NUM> is shown in <FIG>. The colour decode unit comprises a colour data selector unit (CDSU) <NUM>, a sequence decoder unit <NUM>, a colour de-quantising unit <NUM> and a colour endpoint calculation unit <NUM>.

The CDSU <NUM> is configured to determine the size of the colour data within the data block <NUM>, i.e. the size of the data within the block used to represent the colour endpoints). In ASTC, the colour data is encoded within a data block as a variable length bit string. The colour data is encoded according to a bounded integer sequence encoding (BISE) scheme. The size of the colour data can be determined from the partition count (decoded by the partition count unit <NUM>) and the block mode data decoded by the block mode unit <NUM>. Thus, the CDSU <NUM> determines the size of the colour data using only a portion of the configuration data that is independent of the texels being decoded from the block <NUM>. The CDSU <NUM> may also decode the location of the colour data within the data block. This information may again be determined from the partition count and the block mode data.

As described above, the partition count and the block mode data are parameters specified per-block of data and are independent of the texels being decoded from the block <NUM>. Thus the colour decode unit <NUM> can use that portion of configuration data as part of the decoding for each of the texels <NUM>A-D. In particular, the CDSU <NUM> can perform a single determination of the colour data size within the block <NUM> and that determination can then be used as part of the decoding pipeline for each of the texels <NUM>A-D.

The sequence decoder unit <NUM> is configured to perform integer sequence decoding of the colour data. As mentioned above, the colour data is encoded within a data block according to a binary integer sequence encoding (BISE) scheme. The use of the BISE scheme enables colour values to be encoded in a fractional number of bits. A sequence of values can be represented using trits (base-<NUM> representation) or quints (base-<NUM> representation). Other base representations may also be used.

The colour de-quantising unit <NUM> is configured to extract the colour values from the decoded colour data and to de-quantise those colour values. De-quantising means restoring the encoded colour values to their original range (e.g. [<NUM>, <NUM>,. In certain cases, each of the texels <NUM>A-D being decoded in parallel by the decoder <NUM> could be in a different partition, in which case eight colour end points may be needed (two colour end points per partition). If each of these partitions were also associated with a colour endpoint mode in which each colour endpoint was formed from four colour values, this would require <NUM> colour values to be extracted and dequantised from the data block <NUM>. However, the ASTC specification limits the number of colour values that may be encoded within a <NUM>-bit data block to <NUM>.

In order for the multi-decoder to be able to best accommodate the above situation, the colour de-quantising unit <NUM> may be configured to (or have the appropriate hardware to be able to) extract and de-quantise <NUM> colour values from the data block <NUM> in parallel. It will be noted that because it is not possible to decode <NUM> colour values from the data block <NUM>, certain colour endpoint modes for partitioned data (e.g. data with a partition count of <NUM> or <NUM>) are not possible.

The endpoint calculation unit <NUM> is configured to convert the de-quantised colour values decoded by the de-quantising unit <NUM> into a set of colour endpoints. The endpoint calculation unit <NUM> may calculate the set of colour endpoints using the partition index and associated colour endpoint mode for each of the texels <NUM>A-D to be decoded. If more than four texels are to be decoded (for example, if <NUM> texels are to be decoded), then there will be a redundancy in partition indices and associated colour endpoint modes for those texels (because a block of data can only have a maximum of four partitions). Thus to reduce the amount of computations, the endpoint calculation unit may convert the colour values into the set of colour endpoints using the set of partition indices (and associated colour endpoint modes) spanned by the texels to be decoded. The de-quantising unit <NUM> may receive this information from the partition index unit <NUM> and the colour endpoint unit <NUM>.

The endpoint calculation unit may output a pair of colour endpoints for each texel being decoded from the block <NUM>. To do this, the endpoint calculation unit <NUM> may select an endpoint pair from the set of colour endpoints using the partition index for each texel being decoded. Alternatively, it may output the colour endpoints for each partition and a partition index for each texel.

Like the parameter decode unit <NUM>, the colour decode unit <NUM> is configured to decode data from the block <NUM> that is independent of the texels being decoded. That is, the colour decode unit <NUM> is configured to decode per-block data as part of decoding the colour endpoint data for the texels <NUM>A-D. The colour decode unit <NUM> uses that same data to decode the colour endpoint data for all of the texels <NUM>A-D being decoded. That is, the same per-block data decoded by the colour decode unit <NUM> is used in the decoding pipeline of each of the texels <NUM>A-D.

For instance, the size and location of the colour data within the data block <NUM> as decoded by the CDSU <NUM> is a parameter specified on a per-block level and is independent of which texels are being decoded from the data block. This data may be referred to as intermediate colour data, since it is data decoded from that block that is used to decode the colour endpoint data output from the colour decode unit. Because this intermediate data is independent of the texels being decoded, it is used by the remainder of the colour decode unit <NUM> when decoding the endpoint data for each of the texels <NUM>A-D being decoded from the block <NUM>. That is, the intermediate colour data is common to the decoding of each texel from the data block <NUM>. By only calculating this intermediate colour data once and re-using it as part of the decoding pipeline for each of the texels being decoded, the hardware requirements of the CDSU <NUM> can be made substantially the same as for a single-output ASTC decoder.

The colour values decoded by sequence decoder unit <NUM> and dequantized by the colour de-quantising unit <NUM> may be partially shared across the decoding pipelines of the texels <NUM>A-D. For example, ASTC limits the number of colour values that may be stored within the data block <NUM> to <NUM>. When decoding a single texel from the block <NUM>, up to eight colour values are needed (up to four colour values per colour endpoint, for two colour endpoints forming a single colour endpoint pair). Thus, when decoding a single texel, eight colour values may be BISE decoded and dequantized. When the decoder is decoding more than (<NUM>/<NUM>) texels in parallel (i.e., when the decoder decodes three or more texels in parallel), all <NUM> colour values may be BISE decoded and de-quantised. However, because the number of colour values being BISE decoded and dequantized is less than the multiple of the number of texels being decoded in parallel and the number of colour values needed per texel, the BISE decoded and dequantized colour values are partially shared across the decoding pipelines of the texels. In other words, in some cases the BISE decoded colour data is at least partially shared amongst the decoding pipelines of the texels being decoded in parallel from the data block. Similarly, the dequantized colour values are in some cases at least partially shared amongst the decoding pipelines of the texels being decoded. In other words, the BISE decoded and dequantized colour data may be common to at least some of the texels being decoded in parallel from the block <NUM>. The BISE decoded colour data and dequantized colour values may also therefore be examples of common intermediate data.

More generally, when the number of colour values decoded from the data block (denoted nv), is less than the number of partitions np multiplied by the number of colour values 2ncv in a colour endpoint pair (where np = the partition number and ncv = the number of colour values to form a single colour endpoint), then a subset of the decoded and dequantized colour values may be converted to colour endpoints shared by a plurality of the texels being decoded (even if those texels belong to different partitions).

<FIG> shows an example internal structure for the weight decode unit <NUM>. Here, the weight decode unit comprises a scaling unit <NUM>; a weight data selector unit (WDSU) <NUM>; a sequence decoder unit <NUM>, a weight de-quantisation unit <NUM> and a weight interpolation unit <NUM>. The scaling unit <NUM> is coupled to the WDSU <NUM>; the WDSU is coupled to the de-quantising unit <NUM> and the de-quantising unit is coupled to the weight interpolation unit <NUM>.

The scaling unit <NUM> is configured to identify weights of the weight grid to be used in an interpolation so as to generate a weight for each of the texels <NUM>A-D. The scaling unit <NUM> may identify a set of weights from the weight grid for each texel being decoded. Each set of weights can then be interpolated to generate a final weight for each texel.

As described above, depending on the size of the block footprint a weight may not be explicitly stored for each texel represented by the data block. For larger block footprints (e.g. <NUM> by <NUM> texels), the weight grid is of a sparser resolution than the block dimensions. In such cases, in order to derive a weight for each texel, the texel's coordinates are scaled to the dimensions of the weight grid and then a weight interpolation is performed for each texel in order to calculate a weight for those texels.

The scaling unit <NUM> comprises a scaling factor unit <NUM> and a weight selector unit <NUM>. The scaling factor unit <NUM> decodes the scaling factor that scales the size of the weight grid to the size of the block footprint from the data block <NUM>. The weight selector unit <NUM> uses the scaling factor to scale the coordinates of each of the texels <NUM>A-D being decoded to the weight grid and to select weights of the weight grid to be used in an interpolation for each of the texels <NUM>A-D to calculate a weight for those texels. The same scale factor as calculated by scale factor unit <NUM> is used by the weight selector unit <NUM> to scale the coordinates of each of the texels <NUM>A-D. Thus the scaling factor can be used to calculate the weights for each of the texels <NUM>A-D.

This process is illustrated schematically in <FIG>. A <NUM> by <NUM> block footprint of texels is shown by the 'cross' markings (denoted generally at <NUM>) and a <NUM> by <NUM> weight grid is shown by the 'dot' markings and denoted generally at <NUM>. The weight grid is therefore of a lower resolution than the dimensions of the block footprint. The block footprint and the weight grid are shown overlapped with each other for the purposes of illustration. A scaling factor is then applied to the coordinates of the texels to re-scale the block footprint to the dimensions of the weight grid. The result of applying this scale factor is shown generally at <NUM>. In this example the scaling factor has been applied to all the texels in the block footprint (rather than just the selected texels being decoded) for the purposes of illustration. The re-scaled texel coordinates are then used to select a set of weights of the weight grid to interpolate in order to calculate a weight for each texel. For example, the coordinates of texel A (circled for identification) are re-scaled from position <NUM> to position <NUM>. The set of weights <NUM>, <NUM>, <NUM> and <NUM> are then selected for interpolation to generate a final weight for texel A using the re-scaled position of that texel with respect to the weight grid.

The weight data selector unit <NUM> determines the size of the weight data within the block and the location of the data for the selected weights of the weight grid to be used in the interpolation for each of the texels <NUM>A-D being decoded.

The WDSU comprises a weight data size unit <NUM> and a weight locator unit <NUM>. The data size unit <NUM> is configured to determine the size of the weight data within the block <NUM>. The data size unit <NUM> determines this based on the weight value ranges and the size of the weight grid as decoded by the block mode unit <NUM>. The size of the weight data within the block <NUM> is used as part of the weight data decode for all the texels <NUM>A-D being decoded.

The weight locator unit <NUM> is configured to locate the weight data within the block <NUM> for each set of weights to be used in the weight interpolation for each of the texels <NUM>A-D. That is, the weight locator unit <NUM> may separately locate the weight data within the block to be used in the weight interpolation for each texel being decoded. It may locate this weight data for each texel in parallel.

Like the colour data, the weight data may also be BISE encoded. The sequence decoder unit <NUM> is configured to perform binary integer sequence decoding of the weight data.

The weight de-quantization unit <NUM> is configured to de-quantise the decoded set of weights for each of the texels <NUM>A-D (that is, return each of the weights to their original range from their encoded range). The set of weights for each of the texels being decoded are independent of each other, and thus the de-quantization unit may comprise hardware to de-quantise the weight sets for each of the texels being decoded in parallel. However, in some cases the weights can be shared between texels being decoded. That is, a subset of the texels being decoded may share at least one weight. For example, for a 12x12 footprint and a 2x2 weight grid, the weights are shared for all the texels being decoded.

The weight interpolation unit <NUM> is configured to interpolate the set of weights for each texel being decoded to calculate for each of those texels final interpolation weight data (e.g. a final interpolation weight per plane for each texel being decoded). The weight interpolation unit may calculate the final interpolation weight data for each texel being decoded from the block <NUM> in parallel.

The interpolation weight data for each of the texels <NUM>A-D being decoded is then output from the weight decode unit <NUM>.

Like the parameter decode unit <NUM> and the colour decode unit <NUM>, the weight decode unit <NUM> decodes data from the block <NUM> that is independent of the texels being decoded. Thus the weight decode unit decodes per-block data (i.e. data specified on a per-block basis) as part of decoding the interpolation weight data. This data may be referred to as intermediate weight data, since it is data decoded from the data block <NUM> and used to decode the final interpolation weight data output by the weight decode unit. The weight decode unit uses the same per-block (intermediate) data to decode the interpolation weight data for all of the texels <NUM>A-D. That is, the per-block data decoded by the weight decode unit is re-used in the decoding pipeline of each of the texels <NUM>A-D. This advantageously enables the components that decode this data to be shared amongst the decoding pipelines for each of the texels being decoded from the block.

For instance, the scaling factor that scales the dimensions of the block footprint to the weight grid as decoded by the scale factor unit <NUM> is a parameter specified per data block and is independent of the texels being decoded. Thus the same scale factor can be used by the weight selector unit <NUM> to scale the coordinates of each of the texels <NUM>A-D. Thus the scale factor unit may have substantially the same hardware requirements as if the decoder <NUM> were a single-output decoder.

Similarly, the size of the weight data within the block <NUM> is also a parameter that is independent of the texels being decoded. Thus the size of the weight data as decoded by the weight data size unit <NUM> is used by the weight locator unit <NUM> to locate the weight data for all of the texels <NUM>A-D being decoded. Thus the data size unit <NUM> may also have substantially the same hardware requirements as if the decoder <NUM> were a single-output decoder. Additional savings in hardware may be made if the requested texels are always (or often) adjacent, which means that for example for a 2x2 block, you would need a maximum of (p+<NUM>)(q+<NUM>) weights, instead of 4pq in general.

Referring back to <FIG>, the interpolator units <NUM> are configured to calculate a colour value for each of the texels <NUM>A-D being decoded using the interpolation weight data for that texel and a pair of colour endpoints from the colour endpoint data. The interpolator units may calculate a final colour for each texel being decoded from the interpolant weight data for that texel output from the weight decode unit <NUM> and the colour endpoint pair for that texel output from the colour decode unit <NUM>. The final colour values may be specified with respect to an RGBα colour space (i.e. each decoded colour may be in RGBα format).

The interpolator units <NUM> may calculate the colour for each texel by using the interpolant weight for that texel to interpolate between the associated colour endpoint pair.

The interpolator units <NUM> may be configured to calculate the final texel colours for each of the texels being decoded in parallel. The number of interpolator units <NUM> is equal to the partition number of the texture data being decoded.

<FIG> shows a flowchart of steps for decoding a plurality of texels from a block of texture data encoded according to an ASTC format.

At step <NUM>, configuration data for the block of texture data is decoded.

At step <NUM>, colour data for the plurality of texels of the block is decoded in dependence on configuration data.

At step <NUM>, interpolation weight data for each of the plurality of texels is decoded in dependence on the configuration data.

At step <NUM>, a colour value for each of the plurality of texels is calculated in dependence on the interpolation weight data for that texel and a pair of colour endpoints from the colour endpoint data; wherein at least one of the decoding of configuration data, decoding of colour endpoint data and decoding of interpolation weight data comprises decoding data from the block that is independent of the texels being decoded from that block and using that same data for the decoding of at least two of the plurality of texels.

The decoder <NUM> described above is a multi-output decoder that can decode multiple texels from a block of texture data compressed according to the ASTC specification. As in the examples above, the decoder can operate to decode the plurality of texels in parallel. However, advantageously, the decoder <NUM> can use certain portions of the data decoded from the texture data block as part of the decoding process for all of the texels being decoded from that block. Thus multiple texels can be decoded from the block in parallel without requiring parallel processing for each stage of the decoding process. This means the decoder <NUM> can have reduced hardware requirements (e.g. have a reduced area if implemented on an integrated circuit) compared to operating multiple conventional ASTC single-decoders in parallel. In particular, the inventors have found that by implementing the multiple output decoder in the manner described above to decode a <NUM> by <NUM> block of texels, the chip area can be reduced to approximately <NUM> times the chip area of a conventional single-output ASTC decoder, approximately equivalent to two thirds of the area of four single decoders. In other words, the multi-output decoder described herein can save approximately a third of the chip area compared to four single-output decoders operating in parallel.

Multiple components of the data decoded from the data block have been identified herein as being common to the decoding of at least some of the set of texels being decoded in parallel from the received data block. Some data decoded from the data block is independent of the set of texels being decoded from the received data block in parallel (and independent of the number of texels being decoded from the data block in parallel), and thus suitable for use in decoding all of the texels in that set. In the examples described above, the decoder was arranged so that each of these data components was used in the decoding process for all of the texels to be decoded from the block. Whilst this approach is likely to minimise the hardware requirements of the multi-decoder, it will be appreciated that the multi-decoder will realise gains in hardware efficiency so long as at least one portion, or component, of data decoded from the block that is common to the decoding of at least a subset of the set of texels being decoded in parallel from the received data block is used in the decoding process for those subset of texels. This is sufficient to avoid every stage of the decoding process from being executed multiple times in parallel for each texel being decoded. That component could be decoded by the parameter decode unit, weight decode unit, or colour decode unit.

In the examples above, the colour mode data was decoded by the parameter decode unit. However, it may alternatively be decoded by the colour decode unit.

In the examples above, the decoder <NUM> operated to decode a two by two block of texels from the data block in parallel. It will be appreciated that this was merely for the purposes of illustration and that the decoder <NUM> could be configured to decode any plurality of texels from the data block. For example, the decoder could decode a p by q sub-block of texels from the data block, where the dimensions of the sub-block in each direction are less than or equal to the corresponding dimension of the block footprint. Alternatively, the decoder <NUM> could decode a plurality of disparate texels from the block of data; that is, a plurality of texels where at least two of those texels are not contiguous. The decoder could operate to decode any nt texels from the received data block; i.e. the nt texels to be decoded from the block may be selected free of constraint.

The decoder <NUM> could be configured to decode multiple texels from a block of data representing dual-plane texture data, or single-plane texture data. The decoder can decode texture data from the block that has been encoded using either high dynamic range (HDR) or low dynamic range (LDR) (corresponding to the HDR profile and LDR profile respectively). Generally, the LDR profile supports two-dimensional textures, but it is also possible to support three-dimensional textures. The HDR profile also supports two-dimensional textures and additionally supports three-dimensional textures composed of multiple two-dimensional slices of compressed data.

The colour values may be formed from colour channels (e.g. luminance, R, G, B, alpha etc.), but in general may represent many different types of graphics data, e.g. height maps, normal maps, lighting etc..

The above examples describe how the decoder is operable to decode a maximum of nt texels from a single block <NUM>. Though the decoders described herein are capable of decoding multiple texels in parallel from a single received data block, it will be appreciated that in some instances, the decoder may only decode a single texel from the received data block. The number of texels that the decoder actually decodes from a block may depend on the texel request received by the decoder. If the decoder, in response to receiving texture block <NUM> and a texel request, determines that only a single texel is to be decoded from the block <NUM>, then it may turn down (e.g., power down, or turn off) a portion of its hardware to reduce power consumption. The size of the portion being turned down may be determined so that the remaining portion of the hardware (i.e. the portion that has not been turned down) can decode the texel without incurring a performance penalty (e.g. in the time taken to decode the requested texel).

The decoder <NUM> of <FIG> is shown as comprising a number of functional blocks. This is schematic only and is not intended to define a strict division between different logic elements of such entities. Each functional block may be provided in any suitable manner.

The decoders described herein may be embodied in hardware on an integrated circuit. The decoders described herein may be configured to perform any of the methods described herein. Generally, any of the functions, methods, techniques or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms "module," "functionality," "component", "element", "unit", "block" and "logic" may be used herein to generally represent software, firmware, hardware, or any combination thereof. In the case of a software implementation, the module, functionality, component, element, unit, block or logic represents program code that performs the specified tasks when executed on a processor. The algorithms and methods described herein could be performed by one or more processors executing code that causes the processor(s) to perform the algorithms/methods. Examples of a computer-readable storage medium include a random-access memory (RAM), read-only memory (ROM), an optical disc, flash memory, hard disk memory, and other memory devices that may use magnetic, optical, and other techniques to store instructions or other data and that can be accessed by a machine.

It is also intended to encompass software which defines a configuration of hardware as described herein, such as HDL (hardware description language) software, as is used for designing integrated circuits, or for configuring programmable chips, to carry out desired functions. That is, there may be provided a computer readable storage medium having encoded thereon computer readable program code in the form of an integrated circuit definition dataset that when processed (i.e. run) in an integrated circuit manufacturing system configures the system to manufacture a decoder configured to perform any of the methods described herein, or to manufacture a decoder comprising any apparatus described herein. An integrated circuit definition dataset may be, for example, an integrated circuit description.

Therefore, there may be provided an integrated circuit definition dataset that, when processed in an integrated circuit manufacturing system, causes the method of manufacturing a decoder to be performed.

An integrated circuit definition dataset may be in the form of computer code, for example as a netlist, code for configuring a programmable chip, as a hardware description language defining an integrated circuit at any level, including as register transfer level (RTL) code, as high-level circuit representations such as Verilog or VHDL, and as low-level circuit representations such as OASIS (RTM) and GDSII. Higher level representations which logically define an integrated circuit (such as RTL) may be processed at a computer system configured for generating a manufacturing definition of an integrated circuit in the context of a software environment comprising definitions of circuit elements and rules for combining those elements in order to generate the manufacturing definition of an integrated circuit so defined by the representation.

An example of processing an integrated circuit definition dataset at an integrated circuit manufacturing system so as to configure the system to manufacture a decoder will now be described with respect to <FIG>.

<FIG> shows an example of an integrated circuit (IC) manufacturing system <NUM> which is configured to manufacture a decoder as described in any of the examples herein. In particular, the IC manufacturing system <NUM> comprises a layout processing system <NUM> and an integrated circuit generation system <NUM>. The IC manufacturing system <NUM> is configured to receive an IC definition dataset (e.g. defining a decoder as described in any of the examples herein), process the IC definition dataset, and generate an IC according to the IC definition dataset (e.g. which embodies a decoder as described in any of the examples herein). The processing of the IC definition dataset configures the IC manufacturing system <NUM> to manufacture an integrated circuit embodying a decoder as described in any of the examples herein.

In other examples, processing of the integrated circuit definition dataset at an integrated circuit manufacturing system may configure the system to manufacture a decoder without the IC definition dataset being processed so as to determine a circuit layout. For instance, an integrated circuit definition dataset may define the configuration of a reconfigurable processor, such as an FPGA, and the processing of that dataset may configure an IC manufacturing system to generate a reconfigurable processor having that defined configuration (e.g. by loading configuration data to the FPGA).

Claim 1:
A decoder (<NUM>) configured to decode a plurality of texels from a received block of texture data (<NUM>) encoded according to the Adaptive Scalable Texture Compression (ASTC) format, wherein the texels represented by the block are partitioned into np partitions, the decoder comprising:
a parameter decode unit (<NUM>) configured to decode configuration data for the received block of texture data;
a colour decode unit (<NUM>) configured to decode colour endpoint data for the plurality of texels of the received block in dependence on the configuration data;
a weight decode unit (<NUM>) configured to decode interpolation weight data for each of the plurality of texels of the received block in dependence on the configuration data; and
np interpolator units (<NUM>), each interpolator unit being configured to calculate a colour value for each texel of the subset of texels of the plurality of texels in a respective partition using the interpolation weight data for that texel and a respective pair of colour endpoints from the colour endpoint data, wherein the np interpolator units are configured to operate in parallel;
wherein the weight decode unit (<NUM>) is configured to decode, as part of decoding the interpolation weight data, intermediate weight data, only once, from the received block that is common to the decoding of at least two of the plurality of texels and independent of which of the texels are decoded from the received block; and wherein the weight decode unit (<NUM>) is configured to use the intermediate weight data to decode the interpolation weight data for the at least two of the plurality of texels in parallel.