JP2011070672A - Graphics processing systems - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide frame buffer generation in a graphic processing system and improvement with respect to similar operations. <P>SOLUTION: A transaction elimination hardware unit 5 controls the writing of tiles generated by a tile-based graphics processor to a frame buffer in a memory 2. The transaction elimination hardware unit 5 has a signature generating unit 20 that generates a signature representing the contents of a tile in each tile. A signature comparator 23 compares the signature of a new tile received from the graphics processor, with the signatures of tiles already stored in the frame buffer. If the signatures do not match, the signature comparator 23 controls a write controller 24 to write the new tile in the frame buffer. When the signatures do not match, data are not written to the frame buffer, and the existing tile remains inside the frame buffer. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to graphics processing systems, and more particularly to frame buffer generation and similar operations in graphics processing systems.

  As is known in the art, the output of a graphics processing system to be displayed is typically written to a so-called “frame buffer” in memory when ready to display. The frame buffer is then read by the display controller and output to a display (eg, screen or printer) for display.

  When writing graphics data to the frame buffer, a relatively significant amount of power and memory bandwidth is consumed, especially if the frame buffer resides in memory that is external to the graphics processor. Is so. For example, new frames need to be written to the frame buffer at a frame rate of 30 frames per second, and each frame contains a significant amount of data, especially for high-resolution displays and high-definition (HD) graphics. You may need it.

  Thus, it is known that it is desirable to attempt to reduce the power consumption of frame buffer operations, and various techniques have been proposed to attempt to achieve such a reduction.

  These techniques include on-chip (as opposed to external) frame buffer formation, frame buffer caching (buffering), frame buffer compression and dynamic color depth control. However, each of these techniques has its own drawbacks and disadvantages.

  For example, using an on-chip frame buffer may require a large amount of on-chip resources, especially for high resolution displays. Frame buffer caching or buffering is not practical because frame generation is typically asynchronous to the frame buffer display. Although frame buffer compression can be useful, the required logic is relatively complex and the frame buffer format is changed. Using lossy frame buffer compression degrades image quality. Similarly, the dynamic color depth control is an irreversible method, and therefore the image quality is degraded.

  Accordingly, applicants are convinced that there is still room for improvement to frame buffer generation and similar operations in graphics processing systems.

According to a first aspect of the present invention, there is provided a method of operating a graphics processing system in which data generated by the graphics processing system is used to form an output array of data in an output buffer. The method is
A graphics processing system storing the data output array in the output buffer by writing a block of data representing a particular region of the data output array to the output buffer;
When a block of data is being generated against the output data array, the graphics processing system compares that block of data with at least one other block of data, and the generated block of data based on this comparison Determining whether to write to the output buffer.

According to a second aspect of the present invention, a graphics processing system is realized, the system comprising:
A graphics processor comprising means for generating data for forming an output array of data to be supplied by the graphics processor;
Means for storing the data generated by the graphics processor in the output buffer as an array of data by writing to the output buffer a block of data representing a particular region of the array of data;
Graphics processing system
Means for comparing the generated block of data against the output data array with at least one other block of data and deciding whether to write the generated block of data to the output buffer based on the comparison Further prepare.

According to a third aspect of the invention, a graphics processor is realized, the processor comprising:
Means for writing a block of data to an output buffer that represents a particular region of the output array of data that is generated by the graphics processor and to be supplied by the graphics processor;
Means for comparing the block of data generated for the output data array with at least one other block of data and determining whether to write the block of data to the output buffer based on the comparison.

  The present invention may be a block of data that represents a particular region of the output array of data (which may be, for example, a rendered tile generated by a graphics processor, and in a preferred embodiment, graphics The output array of data (which can be, for example, a frame to be displayed, is also displayed, in one preferred embodiment, by writing processor-generated tiles) to an output buffer. Is a graphics processing system that is stored in an output buffer (which can be, for example, a frame buffer, and in a preferred embodiment is a frame buffer); Also implemented in such a graphics processing system It is.

  Thus, in essence, the present invention provides a graphics processing system in which the entire “final” output of a graphics processing system is stored in memory on a block-by-block basis rather than directly on a single output “frame”. And is intended to be implemented in such a graphics processing system.

  For example, and as will be appreciated by those skilled in the art, this applies to tile-based graphics processing systems, where each block of data considered and compared in the manner of the present invention is a graphics processor. (And in a preferred embodiment, it corresponds) (although this is not essential, as will be described further below).

  (As is known in the art, tile-based rendering is a two-dimensional output array or frame ("render target") of the rendering process (e.g., typically also displaying the scene being rendered). Are to be subdivided or partitioned into a plurality of smaller areas, usually referred to as “tiles”, for the rendering process. Rendered separately (typically from one to the next), then the rendered tiles (partial regions) are recombined, for example to display a complete output array (frame) (render target) Form.

  Another term commonly used for "tiling" and "tile based" rendering is "chunking" (partial regions are referred to as "chunks") And "bucket" rendering. The terms “tile” and “tiling” are used herein for convenience, but these terms are intended to encompass all alternative and equivalent terms and techniques. Will be understood.

  In the present invention, each output data block (e.g., a rendered tile) is not simply written to the frame buffer as soon as it is ready, but instead the output data block is one or more other data blocks ( (E.g. one or more tiles) (at least one data block) is first compared and then based on that comparison it is determined whether (new) data blocks are written to the output (e.g. frame) buffer Is done.

  As described in more detail below, Applicants use this process to significantly reduce the number of data blocks (e.g., rendered tiles) that are written to the output (e.g., frame) buffer during use. Has found and understood that the number of output (eg, frame) buffer transactions can be significantly reduced, and thus the power and memory bandwidth consumption associated with output (eg, frame) buffer operations can be significantly reduced.

  For example, if a newly created data block already exists in the output buffer or is found to be the same as a data block that will already exist (e.g. a rendered tile), the newly created data block It can be determined (and preferably determined) that the data block need not be written to the output buffer, thereby eliminating the need for an output buffer “transaction”.

  In addition, applicants can use new data blocks (e.g., in some areas of the image that do not change from frame to frame (e.g., sky, play field when the camera position is stationary, most of the user interface for many applications, etc.) Compared is the same or similar to the data block (e.g. rendered tile) that already exists in the output (e.g. frame) buffer or will already exist Recognize that this is possible. Therefore, by identifying such areas (e.g. tiles) and then making it easier to avoid rewriting such areas (e.g. tiles) into the output (e.g. frame) buffer if desired , Significant savings in write traffic (write transactions) to the output (eg, frame) buffer can be achieved.

  For example, Applicants have discovered that for some common games, up to 20% (or even more) of the rendered tiles in each frame may not have changed. HD1080p graphics at 30 frames per second (fps) and estimated power and memory bandwidth savings if 20% of the tiles in a frame are not rewritten to the frame buffer (by using the present invention) Can be about 30mW and 50MB / s. Greater power and bandwidth savings can be achieved if more rendered tiles do not change from frame to frame. For example, if 90% of the rendered tiles are not rewritten (not changed), this savings may be on the order of 135 mW and 220 MB / s.

  Thus, the power consumption and memory bandwidth used for frame and other output buffer operations can be significantly reduced by using the present invention, making it virtually easier to identify and eliminate unwanted output (e.g. frame) buffer transactions. Can be reduced.

  Furthermore, compared to the above-described prior art scheme, the present invention requires relatively little on-chip hardware, can be an irreversible process, and does not change the frame buffer format. In addition, it can be easily used in cooperation with and complementing an existing frame buffer power reduction method, thereby making it easier to save power if desired.

  The output array of data formed using the data generated by the graphics processing system is a suitable, desirable array of such data, ie an array of data that can be generated using a graphics processor. It can be. In one particularly preferred embodiment, this includes an output frame for display, which is a texture that a graphics texture (e.g., a render `` target '' generates using a graphics processor (e.g., In a “render to texture” operation)) or other outputs of the graphics processor, such as other surfaces to which the graphics processor system output is written, can be included or alternatively included.

  Similarly, the output buffer to which data is written can include any suitable such buffer, and can be configured in memory in any suitable and desirable manner. For example, this may be an on-chip buffer, but may also be an external buffer (and may actually be an external buffer (memory), as will be explained below). Similarly, it can be dedicated memory for this purpose, or it can be part of memory that is also used for other data. In a preferred embodiment, the output buffer is a frame buffer for the graphics processing system and / or for the display to which the graphics processing system output is supplied.

  One or more other data blocks with which the generated data blocks are compared can be selected as needed. In one particularly preferred embodiment, these are data blocks already stored in the output buffer.

  Thus, in one particularly preferred embodiment, a data block comparison is already stored in the output buffer for the block of data that has been generated for the output data array (e.g., preferably ready to write the output buffer). A step (or means) of comparing to at least one other block of data being stored (and then determining whether to write a new block of data to the output buffer based on the comparison).

  In this case, the block (s) of data already stored in the output buffer may be blocks of data already stored for the current output data array, but in a particularly preferred embodiment, One or more blocks of data from a data array (ie, a data array already stored in the output buffer), or such a block. Thus, in a preferred embodiment, the generated data block is compared with one or more blocks from the previous output data array. In a preferred embodiment, the generated data block is only compared with one or more blocks from the previous output data array.

  Thus, in one particularly preferred embodiment, this comparison includes data blocks from previous data arrays already stored in the output (eg, frame) buffer. This in turn allows a similar data block not to be written again to the output buffer for the current (new) data array if it already exists in the output buffer from the previous data array. This may be particularly useful when a series of similar data sequences (such as frames of a video sequence) are being generated.

  In another preferred embodiment, the data block comparison process is performed (by comparing blocks) on blocks that are being generated only for the same data array (current data array).

  In this case, for example, a comparison can be made with the data block for the current array already stored in the output buffer and / or generated for the current output array but not yet stored in the output buffer. Comparisons with other non-blocks can be made (in one preferred embodiment, such comparisons are made).

  In this case, when each data block to be written to the data array is generated, it is compared with another data block or blocks of the data array, and then a new data block is included in the comparison. Can be written based on or not written. Thus, in a particularly preferred embodiment, when a data block for a data array is completed, the data block is compared with at least one other data block for the data array, and the completed data block is converted into a data array based on the comparison. There is a step or means for determining whether to write.

  In a particularly preferred embodiment, a data block comparison is performed with both the data block for the current (current) data array and the data block of the previous data array already stored in the output buffer.

  Thus, in a preferred embodiment, a comparison is made with a data block to be stored in the output buffer or already stored.

  There is a comparison of the current output data array with other data blocks, so that the data block generated for that array is not already in the output buffer for the data block position of interest. If the data block itself cannot be written to the output buffer, the data block itself cannot be written to the output buffer, but preferably there is metadata for the block location of interest indicating that other blocks of the data array must be processed. A block position of interest is generated and stored. The device that is to use or process the data array can then identify which other data block of the data array to process for the block of interest.

  Each block of data considered and compared can represent any suitable, desired area of the entire output array of data to be stored in the output buffer. As long as the entire output array of data is divided or partitioned into a plurality of identifiable smaller regions, each representing a portion of the entire output array, and accordingly the data that can be identified and compared in the manner of the present invention As long as it can be represented as a block, subdivision of the output array into blocks of data can be performed as needed.

  Each generated block of data preferably represents a different part (partial region) of the entire output array (these blocks can also overlap if desired). Each block will represent an appropriate portion (area) of the output array, such as multiple data positions within the array. The preferred data block size is 8 × 8, 16 × 16, or 32 × 32 data positions in the output data array.

  In a particularly preferred embodiment, the output array of data is divided into regularly sized and shaped areas (blocks of data), preferably square or rectangular shaped areas. However, this is not essential and other arrangements can be used if desired.

  In a particularly preferred embodiment, each data block corresponds to a rendered tile that the graphics processor generates as its rendering output. This is a particularly straightforward way of implementing the present invention, in which the graphics processor directly generates rendering tiles and thus “generates” data blocks that are considered and compared in the manner of the present invention. No further processing is required. Thus, in this case, each rendered tile generated by the graphics processor is compared to one or more other rendered tiles as it is written to the output (e.g. frame) buffer, and then the comparison Newly rendered tiles are or are not written to the output buffer.

Thus, according to a fourth aspect of the present invention, a method for operating a tile-based graphics processing system, wherein a rendered tile generated by a graphics processing system is generated and written to an output buffer A method is provided, which is
When a tile for output to the output buffer is complete, the graphics processing system compares that tile to at least one other tile that is already stored or should be stored in the output buffer, and based on this comparison Determining whether to write the completed tile to the output buffer.

According to a fifth aspect of the present invention, a graphics processing system is realized, the system comprising:
A tile-based graphics processor comprising means for generating output tiles of output to be supplied by the graphics processor;
Means for writing output tiles generated by the graphics processor to an output buffer after the output tiles are completed;
Graphics processing system
Means for comparing the completed output tile with at least one tile already stored in the output buffer or to be stored and determining whether to write the completed tile to the output buffer based on the comparison .

According to a sixth aspect of the invention, a tile-based graphics processor is realized, the graphics processor comprising:
Means for generating output tiles of output to be supplied by the graphics processor;
Means for writing output tiles generated by the graphics processor to an output buffer after the output tiles are completed;
To compare the output tile completed by the graphics processor to at least one tile already stored in the output buffer or to be stored, and to determine whether to write the completed tile to the output buffer based on the comparison Means.

  As will be appreciated by those skilled in the art, these aspects and embodiments of the present invention may include, where appropriate, one or more or all of the preferred and optional features of the present invention described herein. And preferably comprises. Thus, for example, the output buffer in a preferred embodiment is a frame buffer.

  In these aspects and arrangements of the present invention, the render target (output data array) can be divided into several (rendering) tiles of any size and shape desired and suitable for rendering. . The rendered tiles are preferably all the same size and shape as is known in the art, although this is not essential. In a preferred embodiment, each rendered tile is rectangular and preferably takes a sampling position of 8 × 8, 16 × 16, or 32 × 32 with respect to size.

  In one particularly preferred embodiment, the invention may be performed in addition to or instead of using data blocks of different sizes and / or shapes than the tiles that the rendering process manipulates (generates). Preferably, in addition to or in lieu of the foregoing.

  For example, in a preferred embodiment, one or each data block considered and compared in the present invention is comprised of a set of multiple “rendered” tiles and / or a small portion of a rendered tile. May only be included. In these cases, there may actually be an intermediate stage that “generates” the desired data block from one or more rendered tiles generated by the graphics processor.

  In a preferred embodiment, the same block (region) configuration (size and shape) is used throughout the output array of data. However, in other preferred embodiments, different block configurations (eg, with respect to their size and / or shape) are used for different regions of a given output data array. Thus, in a preferred embodiment, different data block sizes can be used for different regions of the same output data array.

  In a particularly preferred embodiment, the block configuration (e.g. with respect to the size and / or shape of the block under consideration) is in use on the output data array (e.g. output frame), e.g. based on the output data array. Can be changed. Most preferably, the block configuration can be adapted during use, for example and preferably, depending on the number or percentage of output buffer transactions that are eliminated (avoided). For example, and preferably, a block of data need not be written to the output buffer if it is known that using a specific block size only has a low probability that the block does not need to be written to the output buffer. In order to try to increase the probability of doing so, it is possible to change (eg, also preferably reduce) the considered block size for subsequent output arrays of data.

  If the data block size is changed in use, the change can be performed as desired, for example, over the entire output data array, or only over a specific portion of the output data array.

  Comparison of the newly generated output data block (eg, rendered tile) with other data blocks can be performed as desired and in any suitable manner. The comparison is preferably such that it can be determined whether the new data block is the same (or at least sufficiently similar) to the other data blocks. Thus, for example, some or all of the contents of a new data block can be compared to some or all of the contents of other data blocks (in a preferred embodiment, this is done).

  In one particularly preferred embodiment, this comparison represents the contents of the new output data block and / or information derived from the contents of the new output data block, represents the contents of other data blocks, and / or other Compared with information derived from the contents of the data block, for example and preferably, it is performed by evaluating the similarity of the data block or something different.

  Information representing the contents of each data block (e.g., rendered tiles) may be of any suitable form, but is preferably based on or derived from the contents on the data block. The Most preferably, it is generated from the content of the data block or takes the form of a “signature” for the data block based on the content of the data block. Such a “signature” of the content of the data block represents, for example and preferably, the content of the data block, such as a checksum, CRC or hash value derived from the data block (generated for the data block) Any suitable set of derivation information that can be considered can be included. Suitable signatures include standard CRCs such as CRC32 or other forms of signatures such as MD5, SHA-1.

  Thus, in a particularly preferred embodiment, a signature indicating or representing the content of the data block and / or derived from the content of the data block is generated for each data block to be compared, the comparison process comprising: Comparing the signatures of each data block.

  Thus, in one particularly preferred embodiment, when the system is operating in the manner of the present invention, a signature, such as a CRC value, is generated for each data block (eg, and preferably generated) for the output data array. Generated for each output rendered tile). Any suitable “signature” generation process, such as a CRC function or a hash function, can be used to generate a signature for a data block. Preferably, the data block (eg, tile) data is processed in a selected, preferably specific or predetermined, order when generating the data block signature. This can further help reduce power consumption. In a preferred embodiment, the data is processed using a Hilbert sequence (Hilbert curve).

  Where necessary, signatures for data blocks (eg, rendered tiles) stored in the output (eg, frame) buffer should be stored accordingly. Preferably, it is stored by an output (eg, frame) buffer. The stored signature for the data block can then be retrieved as appropriate when it becomes necessary to compare the signatures.

  Preferably, a signature for one or more data blocks, and preferably for a plurality of data blocks, for example in a local comparison stage or means of the graphics processor itself, e.g. an on-chip signature (e.g. CRC) buffer Can be cached in and cached. This method can eliminate the need to fetch the signature of the data block from the external buffer each time a comparison is made, thus helping to reduce the memory bandwidth used to read the signature of the data block.

  If a representation of the data block content, such as a data block signature, is cached locally, eg, stored in an on-chip buffer, the data blocks are preferably processed in a suitable order, such as Hilbert order, thereby , Signatures etc. are likely to match locally cached data blocks (stored in an on-chip buffer).

  As will be appreciated by those skilled in the art, although the generation and storage of signatures for data blocks (eg, rendered tiles) requires some processing and memory resources, Applicants have more to do with this invention. We are confident that the potential savings in terms of power consumption and memory bandwidth that can be achieved are better.

  For example, it is possible to generate a single signature for one, e.g. RGBA, data block (e.g. rendered tile) or generate a separate signature (e.g. CRC) for each color plane It is possible. Similarly, color conversion can be performed and different signatures can be generated for the Y, U, and V planes as needed.

  As those skilled in the art will appreciate, the longer the signature generated for a data block (the more accurately the signature represents the data block), the more false “matches” between the signatures (and thus, for example, new The possibility that an error that a data block is not written to the output buffer) will be reduced. So, in general, depending on the accuracy required (and as a trade-off for the memory and processing resources required for signature generation and processing, for example), it is possible to use longer or shorter signatures (e.g. CRC). is there.

  In one particularly preferred embodiment, the signature is directed toward a particular aspect of the data block content compared to other aspects of the data block content (e.g., and preferably, data for the data block (the content of the data block is Weighted) for a particular aspect or part of the data represented). Thereby, for example, a signature having a predetermined overall length can improve the overall result by weighting the signature on the portion of the data block content (data) that is more effective for the entire output (e.g., As perceived by the viewer.)

  In one such preferred embodiment, a longer (more accurate) signature is generated for the MSB bits of the color compared to the LSB bits of the color. (In general, the LSB bits of a color are less important than the MSB bits, so applicants are not likely to have errors in comparing LSB bits for different output data blocks (e.g., rendered tiles). (In my opinion, the impact on the overall output is not so bad, and we recognize that using a relatively inaccurate signature for the LSB bits is acceptable.)

  For example, different length signatures for different applications, etc. may be used depending on the requirements of the application, eg, display. This can further help reduce power consumption. Thus, in a preferred embodiment, the signature length used can be changed during use. Preferably, the signature length can be changed according to the application in use (adapted tuning can be made according to the application being used).

  In one particularly preferred embodiment, a completed data block (e.g., rendered tile) is compared with other data blocks for the output array (e.g., and preferably also already stored in the output buffer) as a result of the comparison. Is not written to the output buffer if it is determined that it should be considered the same. Thus, a data block that is already stored in the output buffer or determined to be the same as the data block that is to be stored need not be written to the output buffer.

  Thus, in a particularly preferred embodiment, in the present invention, a signature representing the contents of a data block (eg, a rendered tile) is or is to be stored in an output (eg, frame) buffer. Compare (e.g. tiles) signatures and if the signatures are the same, do not write (new) data blocks (e.g. tiles) to the output buffer (but if the signatures are different, (new) data blocks ( For example, write tiles to the output buffer).

  Incorrectly matching blocks if the comparison process requires an exact match between the data blocks being compared (e.g., between their signatures) to be compared for blocks that are considered to match so that no new blocks are written to the output buffer Ignoring the effect of, the present invention will actually constitute a reversible process. If the comparison process only requires a sufficiently similar match (but not an exact match), this process can be used in that the data block can be replaced with a data block that is not its exact match. , “Irreversible”.

  A current, completed data block (e.g., a rendered tile) (e.g., and preferably its signature) is already stored in one or more other data blocks (e.g., in an output buffer). Data block).

  Preferably, at least one of the data blocks (e.g. tiles) against which (new) data blocks are compared (or only the data block against which (new) data blocks are compared) is It includes a data block stored in an output buffer that occupies the same location (same data block (eg, tile) location) as the completed destination of the new data block. Thus, in a preferred embodiment, the newly generated data block is compared to an equivalent data block (or blocks if appropriate) already stored in the output buffer.

  In a preferred embodiment, the current (new) data block is compared with only a single other data block.

  In another preferred embodiment, the current, completed data block (e.g. its signature) is compared with a plurality of other data blocks (e.g., signatures already stored in the output buffer). The This can help to further reduce the number of data blocks that need to be written to the output buffer, as data block writes that are the same as data blocks at other locations in the output data array can be eliminated.

  In this case, if the data block matches a data block at a different position in the data array, the system preferably outputs information indicating which other data block should be used for the data block position of interest. And store. For example, a list indicating whether the data block is the same as other data blocks in the output data array having different data block positions (coordinates) may be maintained. Then, for example, when reading a data block for display purposes, the corresponding list entry is read and if it is "null", for example, a "normal" data block is read, If the address of a different data block is included, the different data block is read. This is also preferably performed as described above when the data block is compared to other data blocks generated for the current output array (i.e. not necessarily already stored in the output buffer). This then allows the device that reads the output array in that case to know which data block to process instead of the data block that was not written to the output buffer for the data array.

  When a data block is compared to multiple other data blocks (e.g., already stored in an output buffer), each data block is replaced with all other (e.g., existing) data blocks (e.g., existing) for the output array. (E.g., all other blocks in the output buffer), but preferably each data block is, for example, also preferred, with some but not all of the other data blocks for the output array. Are compared only to data blocks in the same area of the output data array as the new data blocks (e.g., in the output buffer) (e.g., these data blocks cover and surround the intended location of the new data block) ). This increases the likelihood of detecting a data block match without checking all the data blocks in the output array.

  In a preferred embodiment, every data block generated for the output data array is compared to one or more other data blocks. However, this is not essential and, therefore, in other preferred embodiments, the comparison is performed on some but not all of the data blocks of a given output data array (eg, output frame).

  In a particularly preferred embodiment, the number of data blocks to be compared with one or more other data blocks for each output data array is, for example, and preferably for each output array (e.g., for each frame), or Changes are made based on multiple sequences of output arrays (eg, frames). This is preferably based on (or not based on) the expected correlation between successive output data arrays (eg, frames).

  Thus, the present invention preferably provides a means for selecting the number of data blocks to be written to the output buffer or its to be compared with one or more other data blocks for a given output data array. Selecting the number of such data blocks.

  Preferably, if there is little (and expected) correlation between different output data sequences, fewer data blocks are compared (e.g., signatures are generated on relatively few data blocks in that case) ), If there are many correlations between different output data arrays (expected to have many correlations), the data blocks in the output data array that are being compared (and the signature is (And preferably all are) (thus many newly generated data blocks would be expected to be duplicated in the output buffer). This helps reduce the amount of comparison (significant power and resources) and signature generation performed when it is expected that a small number of data block write transactions will be eliminated (output data alignment On the other hand, it still makes it easier to use the comparison process of the invention when it is expected to be particularly advantageous (i.e. when there is a lot of correlation between the output data sequences) .

  In these arrangements, the amount of (expected) correlation between different (eg, consecutive) output data sequences is preferably estimated for this purpose. This can be done as desired, but is preferably based on the correlation between the earlier output data arrays. Most preferably, the number of matching data blocks in the previous pair or sequence of output data arrays (e.g., also preferably as determined by comparing data blocks in the manner of the present invention), most preferably The number of matching data blocks in the pair immediately preceding the output data array (eg, output frame) is used as a measure of expected correlation for the current output data array. Thus, in a particularly preferred embodiment, the number of data blocks known to match in the previous output data array is used to determine how many data blocks in the current output data array are in the manner of the present invention. Select whether to compare.

  In a particularly preferred embodiment, the number of data blocks compared in the manner of the present invention can and preferably is changed as is the case between different regions of the output data array. In one such arrangement, this is based on the arrangement of previous data block matches in the output array, i.e., this gives an estimate of the area of the output array that is expected to be highly correlated (and vice versa). The number of data blocks in different regions of the output array to be processed in the manner of the present invention is then controlled and selected accordingly. For example, and preferably, the previous arrangement of data block matches is used to determine if the region of the output array is likely to remain the same, and which region is, then The number of data blocks processed in a manner can be increased in those areas.

  In a preferred embodiment, a software application (e.g., using and / or receiving an output array generated by a graphics processing system) indicates which regions of the output data array are processed in the manner of the present invention. , In particular, and preferably, can indicate for which region of the output sequence the data block signature calculation process is to be performed. This in turn allows the signature calculation to be “turned off” by the application for the region of the output array that “knows” that the application will always be updated.

  This can be achieved as desired. In a preferred embodiment, a register is provided that enables / disables data block (e.g., rendered tile) signature computation for the output array region, where a software application sets the register accordingly (e.g., a graphics processor). Through the driver). The number of such registers should be selected as a trade-off between, for example, the additional logic required for the registers, the desired granularity of control, and the potential savings gained by being able to override signature calculations. Can do.

  In a particularly preferred embodiment, the system always writes newly generated data blocks to the output buffer periodically, e.g. once per second, for each given data block (data block position). Configured. Thus, new data blocks are reliably written into the output buffer at least periodically for every data block position, so that, for example, erroneously matching data blocks (e.g. Are kept in the output buffer for a predetermined, eg, desired or selected period, because the data block signatures happen to match even though they are different.

  This can be done, for example, by simply writing out a new output data array periodically (eg, once per second). However, in a particularly preferred embodiment, new data blocks are written to the output buffer individually on a rolling basis, so that the new output array is not written all at once, but instead of the data blocks in the output array being selected. Each time a new output array is generated, it is written to the output buffer in a circular pattern, and over time, all data blocks are eventually written out as new. In a preferred such arrangement, the system writes a (different) selected 1 / n portion (e.g., 1/25 portion) of a data block completely per output array (e.g., frame). , N (eg, 25) by the end of the sequence of output arrays (eg, frames), all data blocks are configured to be completely written to the output buffer at least once.

  This operation is preferably accomplished by disabling the data block comparison for the associated data block (ie, the data block that is completely written to the output buffer). (Data block signatures are preferably still generated for data blocks that are all written to the output buffer, since these blocks can be compared with subsequent data blocks).

  The present invention provides a double buffered output (e.g., frame) buffer, i.e., two output arrays (e.g., frames), e.g., an output array being displayed, and thus the next output array to be displayed. When used with an output buffer that simultaneously stores an output array written as (e.g., a frame), the comparison process of the present invention preferably compares the newly generated data block with the oldest output array in the output buffer. (That is, compare the newly generated data block with the output array that is not currently displayed but is written as the next output array to be displayed).

  In one particularly preferred embodiment, the present invention provides one or more power and bandwidth reduction schemes for other frame (or other output) buffers, e.g., and preferably compression (e.g., frame) buffer ( Can be irreversible or reversible as desired).

  In a preferred arrangement in the latter case, after the comparison process, when a newly generated data block is written to an output (e.g. frame) buffer, the data block is compressed accordingly and then output (e.g. , Frame) buffer.

  If the data block is further subjected to some processing such as compression before it is written to the output buffer, for example, additional processing such as compression is performed on the data block anyway, and then the data block so processed based on the comparison May or may not be written to the output buffer. However, in a particularly preferred embodiment, the comparison process of the present invention is performed first, and further processing, such as compression, of the data block is performed only if it is determined to write the data block to the output buffer. This in turn can avoid further processing of the data block if it is determined that the block does not need to be written to the output buffer.

  The tile comparison process (and signature generation, if used) can be implemented in an integral part of the graphics processor or, for example, between the graphics processor and the output (eg, frame) buffer There can be separate “hardware elements”.

  In a particularly preferred embodiment, there is a “transaction exclusion” hardware element that performs the comparison process and controls the writing (or not writing) of data blocks to the output buffer. This hardware element preferably also generates a signature (caches the signature of the stored data block) when it is complete. Similarly, if the data block operating in the present invention is not the same as, for example, the rendered tile that the rendering process generates, this hardware element preferably generates a data block from the rendered tile that the rendering process generates or assemble.

  In one preferred embodiment, this hardware element is separate from the graphics processor, and in another preferred embodiment, is incorporated into (part of) the graphics processor. Thus, in a preferred embodiment, the comparison means etc. are part of the graphics processor itself, but in other preferred embodiments the graphics processing system comprises a graphics processor, another means comprising comparison means etc. It comprises a “transaction exclusion” unit or element.

  The present invention can be used regardless of the form of output that the graphics processor may be providing to the output buffer. Thus, this can be used, for example, when the data block and output data array are intended to form an image for display (e.g., on a screen or printer) (and in a preferred embodiment, This is the case). However, the present invention is useful when the output is not intended for display, for example, when the output data array (render target) is a texture generated using a graphics processor (e.g., in a "render to texture" operation). ), Or in fact, the output generated using the graphics processor may also be used in other forms of data arrays.

  Similarly, although the present invention has been described above with particular reference to graphics processor operation, applicants have found that the principles of the present invention are in the form of blocks in a manner similar to, for example, a tile-based graphics processing system. It is recognized that it can be applied to other systems that process the same data as well. Thus, the present invention can be applied, for example, to video processing (since video processing is performed on blocks of data similar to tiles in graphics processing) and composite image processing (again, the composite frame buffer is a different block of data. Can be used equally well)

  The present invention can also be used, for example, when a digital camera is processing data (images) generated by a camera sensor. A camera (video or still image), for example, can process the image generated by its sensor for each block for storage in memory. In this case, the data from the camera sensor can be processed as described above, for example, by the camera controller that controls the writing of the image data to the memory.

Thus, according to a seventh aspect of the present invention, there is provided a method of operating a data processing system in which data generated by the data processing system is used to form an output array of data in an output buffer, which The method is
A data processing system storing the data output array in the output buffer by writing a block of data representing a particular region of the data output array to the output buffer;
When a block of data is being generated against the output data array, the data processing system compares that block of data with at least one other block of data, and based on this comparison the generated block of data is Determining whether to write to the output buffer.

According to an eighth aspect of the present invention, a data processing system is realized, the system comprising:
A data processor comprising means for generating data for forming an output array of data to be supplied by the data processor;
Means for storing data generated by the data processor in the output buffer as an array of data by writing to the output buffer a block of data representing a particular region of the array of data;
The data processing system
Means for comparing the generated block of data against the output data array with at least one other block of data and deciding whether to write the generated block of data to the output buffer based on the comparison Further prepare.

According to a ninth aspect of the present invention, a data processor is realized, the processor comprising:
Means for writing a block of data to an output buffer that represents a particular region of the output array of data that is generated by and supplied by the data processor;
Means for comparing the generated block of data against the output data array with at least one other block of data and deciding whether to write the generated block of data to the output buffer based on the comparison Further prepare.

  The present invention also extends to the provision of specific hardware elements for performing the comparison of the present invention and determination of the results. As described above, for example, this hardware element (logic) is configured as one integral part of, for example, a graphics processor or, for example, an interface between a graphics processor and an external memory controller, for example. Can be a stand-alone element that can be. This may be a programmable or dedicated hardware element.

Thus, according to the tenth aspect of the present invention, the output array of data generated by the data processing system is stored in the output buffer by writing a block of data representing a specific area of the output array of data to the output buffer. A write transaction eliminator is provided for use in a data processing system to be
Means for comparing the generated block of data against the output data array with at least one other block of data and determining whether to write the generated block of data to the output buffer based on the comparison; Prepare.

  As those skilled in the art will appreciate, all of these aspects and embodiments of the invention may include one or more or all of the preferred and optional features of the invention described herein. Yes, preferably. Thus, for example, the comparison preferably includes comparing signatures representing the contents of each data block. Similarly, the data block comparison step or means preferably includes at least a block of data already stored in the output buffer (and / or to be written to the output buffer) that is ready to be written to the output buffer. Comparing to one block, the method comprises means or means for determining whether to write a block of data to the output buffer based on the comparison.

  In these arrangements, the data blocks are, for example, rendered tiles generated by a tile-based graphics processing system (graphics processor), video data blocks generated by a video processing system (video processor), and a composition processing system. Composite frame tiles generated by and / or image blocks generated by camera sensors, and the like.

  For example, it is possible to use the present invention when there are multiple masters that all write data blocks to the output buffer. This may be the case, for example, when the host processor generates an “overlay” to be displayed on the image being generated by the graphics processor.

  In such a case, all of the different master devices can have an output on which, for example, the data block comparison process operates. Alternatively, the data block comparison process can be disabled if there are two or more master devices that generate data blocks for the output data array. In such cases, the comparison process can be performed, for example, for the entire output data array, or only for portions of the output data array where two master devices may have generated output data blocks (e.g., a host processor "overlay"). Can be disabled (only for regions of the output data array that will be displayed).

  In a particularly preferred embodiment, data block signatures generated for use in the present invention are “salt” ed when created (i.e., other numerical values (salt values) are appended to the generated signature value). Have been). The salt value may conveniently be, for example, a numerical value in a data output array (eg, a frame) after activation, or a random value. This helps to make the errors caused by inaccuracies in the comparison process of the present invention non-deterministic as known in the art (i.e., the process displays a movie or television program, for example) To avoid errors always occurring at the same point for iterative viewing of a given sequence of images, such as when used for

  Typically, the same salt value is used for one frame. The salt value can be updated every frame or periodically. For periodic salting, the salt value should be changed at the same time as signature comparison is disabled (if it is done) to minimize the bandwidth to write the signature.

  Applicants can use the techniques of the present invention, for example, in a tile-based graphics processing system, for example, by counting the number of “matches” of data blocks (eg, tiles) identified in the present invention. Assess or estimate the correlation between successive output data arrays (e.g., frames) and / or sequences of output data arrays (e.g., frames) (i.e., the degree to which the output data arrays (e.g., frames) are similar to each other) Further recognize that you can. In addition, the Applicant, for example, indicates that the image is stationary for a period of time, for example, if the information indicates that consecutive frames are the same (high correlation). , Also recognized as useful. In that case, for example, the frame rate can be reduced.

Thus, according to a further aspect of the present invention, data for which an output array of data is generated by a data processing system that writes a block of data representing a particular region of the output array of data to an output buffer and stores the output array of data A method is provided for operating a processing system, the method comprising:
When the data processing system writes a block of data to the output buffer, it compares that block of data with at least one block of data already stored in the output buffer, and the result of the comparison for multiple blocks of data To estimate the correlation between different output sequences of the data processing system.

According to another aspect of the present invention, a data processing system is implemented, the system comprising:
Means for generating data to form an output array of data to be supplied by the data processing system;
Means for storing data generated by the data processing system in the output buffer as an array of data by writing to the output buffer a block of data representing a particular region of the array of data;
Means for comparing a data block to be written to the output buffer with at least one data block already stored in the output buffer;
Means for estimating a correlation between different output sequences of the data processing system using the results of the comparison for the plurality of blocks of data.

  As those skilled in the art will appreciate, all of these aspects and embodiments of the invention may include one or more or all of the preferred and optional features of the invention described herein. Yes, preferably. Thus, for example, the comparison preferably includes comparing signatures representing the contents of each data block.

  Similarly, data blocks may be rendered tiles generated by a tile-based graphics processing system, video data blocks generated by a video processing system, and / or composite frame tiles generated by a composite processing system, for example. And preferably those.

  In these arrangements, the estimated correlation between different output sequences (e.g., frames) is preferably used to control further processes of the system regarding the output sequence or frame, such as frequency of generation and / or format. The Thus, in a particularly preferred embodiment, the output array (frame) generation rate and / or display refresh rate, and / or the form of anti-aliasing used for the output array (frame) is an estimate between different output arrays (frames). Controlled or selected based on the correlated.

  The present invention can be implemented in any suitable system, such as a suitably configured microprocessor-based system. In a preferred embodiment, the present invention is implemented in a computer and / or microprocessor based system.

  Various functions of the present invention may be performed in any desired and preferred manner. For example, the functions of the present invention can be implemented in hardware or software as required. Thus, for example, the various functional elements and “means” of the present invention are appropriately dedicated hardware elements and / or programmable hardware elements that can be programmed to operate in a desired manner, etc. May include one or more suitable processors, one or more controllers, functional units, circuits, processing logic, microprocessor arrangements, etc. operable to perform various functions and the like.

  In a preferred embodiment, the graphics processor and / or transaction exclusion unit is implemented as a hardware element (eg, an ASIC). Accordingly, in other embodiments, the invention is directed to one or more of the embodiments of the invention described herein, or one of the embodiments of the invention described herein. A hardware element is provided that includes an apparatus that operates according to one or more methods.

  It should also be noted that various functions of the present invention may be replicated on a given processor and / or executed in parallel on a given processor, as will be appreciated by those skilled in the art.

  The present invention is applicable to any suitable form or configuration of graphics processor and renderer, such as a processor that takes a “pipelined” rendering arrangement (in this case, the renderer takes the form of a rendering pipeline). ). This is particularly applicable to tile-based graphics processors and graphics processing systems.

  As will be appreciated from the above, the present invention is not exclusively applicable, but is particularly applicable to 2D and 3D graphics processors and processing devices, and accordingly, the invention described herein. 2D and / or comprising an apparatus of one or more aspects of the embodiments or operating according to a method of one or more aspects of the invention described herein Or extended to 3D graphics processors and 2D and / or 3D graphics processing platforms. Assuming that hardware is required to perform the specific functions described above, such 2D and / or 3D graphics processors may in some other way be 2D and / or 3D graphics processors. Can comprise one or more or all of the normal functional units and the like.

  Those skilled in the art will also understand that all described aspects and embodiments of the present invention may include one or more or all of the preferred and optional features described herein, as appropriate. Will do.

  The method according to the invention can be implemented at least in part using software, for example using a computer program. As such, when viewed from another aspect, the present invention provides computer software, data processing means specially adapted to perform the methods or methods described herein when installed on the data processing means. A computer program element that includes computer software code portions that perform the methods described herein when the program element is executed, and described herein when the program is executed on a data processing system It can be seen that a computer program is provided that includes code means adapted to perform all the steps of one or more of the described methods. The data processing system may be a microprocessor, a programmable FPGA (Field Programmable Gate Array), or the like.

  The invention further provides a method of the invention for a processor, renderer or system in conjunction with the data processing means when used to operate a graphics processor, renderer or other system comprising data processing means. The present invention also extends to a computer software carrier including such software that causes the steps of Such a computer software carrier can be a physical storage medium such as a ROM chip, a CD ROM, or a disk, or an electronic signal on a cable, an optical signal, or a satellite or the like It can be a signal such as a radio signal.

  Furthermore, it will be understood that not all steps of the methods of the present invention need be performed by computer software, and thus, from a broader perspective, the present invention is not limited to the methods described herein. Computer software and such software installed on a computer software carrier are provided for performing at least one of the plurality of steps.

  Therefore, the present invention can be appropriately implemented as a computer program product for use with a computer system. Such implementations include, but are not limited to, optical or analog communication lines fixed on tangible, non-transitory media such as diskettes, CD ROM, ROM, or hard disks. Can be transmitted to a computer system on a tangible medium or via a modem or other interface device using intangible means of wireless technology including, but not limited to, microwave, infrared, or other transmission technology A series of computer readable instructions. These series of computer readable instructions implement all or part of the functionality already described herein.

  Those skilled in the art will appreciate that such computer readable instructions can be written in many programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using current or future memory technologies including, but not limited to, semiconductor, magnetic, or light, or light, infrared, or micro, without limitation. It can be transmitted using current or future communication technologies, including waves. Such computer program products are distributed pre-installed in a computer system on a removable medium, for example a system ROM or fixed disk, attached with a printed or electronic document, eg distributed as commercial software, or on a server or network, For example, it is contemplated that it can be distributed from an electronic bulletin board on the Internet or the World Wide Web.

  Numerous preferred embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings.

1 is a schematic diagram of a first embodiment in which the present invention is used in conjunction with a tile-based graphics processor. FIG. It is a figure which shows the outline of how the relevant data are stored in memory in the 1st Embodiment of this invention. FIG. 2 is a diagram showing an overview and details of a transaction exclusion hardware unit of the embodiment shown in FIG. FIG. 5 shows a schematic of possible modifications to the operation of a preferred embodiment of the present invention. FIG. 5 shows a schematic of possible modifications to the operation of a preferred embodiment of the present invention. FIG. 6 illustrates a combination of multiple image sources that form an output for display. FIG. 2 is a schematic diagram of an embodiment of the present invention with multiple image sources. FIG. 6 shows a schematic of another embodiment of the invention with multiple image sources. It is a figure which shows other embodiment of this invention. It is a figure which shows other embodiment of this invention.

  A number of preferred embodiments of the invention will now be described. Although these embodiments have been described with respect to using the present invention exclusively in a graphics processing system, as noted above, the present invention provides data that represents a portion of the overall output, such as video processing, in blocks. It can be applied to other data processing systems to process.

  Similarly, the following embodiments are described with respect to a comparison of rendered tiles generated exclusively by a tile-based graphics processor in the manner of the present invention, but again, as noted above, the present invention is It is not limited to a simple arrangement configuration.

  FIG. 1 shows an outline of the arrangement of a graphics processing system according to the present invention.

  The graphics processing system comprises a tile-based graphics processor or graphics processing unit (GPU) 1, as shown in FIG. 1, which is generated as is known in the art. Generate tiles of the output data array, such as the output frame to be. The output data array can typically be an output frame intended to be displayed on a display device, such as a screen or printer, as is known in the art, for example, It may include a “render to texture” output, such as a graphics processor.

  As is known in the art, in such an arrangement, the tiles are generated by the graphics processor 1 and then usually through the interconnect 3 connected to the memory controller 4. Are written in the frame buffer in the memory 2 (this memory may be DDR-SDRAM). Sometime later, the frame buffer is read by, for example, a display controller and output to the display.

  In an embodiment of the present invention, this process is modified by the use of a transaction exclusion hardware unit 5 that controls the writing of tiles generated by the graphics processor 1 to the frame buffer in the memory 2. In essence, and as described in more detail below, transaction exclusion hardware 5 operates to generate a signature that represents the contents of the tile for each tile, and then checks to see if the signatures match To compare the signature with the signature of one or more tiles already stored in the frame buffer. (Thus, in this embodiment, the data blocks to be compared include rendered tiles generated by the graphics processor.)

  If the signature matches, then it is assumed that the new tile is the same as the tile already stored in the frame buffer, where the transaction exclusion hardware unit 5 refrains from writing the new tile to the frame buffer. .

  In this way, embodiments of the present invention can avoid write traffic to sections of the frame buffer that do not actually change from one frame to the next (in the case of games, this is Interface, most of the sky etc., and most of the play field when the camera position is still). This can save a significant amount of bandwidth and power consumption for frame buffer operation.

  On the other hand, if the signatures do not match, a new tile is written to the frame buffer, and the generated signature for that tile is also written to memory.

  FIG. 2 shows an exemplary memory layout for this, where the tiles that make up the frame are stored in a portion 10 of the memory (thus forming a “frame buffer”) and related to the tiles that make up the frame. The signature is stored in the other part 11 of the memory. (Other processing methods are, of course, possible.) For high-definition (HD) frames, if it is a 16x16 32-bit tile, use a 32-bit signature to add 30KB to an 8MB frame .

  (If the frame buffer is double buffered, preferably the signature data is stored for each frame (and with each frame). The new tile is then compared to the oldest frame in memory. )

  FIG. 3 shows the transaction exclusion hardware unit 5 in more detail.

  As shown in FIG. 3, the tile data received by the transaction exclusion hardware unit 5 from the graphics processor 1 is a buffer 21 that temporarily stores the tile data during the signature generation and comparison process. And also to the signature generator 20.

  The signature generator 20 operates to generate a signature required for the tile. In an embodiment of the invention, the signature takes the form of a 32-bit CRC for the tile.

  Other forms of signatures, such as other signature generation functions and hash functions, or alternatively, can be used if desired. For example, it is possible to generate a single signature for one RGBA tile, or another signature for each color plane. Similarly, color conversion can be performed and separate signatures can be generated for each of Y, U, and V. To reduce power consumption, the order of tile data processed by the signature generator 20 can be changed as needed (eg, using a Hilbert curve).

  When a signature for a new tile is generated, this tile will act to compare the signature of the new tile with one or more signatures of one or more tiles that are in the frame buffer or already exist. To the signature comparator 23. In an embodiment of the invention, the comparison is a comparison with the signature of a tile already in the frame buffer at the tile position for the tile of interest.

  The signature buffer 22 of the transaction exclusion hardware unit 5 (this buffer can be implemented in various ways, for example as a buffer or cache) so that signatures for multiple tiles from the previous frame can be easily retrieved during system operation. Therefore, the signature comparator 23 fetches the associated signature from the signature buffer 22 if it exists (or fetches the signature from the main memory 2 as is known in the art). Compare the signature of the previous frame tile with the signature received from the signature generator for a match.

  If the signatures do not match, the signature comparator 23 controls the write controller 24 to write the new tile and its signature to the frame buffer and the associated signature data store in the memory 2. On the other hand, if the signature comparator finds that the signature of the new tile matches the signature of the tile already stored in the frame buffer, the write controller 24 invalidates the tile and stores it in the frame buffer. Does not write any data (ie, it can leave an existing tile in the frame buffer and keep its signature).

  In this way, if the signature comparison reveals that the tile is different from the tile already stored in the memory 2, the tile is written only to the frame buffer in the memory 2. This helps to reduce the number of write transactions to memory 2 when a frame is being generated.

  In an embodiment of the present invention, signature comparisons for each stored tile in the frame buffer are periodically invalidated to stop an illegally matched tile from being in the frame buffer for too long. (Preferably once per second). This means that if a tile with signature comparison disabled is newly created, it is inevitable that the newly created tile will be written to the frame buffer in memory 2. Yes. In this way, it can be ensured that mismatched tiles are always replaced with completely new (and therefore correct) tiles over time. (For random tiles, for example, a 32-bit CRC will generate a false match (i.e. a situation where the same signature is generated for tiles with different content) once every 2 ^ 32 tiles, and every second (With 30 frames of 1080 HD resolution, the comparison process occurs approximately every 4 hours, resulting in tile mismatch.)

  In embodiments of the present invention, stored tile signature comparisons are disabled in a predetermined, circular, sequence, so that every second (and / or eg 25 or 30 frames as a set). Over this set), each individual tile invalidates its signature comparison once (thus writing a new tile for it).

  Other processing methods may be possible. For example, the system can simply be configured to export completely new frames periodically (eg, once per second) in the same manner as MPEG video. In addition, or alternatively, a longer signature can be used for each tile, which significantly reduces the rate at which false tile matching occurs due to the fact that signatures for different tiles are actually identical. . For example, a larger CRC, such as a 64-bit CRC, can reduce such discrepancies to a rate of once every 1.2 million years.

  (Alternatively, such false tile matches can be perceived by the fact that the tiles are still similar anyway, and mismatched tiles can only be displayed on the order of 1/30 seconds or less. (There can be no prevention in this respect because there is no such thing.)

  For example, it is possible to weight signature generation to aspects of the content of the tile that are considered more important (eg, how the user perceives the final display tile). For example, a longer signature can be generated for a color MSB bit compared to a color LSB bit (since color LSB bits are generally less important than MSB bits). The signature length can also be changed during use, for example depending on the application, to help minimize power consumption.

  In a particularly preferred embodiment, data block signatures generated for use in the present invention are “salt” ed when created (i.e., other numerical values (salt values) are appended to the generated signature value). Have been). The salt value may conveniently be, for example, a numerical value in a data output array (eg, a frame) after activation, or a random value. This helps to make the errors caused by inaccuracies in the comparison process of the present invention non-deterministic as known in the art (i.e., the process displays a movie or television program, for example) To avoid errors always occurring at the same point for iterative viewing of a given sequence of images, such as when used for

  As described above, in an embodiment of the present invention, the signature comparison process operates to compare the newly generated tile with the tile stored for the corresponding tile location in the frame buffer.

  However, in other preferred embodiments, a given generated tile is compared to a plurality of tiles already stored in the frame buffer. In this case, the signature generated for that tile is compared accordingly with the signatures of the multiple tiles stored in the frame buffer. In this case, such a comparison is performed with the signature of the tile stored in the signature buffer 22 of the transaction exclusion hardware unit 5 (i.e., with a subset of all stored tiles for the frame). Preferably, other configurations are possible if desired, such as a comparison of new tiles with all stored tiles. Preferably, the tiles are processed in an appropriate order, such as a Hilbert order, to increase the likelihood that the signature matches a tile stored in the signature buffer 22.

  In this case, the signature generated for the new tile is correspondingly compared to the signatures of the multiple tiles in the current output frame (these tiles are understood by those skilled in the art as the current frame Newly written tiles, or tiles from the previous frame (s) that actually "carry over" to the current frame because they matched the tiles of the current frame).

  In this embodiment, a list is maintained that indicates whether the tile is the same as other tiles with different tile coordinates in the previous frame. The corresponding list entry is then read when reading the tiles to be displayed. When the list entry value is zero (null), the data stored in the normal tile position for the tile is read. Otherwise, the list entry may be an address of a different tile to read, which can be automatically translated by, for example, the transaction exclusion hardware unit 5 to determine the position of the tile in the frame buffer to be read for the current tile position. including.

  In a preferred embodiment of the present invention, a tile comparison process is performed for every tile that is generated. However, in another preferred embodiment, an adaptive scheme is used that reduces the tiles to analyze when little correlation is expected between frames. In this arrangement, the historical number of tile matches is used as a measure of correlation between frames (if there are multiple tile matches, it can be assumed that there are multiple correlations between frames, The reverse is also true). The transaction exclusion hardware can comprise a suitable controller for performing this operation.

  So in this case, if it is determined that there is a lot of correlation between the frames (that is, many of the tiles match the tiles already in the frame buffer), a signature is generated for all of the tiles. If it is determined that there is little correlation between frames (few or no tiles are known to match the tiles already stored in the frame buffer) A signature is generated and a tile comparison process is performed.

  FIG. 4 illustrates this. FIG. 4a shows the case where there are many correlations between frames and signatures are generated for all tiles. FIG. 4b shows the reverse situation where there is little correlation between frames, in which case signatures are generated and compared for only a subset 31 of tiles.

  Using these principles, for example, determine which particular part of a frame has a higher correlation and then increase the number of tiles that are compared in a particular region of that frame only if desired It is also possible to try.

  As will be appreciated by those skilled in the art, the transaction exclusion hardware unit 5 is operable with respect to the output generated by the graphics processor 1, such as a graphics frame buffer, a texture to graphic render, and the like.

  As will be appreciated by those skilled in the art, in a typical system with a graphics processor 1, there may be a number of image sources such as a GUI, graphics, and video. These sources can be synthesized using a display controller that uses layers, or a dedicated composition engine, or using, for example, a graphics processor. FIG. 5 shows an example of such a composite frame.

  In such an arrangement, the transaction exclusion process of the present invention can be used, for example, only with a graphics processor. FIG. 6 shows a possible system configuration for such an arrangement. In this case, there is a graphics processor 1, a video codec 60, and a CPU 61, each generating a potential image source for display. The transaction exclusion unit 5 is arranged between the graphics processor 1 and the memory interconnect 3.

  However, Applicants have noted that the transaction exclusion process of the present invention is processed in blocks in a manner similar to tiles in tile-based graphics processors such as video processors (video codecs) that generate video blocks for video frame buffers. It is recognized that it can be used equally well for other types of data and for graphics processor image synthesis. Thus, the transaction exclusion process of the present invention is equally applicable to images being generated by video processor 60, for example.

  Thus, FIG. 7 shows an alternative configuration in which the transaction exclusion hardware unit 5 can operate in the manner described above to process the appropriate image output from any of the graphics processor 1, video processor 60, and CPU 61. ing. In this arrangement, the transaction exclusion hardware unit 5 is enabled to operate on specific defined and selected portions of a specific master ID and / or address map.

  Other arrangements are of course possible.

  For example, it is possible to use the present invention when there are multiple masters that all write data blocks to the output buffer. This may be the case, for example, when the host processor generates an “overlay” to be displayed on the image being generated by the graphics processor.

  In such a case, all of the different master devices can have an output on which, for example, the data block comparison process operates. Alternatively, the data block comparison process can be performed on the output data array, on the entire output data array, or on a portion of the output data array where two master devices may be generating the output data block. Can only be disabled when there are two or more master devices that generate data blocks (eg only for regions of the output data array where the host processor “overlay” is to be displayed).

  8 and 9 show another embodiment of the present invention. FIG. 8 shows an outline of the arrangement configuration of this embodiment, and FIG. 9 is a flowchart showing the steps of the data block comparison process in this embodiment.

  In this embodiment, as shown in FIG. 8, the transaction exclusion hardware unit is an integral part of the graphics processor (GPU) 1. The transaction exclusion hardware unit 5 compares the new data block with other data blocks generated for the output array (frame) of interest, as described further below, and already in the output data array It also operates so as not to compare with the stored data block.

  Thus, in this embodiment, the graphics processor 1 comprises a transaction exclusion unit 5 comprising a data block generation logic 41 and a block comparison logic 43 after the tile rendering logic 40. Block generation logic 41 operates to generate appropriate data blocks from the tiles generated by tile rendering logic 40. In an embodiment of the present invention, block generation logic generates blocks corresponding to the partial tiles of the tiles generated by tile rendering logic 40. However, as described herein, data blocks of other sizes and formats are possible and can be generated by the block generation logic 41 if desired.

  The block generation logic stores successive blocks to be generated in the buffer 42. The comparison logic 43 then compares each data block stored in the buffer 42 (in this case, comparing the new data block with the previous data block), and based on this comparison, the blocks are the same. Generate output metadata bits that indicate whether they are considered. Metadata output bits for multiple blocks are collected and merged into one buffer (to increase memory efficiency), then into the metadata bitmap 45 in main memory 2 associated with the output data array of interest Stored as appropriate (written to off-chip memory). (Other processing methods are of course possible.)

  The data block is also read from the buffer 42, a write exclusion process described later is executed, and stored appropriately in the frame (output) buffer 4 in the memory 2.

  In this embodiment, the metadata is configured such that each data block (partial tile) location in the output data array 44 in the memory 2 is associated with a bit in the metadata bitmap 45, and a bit for the data block. The bit in the map is set to '1' if the data block is considered to be the same as the previous data block in the output data array, and the data block is considered different from the previous data block Is set to "0". This in turn allows the device reading the output data array 44 to determine which data block to use for each data block location, as further described below.

  To facilitate this operation, the data blocks that make up the output frame are processed in a specific predefined order (both when writing to and reading from the frame buffer). An order in which spatial coherence between blocks can be utilized is preferably used.

  The data array and metadata generation process is shown as a flow diagram in FIG.

  As shown in FIG. 9, the block generation logic 41 generates data blocks (in this case, corresponding to partial tiles) from the rendered tiles generated by the tile rendering logic 40 (step 51). The data block is then stored in the buffer 42.

  The comparison logic 43 then compares the new data block with the previous data block (which is already stored in the buffer 42) (step 52). In the present embodiment, the comparison logic 43 compares the contents of the data blocks. Other processing methods may be possible. For example, the comparison logic can compare the signatures for the blocks rather than the actual contents of the blocks, as described above.

  The comparison logic then determines whether the new block should be considered similar to the previous block (step 53). In an embodiment of the invention, this evaluation is based on how similar the contents of the two blocks being compared are. For example, a threshold of a certain amount of difference in a pixel's LSB is set, and if the difference between the contents of two blocks is less than this threshold, the blocks are determined to be similar, and vice versa.

  (This threshold can be changed (eg, programmed) during use. For example, based on the ratio of static frame data to dynamic frame data and / or power mode in use (eg, low power mode) Can be set for each application based on whether or not)

  Other data block comparison schemes can be used if desired.

  If the block is determined to be different (not similar) by the comparison logic in step 53, the comparison logic operates to write the value “0” to the appropriate location in the metadata bitmap 45 (step 54). ). This new data block is written from the buffer 42 to the frame buffer 44 in the main memory 2 (step 55).

  On the other hand, if it is determined in step 53 that the blocks should be considered similar, the comparison logic 43 operates to cause “1” to be written to the appropriate location in the metadata bitmap 45. (Step 56).

  Further, if the two blocks are considered similar to each other, the new block is not written into the data array in the frame buffer 44 (step 58).

  As a result, if it is determined that the data block is the same as the previous data block (i.e., the same as the previous data block stored in the frame buffer 44), the new data block is similarly stored in the frame buffer. Not written to 44. In this way, write traffic to sections of the data array (frame buffer) 44 that are identical to each other can be avoided. (On the other hand, if it is determined that the data blocks are different, a new data block is written to the frame buffer 44.)

  In this arrangement, when a device such as a display controller reads the output data array 44, it also reads the corresponding metadata bitmap 45. For each data block in the data array that is to be processed, the corresponding bitmap entry is read, and if that bitmap entry is set to `` 1 '', that data block is in the output data array 44 Knowing that it was considered the same as the previous stored data block, and therefore displaying the previous appropriate data block in the output data array 44 as a new block. Alternatively, if the metadata associated with the data block to be processed is "0", the display controller should read a new data block from the data array 44 and display the new block. know.

  In this way, even if the data array 44 cannot contain a data block entry for every data block position in the data array 44, the appropriate data block data can be read and processed.

  (Thus, in these arrangements, the data block itself may not be written to the data array 44, but the processing device reading the data array (such as a display controller) is replaced by any other block. (Because that information is used to determine what to do, comparison metadata 45 should be generated and stored for the block location of interest.)

  If there is a sequence of similar blocks, the metadata correspondingly includes a sequence of “1” in this embodiment, and the device that reads the data array is in this sequence for each successive similar block. It will be understood that the first block of is reused.

  It is also possible to compare a data block with multiple other blocks of the data array (eg, multiple previous data blocks) to see if it is similar to any of the other blocks. In this case, each metadata entry includes a plurality of bits, which can indicate to which of the other data blocks the block of interest was considered similar.

  As mentioned above, in one particularly preferred arrangement of this embodiment, if the data block comparison is not accurate (assuming that it is actually a different but erroneously matched block), the system will generate newly generated data. The block is configured to be written to the frame buffer 44 regularly, for example, once per second for each predetermined data block (data block position).

  The above embodiments and many other alternatives and arrangements of the invention can be used as needed.

  For example, it has a hardware register that enables / disables tile signature calculation for a specific frame area, so that only if the tile has a register for the frame area where the tile is located Transaction exclusion signature generation and comparison can be performed.

  The graphics processor (for example) driver then allows the software application to access and set these tile signature enable / disable registers so that the software application can perform signature generation and comparison. It can be configured to be given an opportunity to directly control whether and where (for which frame region) it is executed. This allows the software application to control how and whether signature calculations and comparisons are performed, for example. This can then be used, for example, to eliminate the power consumed by the signature calculation for the region of the output frame that “knows” when it is constantly updated on the application side. Always update such areas of the frame without first performing a signature check).

  The number of such registers can be selected, for example, as a trade-off between the required additional logic to implement and use them and the desired granularity of control.

  It is also possible to take further advantage of the fact that the number of tile matches in a frame can be used as a measure of correlation between successive frames, as described above. For example, it is possible to determine whether an image is static, such as between successive frames and / or over a period of time, by using a counter to track the number of tile matches within a given frame . Thereby, if it is determined that the image is static for a certain period of time, for example, the processor frame rate can be reduced (leading to power saving), the display refresh rate can be reduced, and / or Or it is possible to re-render the frame using better anti-aliasing (this improves (perceived) image quality) and vice versa.

  The arrangement of the present invention can also be used in conjunction with other frame buffer power and bandwidth reduction techniques, such as frame-buffer compression. In this case, write transaction elimination according to the method of the present invention is preferably performed first, followed by compression (or other) operations. Then, if the compression process finds that the signature of the tile is the same, the previous compressed tile can be kept as a tile to be used in the current output frame, but if the tile is not “excluded”, the new The tiles are sent to frame buffer compression (or other) hardware and then sent to the frame buffer in memory. This means that compression operations can be avoided if the tile signatures match.

  This embodiment is described above with respect to comparing rendered tiles to be written to the frame buffer, among other things, but forms an area of the output data array to be compared as described herein. Data blocks (and, for example, those with signatures generated for them) need not correspond exactly to the rendered tiles generated by the graphics processor.

  For example, the data blocks considered and compared can be composed of a plurality of rendered tiles and / or can include a small portion of the rendered tiles. In fact, different data block sizes can be used for different regions of the same output array (e.g., output frame) and / or the size and shape of the data block, if desired, e.g. depending on the write transaction rejection rate Adaptation can be changed.

  If a data block size is used that does not exactly correspond to the size of the rendered tile, the transaction exclusion hardware unit 5 conveniently uses the graphics processor (or other that supplies data to it for the output array). From the data, such as rendered tiles, from which the appropriate data blocks (and, for example, signatures for these data blocks) can be assembled or generated.

  From the above, it can be seen that the present invention, at least in its preferred embodiments, can help, for example, reduce power consumption and memory bandwidth of a graphics processor.

  This is accomplished, at least in the preferred embodiment of the present invention, by eliminating unnecessary frame buffer memory transactions. This reduces the amount of data rendered in the frame buffer, and thus significantly reduces system power consumption and memory bandwidth consumption. This can be applied to graphics frame buffer, texture to graphics render, video frame buffer, composite frame buffer transactions, and the like.

  Applicants have found that for graphics and video operations, the transaction reduction rate can be between 0 and 30%. (Analysis of some common games such as Quake 4 and Doom 3 showed that 0 to 30% of the tiles in each frame are typically the same.) The transaction rejection rate is likely to be very high (greater than 90%) because only the mouse pointer is moving for most of this time.

  The power saving effect when using the present invention can be relatively large.

  For example, a 32-bit mobile DDR-SDRAM transfer can consume about 2.4 nJ per 32-bit transfer. Thus, assuming a graphics processor frame output rate of 30Hz and considering only the primary effect, the graphics processor frame buffer write (without the present invention) is about (1920 x 1080 x) for HD graphics. 4) × (2.4nJ / 4) × 30 = 150mW is consumed.

  On the other hand, if 20% of the frame buffer traffic can be eliminated for HD graphics, it will save about 30mW (and 50MB / s). For the HD composite frame buffer, removing 90% of the frame buffer traffic results in a reduction of 135 mW (and 220 MB / s).

1 Tile-based graphics processor or graphics processing unit (GPU)
2 memory
3 Interconnection
4 Memory controller
5 Transaction exclusion hardware
10, 11 pieces
20 Signature generator
21 buffers
22 Signature buffer
23 Signature comparator
24 write controller
31 subset
40 tile rendering logic
41 Data block generation logic
42 buffers
43 Block comparison logic
44 Frame buffer
45 Metadata bitmap
60 video codec
61 CPU

Claims (23)

A method of operating a data processing system in which data generated by a data processing system is used to form an output array of data in an output buffer,
Storing the output array of data in the output buffer by the data processing system writing to the output buffer a block of data representing a particular region of the output array of data;
If a block of data has been generated for the output data array, the data processing system compares that block of data with at least one other block of data and the generated of data based on the comparison Determining whether to write a block to the output buffer.   The method of claim 1, wherein the comparison process includes comparing signatures representing the contents of each data block.   The method according to claim 1 or 2, wherein the generated data block is compared with only one other data block.   The method according to any one of claims 1 to 3, wherein the data block comparison is performed on some but not all of the data blocks to be generated for a given output data array.   5. A method according to any one of the preceding claims, wherein the data processing system is configured to regularly write a newly generated data block for each data block location to the output buffer periodically.   The method according to any one of claims 1 to 5, wherein the data processing system is a tile-based graphics processing system, and each data block corresponds to a rendered tile generated by the graphics processing system. .   The method according to claim 1, wherein the data processing system is a graphics processing system, and the output data array is an output frame to be generated by the graphics processing system.   8. The method according to claim 1, wherein the data processing system is a graphics processing system, and the output buffer is a frame buffer to which the output of the graphics processing system is written.   9. The data processing system according to claim 1, wherein the data processing system is a graphics processing system, and the output buffer is a texture or other surface to which the output of the graphics processing system is written. the method of. A data processor comprising means for generating data for forming an output array of data to be supplied by the data processor;
Means for storing data generated by the data processor in the output buffer as an array of data by writing to the output buffer a block of data representing a particular region of the array of data;
To compare a block of data generated for the output data array with at least one other block of data and to determine whether to write the generated block of data to the output buffer based on the comparison A data processing system further comprising: For use in the data processing system, wherein the output array of data generated by the data processing system is stored in the output buffer by writing a block of data representing a particular region of the output array of data to the output buffer A write transaction eliminator,
Comparing a block of data generated for the output data array with at least one other block of data and determining whether to write the generated block of data to the output buffer based on the comparison A write transaction elimination apparatus comprising:   12. The system of claim 10 or the apparatus of claim 11, wherein the comparing means includes means for comparing signatures representing the contents of each data block.   13. The system or apparatus according to any one of claims 10 to 12, wherein the generated data block is compared with only one other data block.   14. The means of any one of claims 10 to 13, further comprising means for selecting the number of generated data blocks to be compared with one or more other data blocks for a given output data array. The system or device described.   15. The data processing system or write transaction eliminator is configured to constantly write a newly generated data block for each data block location periodically to the output buffer. The system or device described.   16. The system according to any one of claims 10 to 15, wherein the data processing system is a tile-based graphics processing system, each data block corresponding to a rendered tile generated by the graphics processing system. Or equipment.   The system according to any one of claims 10 to 16, wherein the data processing system is a graphics processing system, and the output buffer is a frame buffer to which the output of the graphics processing system is written. apparatus.   17. The data processing system is a graphics processing system, and the output buffer is a texture or other surface to which the output of the graphics processing system is written. System or device.   Write transaction elimination hardware comprising means for storing data generated by the data processor in the output buffer as an array of data by writing a block of data representing a particular region of the array of data to the output buffer Whether to compare a wear element and a block of data generated for the output data array to at least one other block of data and write the generated block of data to the output buffer based on the comparison 19. A system according to any one of claims 10 or 12 to 18 comprising means for determining.   The system of claim 19, wherein the write transaction exclusion hardware element is an integral part of the data processor. A method of operating the data processing system, wherein the output array of data is generated by a data processing system that writes a block of data representing a particular region of the output array of data to an output buffer and stores the output array of data. ,
When the data processing system writes a block of data to the output buffer, it compares that block of data with at least one block of data already stored in the output buffer and for a plurality of blocks of data Using the result of the comparison to estimate a correlation between different output sequences of the data processing system. A data processing system,
Means for generating data to form an output array of data to be supplied by the data processing system;
Means for storing data generated by the data processing system in the output buffer as the array of data by writing to the output buffer a block of data representing a particular region of the array of data;
Means for comparing a data block to be written to the output buffer with at least one data block already stored in the output buffer;
Means for estimating correlations between different output sequences of the data processing system using the results of the comparison for a plurality of blocks of data. A computer program element,
Computer program element comprising computer software code portions for performing the method according to any one of claims 1 to 9 or 21 when the program element is executed on a data processing means.

Images