Method, apparatus, device, and storage medium for prefetching data of a frame of texture data

Abstract

This disclosure provides methods, apparatus, devices, storage media, and program products for prefetching data from texture data frames, relating to the field of video processing. In the method, a request for target data of a texture data frame is received, the request including an address for accessing the target data; based on the address and information indicating the rendering and storage methods of the texture data frame, a plurality of prefetch addresses are determined, wherein associated data at the plurality of prefetch addresses is predicted to be accessed after the target data; and based on at least one of the plurality of prefetch addresses, at least a portion of the associated data is prefetched. Thus, embodiments of this disclosure can more accurately prefetch subsequently accessed data associated with the requested target data by considering both the rendering and storage methods of the texture data frame, thereby improving the efficiency of prefetching texture data frames and the efficiency of video processing.

Description

Technical Field

[0001] The embodiments of this disclosure primarily relate to the field of computer science, and particularly to the field of video and image processing. More specifically, the embodiments of this disclosure relate to methods, apparatus, devices, computer-readable storage media, and computer program products for prefetching texture data frames. Background Technology

[0002] In video and image processing, texture data frames are typically compressed and stored using block compression. Compressing a texture data frame yields the corresponding compressed data and a compression header containing information indicating the compressed data. The compression header and compressed data are usually stored in different parts of the storage device. When rendering a texture data frame or performing other processing, the compression header in the storage device can be accessed first, and then the corresponding compressed data can be accessed based on the information indicated by the compression header, thereby improving the efficiency of video processing.

[0003] Typically, when accessing a compressed header, other compressed headers associated with the requested header can be prefetched from slower storage to a faster HDR cache to improve access efficiency. However, if a prefetched header is not requested within a certain timeframe, the prefetch operation wastes HDR cache resources. Therefore, a method for efficiently and accurately prefetching data is needed to improve the efficiency of accessing compressed headers, thereby enhancing the efficiency of video and image processing. Summary of the Invention

[0004] Embodiments of this disclosure provide a scheme for prefetching texture data frames.

[0005] In a first aspect of this disclosure, a method for prefetching data from a texture data frame is provided, comprising: receiving a request for target data of the texture data frame, the request including an address for accessing the target data; determining a plurality of prefetch addresses based on the address and information indicating a rendering mode and a storage mode of the texture data frame, wherein associated data at the plurality of prefetch addresses is predicted to be accessed after the target data; and prefetching at least a portion of the associated data based on at least one of the plurality of prefetch addresses.

[0006] In this way, by considering both the rendering and storage methods of texture data frames, it is possible to more accurately prefetch subsequent data that may be accessed in association with the target data to be accessed, thereby improving the efficiency of prefetching texture data frames and the efficiency of video and image processing.

[0007] In some embodiments of the first aspect, the information includes at least one of the following: the size of a rendered tile indicating the rendering granularity of the texture data frame, a rendering path, the size of a compressed tile indicating the storage granularity of the texture data frame, the stride of a row-by-row compressed header, the coordinates of a compressed tile containing the target data, the location of the target data in the compressed tile, and address translation information indicating the relationship between the luminance data base address and the chrominance data base address.

[0008] In some embodiments of the first aspect, the associated data includes at least one of the following: chroma data or luminance data corresponding to the target data; data corresponding to the same rendering tile as the target data; and data of other rendering tiles determined based on the rendering tile and rendering path corresponding to the target data. In this way, as much data as possible that may be accessed subsequently can be prefetched, thereby improving the efficiency of prefetching texture data frames and the efficiency of video and image processing.

[0009] In some embodiments of the first aspect, the method further includes: filtering the plurality of prefetch addresses based on access history to determine the at least one prefetch address, wherein the access history includes records of recently accessed compressed tiles, the recently accessed compressed tiles comprising historical data accessed prior to the target data. In this manner, potentially accessed data can be prefetched more accurately based on patterns of requested data access, thereby improving the efficiency of data access.

[0010] In some embodiments of the first aspect, the record includes prefetch information and access information, the prefetch information indicating segments that have been prefetched in the compressed tile, and the access information indicating segments that have been accessed in the compressed tile.

[0011] In some embodiments of the first aspect, the texture data frame is divided into a plurality of compressed tiles, and filtering the plurality of prefetch addresses based on the access history includes: determining a current compressed tile containing the target data among the plurality of compressed tiles; determining a target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles; and filtering the plurality of prefetch addresses based on the access information of the target compressed tile.

[0012] In some embodiments of the first aspect, filtering the plurality of prefetch addresses based on the access information of the target compressed map includes: determining, based on the access information of the target compressed map, a segment that has been accessed in the target compressed map; determining a target segment in the current compressed map corresponding to the segment that has been accessed in the target compressed map; and determining an address among the plurality of prefetch addresses corresponding to the target segment as the at least one prefetch address.

[0013] In some embodiments of the first aspect, the method further includes: creating a record of the current compressed tile, the record of the current compressed tile including prefetch information indicating the target segment and access information indicating the segment containing the target data; removing the record of the earliest accessed compressed tile from the recently accessed compressed tiles from the access history; and adding the record of the current compressed tile to the access history to update the access history.

[0014] In some embodiments of the first aspect, determining a target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles includes determining the target compressed tile based on at least one of the following: distance from the current compressed tile; a predetermined association rule; and the time when the most recently accessed compressed tile was accessed.

[0015] In some embodiments of the first aspect, prefetching at least a portion of the associated data includes: in response to a cache miss of the at least a portion of the associated data, retrieving the at least a portion of the associated data from a memory outside the cache back into the cache.

[0016] In some embodiments of the first aspect, the method further includes: determining the number of recently accessed compressed tiles in the access history based on the size of the rendering window and the compressed tile.

[0017] In a second aspect of this disclosure, a method for accessing data in a texture data frame is provided, comprising: receiving a plurality of access requests for the texture data frame from a plurality of graphics processors; dividing the plurality of access requests into at least one group of access requests based on a rendering mode and a storage mode of the texture data frame; and processing the group of access requests using a processor corresponding to each group of access requests in the at least one group of access requests, wherein processing the group of access requests includes, for each of the group of access requests: determining a request for target data based on the access request, the request including an address for accessing the target data; determining a plurality of prefetch addresses based on the address and information indicating the rendering mode and the storage mode of the texture data frame, the associated data at the plurality of prefetch addresses being predicted to be accessed after the target data; and prefetching at least a portion of the associated data based on at least one of the plurality of prefetch addresses.

[0018] In this way, by routing access requests for a set of associated compressed tiles to the same processor, the efficiency of accessing texture data frames can be improved. For example, on the same processor, the compressed header prefetched for the first access request may also be the compressed header to be prefetched for the second access request. This reduces prefetching operations and improves data processing efficiency. In another example, the compressed header prefetched for the first access request may be the compressed header to be accessed by the second access request. This improves the efficiency of accessing the compressed header.

[0019] In some embodiments of the second aspect, dividing the plurality of access requests into at least one group of access requests based on the rendering and storage methods of the texture data frame includes: dividing the plurality of compressed tiles into at least one group of associated compressed tiles based on the positioning of the plurality of compressed tiles corresponding to the plurality of access requests and the rendering paths corresponding to the plurality of access requests; and dividing the plurality of access requests into the at least one group of access requests, wherein each group of access requests corresponds to a corresponding group of associated compressed tiles in the at least one group of associated compressed tiles. In this way, the accuracy of dividing the plurality of access requests can be improved, thereby improving the efficiency of accessing the texture data frame data.

[0020] In a third aspect of this disclosure, an apparatus for prefetching data from a texture data frame is provided, comprising: a request receiving unit configured to receive a request for target data of the texture data frame, the request including an address for accessing the target data; a prefetch address determining unit configured to determine a plurality of prefetch addresses based on the address and information indicating a rendering mode and a storage mode of the texture data frame, wherein associated data at the plurality of prefetch addresses is predicted to be accessed after the target data; and a prefetch unit configured to prefetch at least a portion of the associated data based on at least one of the plurality of prefetch addresses.

[0021] In some embodiments of the third aspect, the information includes at least one of the following: the size of a rendered tile indicating the rendering granularity of the texture data frame, a rendering path, the size of a compressed tile indicating the storage granularity of the texture data frame, the stride of a row-by-row compressed header, the coordinates of a compressed tile containing the target data, the location of the target data in the compressed tile, and address translation information indicating the relationship between the luminance data base address and the chrominance data base address.

[0022] In some embodiments of the third aspect, the associated data includes at least one of the following: chromaticity data or luminance data corresponding to the target data; data corresponding to the same rendering tile as the target data; and data of other rendering tiles determined based on the rendering tile and rendering path corresponding to the target data.

[0023] In some embodiments of the third aspect, the apparatus further includes a filtering unit configured to filter the plurality of prefetch addresses based on access history to determine the at least one prefetch address, wherein the access history includes a record of recently accessed compressed tiles, the recently accessed compressed tiles comprising historical data accessed prior to the target data.

[0024] In some embodiments of the third aspect, the record includes prefetch information and access information, the prefetch information indicating segments that have been prefetched in the compressed tile, and the access information indicating segments that have been accessed in the compressed tile.

[0025] In some embodiments of the third aspect, the texture data frame is divided into a plurality of compressed tiles, and the filtering unit is further configured to: determine a current compressed tile containing the target data among the plurality of compressed tiles; determine a target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles; and filter the plurality of prefetch addresses based on the access information of the target compressed tile.

[0026] In some embodiments of the third aspect, the filtering unit is further configured to: determine the segment that has been accessed in the target compressed block based on the access information of the target compressed block; determine the target segment in the current compressed block corresponding to the segment that has been accessed in the target compressed block; and determine the address corresponding to the target segment among the plurality of prefetch addresses as the at least one prefetch address.

[0027] In some embodiments of the third aspect, the apparatus further includes an access history update unit configured to: create a record of the current compressed tile, the record of the current compressed tile including prefetch information indicating the target segment and access information indicating the segment containing the target data; remove the record of the earliest accessed compressed tile from the recently accessed compressed tiles from the access history; and add the record of the current compressed tile to the access history to update the access history.

[0028] In some embodiments of the third aspect, the filtering unit is configured to determine the target compressed tile based on at least one of the following: distance to the current compressed tile; a predetermined association rule; and the time when the most recently accessed compressed tile was accessed.

[0029] In some embodiments of the third aspect, the prefetch unit is further configured to: in response to a cache miss of the at least portion of the associated data, retrieve the at least portion of the associated data from a memory outside the cache back into the cache.

[0030] In some embodiments of the third aspect, the apparatus further includes an access history maintenance unit configured to determine the number of recently accessed compressed tiles in the access history based on the size of the rendering window and the compressed tiles.

[0031] In a fourth aspect of this disclosure, an apparatus for accessing data of a texture data frame is provided, comprising: an access request receiving unit configured to receive a plurality of access requests for the texture data frame from a plurality of graphics processors; a grouping unit configured to divide the plurality of access requests into at least one group of access requests based on a rendering mode and a storage mode of the texture data frame; and a processing unit configured to process the group of access requests using a processor corresponding to each of the at least one group of access requests, wherein processing the group of access requests includes, for each of the group of access requests: determining, based on the access request, a request for target data, the request including an address for accessing the target data; determining, based on the address and information indicating the rendering mode and the storage mode of the texture data frame, a plurality of prefetch addresses, the associated data at the plurality of prefetch addresses being predicted to be accessed after the target data; and prefetching at least a portion of the associated data based on at least one of the plurality of prefetch addresses.

[0032] In some embodiments of the fourth aspect, the grouping unit is further configured to: divide the plurality of compressed tiles into at least one set of associated compressed tiles based on the positioning of the plurality of compressed tiles corresponding to the plurality of access requests and the rendering path corresponding to the plurality of access requests; and divide the plurality of access requests into the at least one set of access requests, each set of access requests corresponding to a corresponding set of associated compressed tiles in the at least one set of associated compressed tiles.

[0033] In a fifth aspect of this disclosure, an electronic device is provided, comprising: at least one computing unit; at least one memory coupled to the at least one computing unit and storing instructions for execution by the at least one computing unit, the instructions, when executed by the at least one computing unit, causing the device to implement the method provided in the first or second aspect.

[0034] In a sixth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, wherein the computer program is executed by a processor to implement the method provided in the first or second aspect.

[0035] In a seventh aspect of this disclosure, a computer program product is provided, including computer-executable instructions that, when executed by a processor, implement some or all of the steps of the method of the first or second aspect.

[0036] It is understood that the electronic device of the fifth aspect, the computer storage medium of the sixth aspect, or the computer program product of the seventh aspect provided above are all used to perform the methods provided in the first or second aspects. Therefore, the explanations or descriptions regarding the first aspect also apply to the fifth, sixth, and seventh aspects. Furthermore, the beneficial effects achievable by the fifth, sixth, and seventh aspects can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0037] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1a A schematic diagram of multiple compressed tiles for a texture data frame is shown; Figure 1b A schematic diagram of multiple rendered tiles for a texture data frame is shown; Figure 2 A schematic diagram illustrating a data prefetching method based on the storage of texture data frames is shown. Figure 3 A schematic diagram comparing texture data frames divided into rendered tiles and texture data frames divided into compressed tiles is shown. Figure 4 A schematic diagram of an example environment in which some embodiments of this disclosure can be implemented is shown; Figure 5 A flowchart is shown illustrating a process for processing a request to access target data according to some embodiments of the present disclosure; Figure 6 A schematic diagram of associated data determined based on target data according to some embodiments of the present disclosure is shown; Figure 7 A schematic diagram illustrating a record of recently accessed compressed tiles according to some embodiments of the present disclosure is shown; Figure 8 A schematic diagram of an algorithm for updating access history according to some embodiments of the present disclosure is shown; Figure 9 A flowchart illustrating an example process for prefetching data from a texture data frame according to some embodiments of the present disclosure is shown; Figure 10 A schematic diagram illustrates an example environment for prefetching texture data frames based on access requests from multiple GPUs, according to some embodiments of this disclosure. Figure 11 A schematic diagram of associated compressed blocks according to some embodiments of the present disclosure is shown; Figure 12A schematic block diagram of an apparatus for prefetching data from a texture data frame according to some embodiments of the present disclosure is shown; and Figure 13 A block diagram of a computing device capable of implementing several embodiments of the present disclosure is shown. Detailed Implementation

[0038] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0039] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0040] As briefly mentioned above, there is a need for an efficient and accurate method to prefetch data to improve the efficiency of accessing compression heads, thereby improving the efficiency of video and image processing. Currently, several prefetching schemes have been proposed to improve the efficiency of accessing compression heads.

[0041] First refer to Figure 1a and Figure 1b This section introduces the storage and rendering methods for texture data frames. As mentioned above, texture data frames can be stored as compressed data and a corresponding compressed header. When rendering a texture data frame, the compressed header can be accessed first, followed by the corresponding compressed data for rendering. Figure 1a A schematic diagram of multiple compressed tiles for a texture data frame is shown.

[0042] like Figure 1a As shown, the compression header of a texture data frame can be stored as multiple compressed tiles, such as compressed tiles 110-1 to 110-8. The size of a compressed tile can be, for example, 64 × 16 pixels. Depending on the granularity of the compression, each compressed tile may include one or more compression headers (also called compression header information). For example, compressed tile 110-1 may include compression headers 111-1 to 111-4.

[0043] The compressed head can be stored linearly. For example... Figure 1aAs shown, compression headers 111-1, 111-5, 111-6, and 111-7 can be stored at the same address in the same row of storage space. The addresses of compression headers within the same compression tile can be aligned based on the header stride of the compressed headers stored row by row. For example, compression headers 111-1, 111-2, 111-3, and 111-4 can be stored at addresses in different rows, and the corresponding addresses are aligned according to the header stride.

[0044] It should be understood that the data in a texture data frame can include data with different semantics, such as luminance data and chrominance data. Therefore, for each semantic, the texture data frame can be compressed into corresponding compressed data and a compression header. In other words, the storage device can store multiple compressed tiles for luminance data and multiple compressed tiles for chrominance data.

[0045] Figure 1b A schematic diagram of multiple rendered tiles for a texture data frame is shown. (For example...) Figure 1b As shown, a texture data frame can also be divided into multiple rendering tiles, such as rendering tiles 120-1 to 120-16. Rendering tiles can indicate the granularity used for rendering the texture data frame. In other words, when rendering a texture data frame, the compressed header and compressed data corresponding to a rendering tile can be accessed for rendering. The size of a rendering tile can be, for example, 32×32 pixels.

[0046] In some schemes, data can be prefetched based on the storage method of texture data frames. Figure 2 This diagram illustrates a data prefetching method based on texture data frames. As mentioned above, compressed headers can be stored row by row. In this case, compressed headers located in the same row or in a nearby row as the requested compressed header can be identified as the compressed headers associated with the requested compressed header, and these associated compressed headers can be prefetched into the HDR-Cache to improve the efficiency of accessing compressed headers.

[0047] like Figure 2 As shown, the associated compression headers, i.e., those predicted to be accessed later, can be determined by following the direction of the arrows. The address of the associated compression header can be determined by incrementing or decrementing the address of the requested compression header by a certain amount.

[0048] Depending on the specific implementation, one or more associated compressed headers can be prefetched. For example, if the requested compressed header is 210-1, compressed headers 210-2, 210-3, and 210-4 located in the same line 210 can be prefetched. In another example, compressed headers from multiple lines can be prefetched, such as those in lines 220, 230, and 240. In this way, by prefetching compressed headers that may be requested later, the efficiency of accessing compressed headers can be improved.

[0049] However, since the rendering and storage methods of texture data frames may be inconsistent, compressed headers located on the same or adjacent lines as the requested compressed header may not be requested for access within a certain period of time. Figure 3 A schematic diagram comparing texture data frame 310, divided into rendering tiles, and texture data frame 350, divided into compressed tiles, is shown. Figure 3 In the example, the rendered tile size is 32×32 pixels, the compressed tile size is 64×16 pixels, and each compressed tile corresponds to four compression headers. It should be understood that... Figure 3 The examples in this disclosure are illustrative only and do not constitute a limitation on the scope of this disclosure.

[0050] like Figure 3 As shown, texture data frames can be rendered in a zigzag pattern. In other words, compression heads and corresponding compressed data can be accessed in a zigzag pattern for rendering. For example, compression heads corresponding to rendering tiles 311, 312, 313, 314, 315, and 316 can be accessed sequentially. Specifically, compression heads 351 to 366 can be accessed sequentially, followed by compression heads 371 to 378.

[0051] In this example, prefetching compressed headers that are on the same line and / or in adjacent lines as the requested compressed header may be inappropriate. For instance, if the requested compressed header is 351 and compressed headers on the same line are prefetched into the HDR-Cache, then compressed header 391, located at the end of that line, will not be requested in a short period of time due to the zigzag rendering pattern. Thus, prefetching compressed headers according to the above scheme may reduce the HDR-Cache hit rate and consume HDR-Cache resources.

[0052] To at least partially address the aforementioned problems and other potential issues, various embodiments of this disclosure provide a data prefetching scheme. Generally, according to the various embodiments described herein, a request for target data of a texture data frame is first received, the request including an address for accessing the target data; based on the address and information indicating the rendering and storage methods of the texture data frame, a plurality of prefetch addresses are determined, associated data at the plurality of prefetch addresses being predicted to be accessed after the target data; and based on at least one of the plurality of prefetch addresses, at least a portion of the associated data is prefetched.

[0053] In this way, by considering both the rendering and storage methods of texture data frames, it is possible to more accurately prefetch subsequent data that may be accessed in association with the target data to be accessed, thereby improving the efficiency of prefetching texture data frames and the efficiency of video and image processing.

[0054] Various exemplary embodiments of this disclosure are described below with reference to the accompanying drawings.

[0055] Figure 4 A schematic diagram of an example environment 400 in which some embodiments of the present disclosure can be implemented is shown. Environment 400 may include a graphics processing unit, such as a GPU 410, for image and video processing. Environment 400 may also include a processor 420. Processor 420 may receive a request from GPU 410 for accessing data of a texture data frame in storage device 430. As described above, the data of the texture data frame may include compressed data obtained in a block compression manner and a corresponding compression header, and the compressed data and compression header may be stored in different portions of storage device 430. The data of the texture data frame may include compressed data and corresponding compression headers for different semantics. Storage device 430 may be a double data rate (DDR) memory or any other suitable storage device.

[0056] like Figure 4 As shown, GPU 410 can send request 411 to processor 420 for accessing data in a texture data frame. Processor 420 can process request 411 to generate request 412 corresponding to request 411. In some embodiments, the data in the texture data frame exists in a non-GPU-recognizable, non-native format. Processor 420 can implement a mapping from GPU addresses to the addresses of the texture data frame data through virtualization mapping. For example, request 412 corresponding to request 411 can be generated by decompressor 421 in processor 420.

[0057] The decompressor 421 can send a request 412 to a cache in the processor 420, such as a compressed header cache (HDR-Cache) 422. The control unit 423 in the cache can check whether the requested target data already exists. For example, the control unit 423 in the HDR-Cache 422 can check whether the requested compressed header already exists in the data memory 424. If the requested compressed header does not exist, the HDR-Cache 422 can send a request 413 for the compressed header to the storage device 430. The storage device 430 can return the requested compressed header 414 to the HDR-Cache 422. For example, the compressed header 414 can be stored in the data memory 424.

[0058] The compression header cache 422 can send a compression header 414 to the decompressor 421. The decompressor 421 can determine the requested compressed data based on the compression header 414 and send a request 415 for the compressed data to the storage device 430. The storage device 430 can return the requested compressed data 416 to the processor 420. Based on the compressed data 416, the processor 420 can return the requested texture data frame data 417 to the GPU 410.

[0059] In some embodiments, based on request 412, the compression head cache 422 may also generate one or more prefetch requests. Prefetch requests are used to prefetch compression heads predicted to be accessed after the requested compression head 414 into the compression head cache 422. For example, one or more prefetch requests may be generated by the prediction unit 425 in the compression head cache 422. Similarly, the compression head cache 422 may check whether the compression head requested by the prefetch request already exists in the data memory 424. If the compression head requested by the prefetch request does not exist, the compression head cache 422 may send a prefetch request 419 for that compression head to the storage device 430. For example, the prefetch request 419 may be sent by the control unit 423. The storage device 430 may return the requested compression head 431 to the compression head cache 422. For example, the compression head 431 may be stored in the data memory 424.

[0060] In this way, the associated compressed header 431, predicted to be accessed subsequently, can be prefetched into the compressed header cache 422. Thus, if the GPU 410 subsequently sends a new request for the compressed header 431, the processor 420 can directly use the compressed header 431 stored in the compressed header cache 422 to request the corresponding compressed data from the storage device 430, without first sending a request to the storage device 430 to access the compressed header 431. Therefore, using prefetch requests can improve the efficiency of accessing the compressed header, thereby improving the efficiency of video and image processing.

[0061] It should be understood that the foregoing description, using the example of accessing and prefetching the compressed header of texture data frames, illustrates an example environment for implementing embodiments of this disclosure. In some embodiments, the scheme for prefetching data to implement this disclosure may not involve... Figure 4 One or more modules in or including one or more other modules.

[0062] The following will refer to Figure 5 This describes the details of accessing target data and prefetching associated data based on requests to access target data. Figure 5 A flowchart of a process 500 for processing a request to access target data according to some embodiments of the present disclosure is shown. Process 500 can be performed by... Figure 4The compressed header cache 422 implementation is shown below. See below for reference. Figure 4 To describe process 500.

[0063] In box 501, a request for accessing target data is received. Examples of target data may include a compressed header. For example, a compressed header cache 422 may receive a request 412 for a compressed header sent by a decompressor 421. Alternatively or additionally, the target data may be any other suitable data of a texture data frame, such as uncompressed raw data.

[0064] In box 502, it is checked whether the target data is hit in the cache. For example, control unit 423 in the compression header cache 422 can check whether the compression header requested by request 412 is hit, that is, check whether the compression header requested by request 412 exists in data memory 424. Control unit 423 can determine whether the requested compression header exists in data memory 424 by checking the tag memory (not shown) in the compression header cache 422.

[0065] If a match is not found, in box 503, a request for the target data is sent to the storage device. For example, control unit 423 may send request 413 for the compression head to storage device 430.

[0066] In box 504, a prefetch request is generated. For example, prediction unit 425 in compressed header cache 422 can generate one or more prefetch requests based on request 412.

[0067] In box 505, a prefetch request enters the prefetch queue. Prefetch requests in the prefetch queue can be read by control unit 423 in a first-in, first-out manner.

[0068] In box 506, check if the prefetch queue is empty. For example, the control unit 423 can check if the prefetch queue is empty.

[0069] If the prefetch queue is empty, the process ends at box 507. For example, the process can end when all prefetch requests in the prefetch queue have been processed.

[0070] If the prefetch queue is not empty, then in box 508, read the prefetch requests in the prefetch queue. For example, control unit 423 can read the prefetch requests in the prefetch queue.

[0071] In box 509, it is checked whether the read prefetch request has been hit in the cache. For example, control unit 423 may check whether the compressed header requested by the prefetch request exists in data memory 424.

[0072] If a miss occurs, the prefetch request is sent in box 510. For example, control unit 423 may send prefetch request 419 to storage device 430 for prefetching the associated compressed header 431 from storage device 430 into data memory 424.

[0073] If a match is found, the prefetch request is not sent (i.e., the prefetch request is cancelled), and the process returns to box 506 to check again whether the prefetch queue is empty. For example, control unit 423 may send a cancellation signal to prediction unit 425 to cancel the prefetch request.

[0074] It should be understood that the above process 500 is merely exemplary. For example, the prediction unit 425, instead of the control unit 423, may send the prefetch request 419 to the storage device 430. For example, the control unit 423 may send a confirmation signal to the prediction unit 425 confirming the prefetch request or a cancellation signal to cancel the prefetch request. Based on the confirmation signal or cancellation signal, the prediction unit 425 may send the prefetch request 419 to the storage device 430.

[0075] The following section details how one or more prefetch requests are generated based on a request to access the target data. Each prefetch request includes a prefetch address for accessing data associated with the target data (e.g., the requested compressed header, also referred to herein as associated data). The associated data is predicted to be accessed after the target data.

[0076] According to embodiments of this disclosure, a request for accessing target data includes an address for accessing the target data. Based on this address, the target data can be retrieved from storage devices into a cache for processing. Additionally, the request also includes information associated with the rendering and storage of texture data frames. In other words, the request includes information indicating the rendering and storage methods of the texture data frames.

[0077] Figure 6 A schematic diagram of association data determined based on target data according to some embodiments of the present disclosure is shown. Figure 6 In this context, the compression header 611 can represent the target data requested for access.

[0078] In some embodiments, data corresponding to the same compressed tile as the target data requested for access can be identified as associated data. For example... Figure 6 As shown, compression heads 612, 613, and 614 corresponding to the same compressed block can be identified as associated data.

[0079] In these embodiments, the address of the associated data, i.e., the prefetch address, can be determined based on the address of the target data and information indicating the storage method of the texture data frame. Information indicating the storage method of the texture data frame may include the header stride of the compressed header stored row by row, the number of compressed headers in a compressed tile, and the location of the target data within the compressed tile. The location of the target data within the compressed tile can be indicated using segment numbers (segids). The segment numbers of the compressed headers from top to bottom within the same compressed tile can be 0, 1, 2, and 3, respectively, meaning the segid values ​​are 0, 1, 2, and 3.

[0080] Based on the address and segment number of the target data (segid = SegmentID), the address of the first compression header (i.e., the compression header with segid = 0) in the compressed tile containing the target data can be determined to be HDR_Addr. Based on HDR_Addr, the address of the associated data can be determined to be HDR_Addr + segid. header_stride, where the value of segid can be 0, 1, 2, 3, etc.

[0081] Alternatively, associated data can be determined based on the rendered tiles and rendered paths corresponding to the target data. Associated data may include data corresponding to one or more rendered tiles on the rendered path.

[0082] In these embodiments, the address of the associated data can be determined based on the address of the target data and information indicating the rendering and storage method of the texture data frame. The information may include the location of the compressed tile corresponding to the target data within the texture data frame. For example, the information may include the coordinates of the compressed tile corresponding to the target data.

[0083] like Figure 6 As shown, compressed tiles 610 and 620 correspond to four rendering tiles on the zigzag rendering path (the size of the compressed tile is 64×32 pixels, and the size of the rendered tile is 32×32 pixels). Based on the address HDR_Addr of the compressed header 611, the address of the compressed header 621 can be determined to be HDR_Addr + 4. header_stride; the address of the compressed header 622 is HDR_Addr + 5. header_stride; the address of the compressed header 623 is HDR_Addr + 6. header_stride; the address of the compressed header 624 is HDR_Addr + 7. header_stride.

[0084] Alternatively or additionally, chroma data or luminance data corresponding to the target data (and the associated data determined in the above embodiments, such as compression headers 612, 613, 614, 621, 622, 623, 624) may be identified as associated data. In these embodiments, information indicating the storage and rendering methods of the texture data frame may include address translation information indicating the relationship between the addresses of luminance data and chroma data. For example, the address translation information may include the base address (luma_base_addr) of the luminance data and / or the base address (chroma_base_addr) of the chroma data.

[0085] The address of the associated data can be determined based on the address and address translation information of the target data (and the associated data determined in the above embodiments). For example, based on the address HDR_Addr of the compression header 611 for luminance data, the address of the corresponding compression header 631 for chroma data can be determined to be HDR_Addr + chroma_base_addr. The address of the compression header 632 corresponding to the compression header 612 for chroma data can also be determined to be HDR_Addr + chroma_base_addr + header_stride.

[0086] In some embodiments, the shapes of rendered tiles and compressed tiles can be determined based on information indicating the rendering and storage method of the texture data frame. Based on the shapes of the rendered tiles and compressed tiles, a minimum union of the rendered tiles and compressed tiles can be determined. The minimum union is a region containing an integer number of rendered tiles and an integer number of compressed tiles. Associated data can be determined within this minimum union.

[0087] like Figure 6 As shown, with a compressed tile size of 64×32 pixels and a rendered tile size of 32×32 pixels, the minimum union can be region 630. Only one or more compressed heads within region 630 can be identified as associated data. This avoids prefetching compressed heads that are far from the requested compressed head, thus improving the efficiency of data prefetching.

[0088] In some embodiments, generated prefetch requests can be filtered based on access history. Filtered prefetch requests can be sent to a prefetch queue for later processing to improve the efficiency of prefetching data. For example, in Figure 5 In the process 500 shown, the prefetch requests can be filtered before block 505, and the filtered prefetch requests can be sent to the prefetch queue.

[0089] Access history can include records of the most recently accessed compressed tiles before the target data was accessed. A most recently accessed compressed tile is one that includes the most recently accessed data. The threshold for the number of most recently accessed compressed tiles (i.e., the number of records) included in the access history can be determined based on the number of compressed tiles covered by a window rendered simultaneously by the GPU. For example, the access history can include 16 to 32 most recently accessed compressed tiles.

[0090] For each previously accessed compressed tile, the record may include prefetch information. Prefetch information indicates whether each compressed header in the compressed tile has been prefetched into the cache. The record may also include access information, indicating whether each compressed header in the compressed tile has been accessed. The record may also include time information, indicating when or in what order the compressed tile was accessed. The record may also include fields indicating the attributes of the data.

[0091] Figure 7 A schematic diagram of a record of recently accessed compressed tiles according to some embodiments of the present disclosure is shown.

[0092] like Figure 7 As shown, for each compressed tile (e.g., compressed tile A or compressed tile B), prefetch information can be represented using a prefetch vector such as [p1, p2, p3, p4], where p1, p2, p3, and p4 indicate whether the first, second, third, and fourth compression heads in the compressed tile are prefetched, respectively. The number of elements in the prefetch vector depends on the number of compression heads in the compressed tile. The element value of the compression head corresponding to the prefetch request can be 1 to indicate that the compression head is prefetched. The default element value of the compression head can be zero to indicate that the compression head is not prefetched.

[0093] Similarly, for each compressed tile, access information can be represented using an access vector such as [v1, v2, v3, v4], where v1, v2, v3, and v4 indicate whether the first, second, third, and fourth compressed heads in the compressed tile have been accessed, respectively. The number of elements in the access vector depends on the number of compressed heads in the compressed tile. The element value of the compressed head corresponding to the access request can be 1 to indicate that the compressed head has been accessed. The default element value of the compressed head can be zero to indicate that the compressed head has not been accessed.

[0094] In some embodiments, filtering prefetch requests based on access history may include determining target associated data based on the access history and identifying the prefetch request corresponding to the target associated data as a filtered prefetch request. Specifically, a target compressed tile associated with the currently requested compressed tile may be identified in the most recently accessed compressed tiles in the access history, and the target associated data may be determined based on the access information of the target compressed tile. Data with a corresponding location in the currently requested compressed tile may be identified as target associated data based on the location of the accessed compressed head in the target compressed tile.

[0095] In other words, based on the location of the actually accessed compressed headers in the target compressed tile, it is possible to predict which compressed headers in the currently requested compressed tile are likely to be accessed, and these potentially accessed compressed headers can be prefetched into the cache to improve the efficiency of accessing compressed headers. For example, compressed headers in the currently requested compressed tile that have the same segment number as the accessed compressed headers in the target compressed tile can be identified as target associated data.

[0096] In some embodiments, the target compressed tile in the access history can be determined based on its distance from the currently requested compressed tile. For example, the compressed tile that is spatially the nearest or second nearest neighbor of the currently requested compressed tile can be identified as the target compressed tile. Hamming distance can be used to determine the nearest or second nearest neighbor compressed tiles.

[0097] For example, refer to Figure 6 If compressed head 611 is the target data currently requested for access, and compressed tile 640 is the nearest neighbor of compressed tile 610 in the access history, then compressed heads 613 and 614 in compressed tile 610 can be identified as target associated data if the records for compressed tile 640 in the access history indicate that compressed heads 643 and 644 were previously accessed. In other words, if the generated prefetch requests include requests for compressed heads 612, 613, and 614, the prefetch request for compressed head 612 can be discarded.

[0098] Alternatively or concurrently, target compressed tiles in the access history can be determined based on predefined association rules. These predefined association rules can be determined based on rendering and / or storage methods. For example, a compressed tile that is horizontally separated from the currently requested compressed tile by one compressed tile can be identified as the target compressed tile.

[0099] Alternatively, the target compressed tile in the access history can be determined based on the access time of the most recently accessed compressed tile in the access history. For example, the most recently accessed compressed tile can be identified as the target compressed tile. Another example is that the most recently accessed compressed tile among spatially nearest compressed tiles can be identified as the target compressed tile.

[0100] In some embodiments, the access history can be updated based on received access requests. The access history may include a predetermined number of records (or entries), and each record corresponds to a recently accessed compressed tile. Figure 8 A schematic diagram of an algorithm for updating access history according to some embodiments of the present disclosure is shown.

[0101] like Figure 8 As shown, for each access request (e.g., Figure 4 In access request 412, the access history can be checked to see if a record exists for a compressed tile that includes a compressed header corresponding to the access request. If a record for the compressed tile requested for access already exists, the element value in the access vector for that compressed tile corresponding to the requested compressed header can be updated to indicate that the compressed header has been accessed. For example, the corresponding element value can be updated to 1.

[0102] If the requested compressed tile does not exist in the access history, and the number of compressed tiles included in the access history does not reach a predetermined threshold, a new entry corresponding to the requested compressed tile can be added to the access history table. The element value corresponding to the requested compressed header in the access vector for that compressed tile can be set to indicate that the compressed header has been accessed. The prefetch vector for that compressed tile can also be set based on the prefetch request corresponding to the access request.

[0103] If the requested compressed tile does not exist in the access history, and the number of compressed tiles in the access history has reached a predetermined threshold, the earliest accessed compressed tile (tid_b0) entry in the table can be deleted, and a new entry corresponding to the requested compressed tile can be added. In other words, the record of the earliest accessed compressed tile can be updated to the record of the currently requested compressed tile.

[0104] The element value corresponding to the requested compressed header in the access vector for this compressed tile can be set to indicate that the compressed header has been accessed. For example, the corresponding element value can be set to 1. Furthermore, the target compressed tile (tid_a0) associated with the currently accessed compressed tile can be identified in the most recently accessed compressed tiles in the access history, and the prefetch vector for that currently accessed compressed tile can be set as the access vector for that target compressed tile. It should be understood that... Figure 8The example algorithms shown only illustrate the case where the target compressed tile is the spatially nearest neighbor compressed tile. As mentioned above, the target compressed tile can also be any other suitable compressed tile.

[0105] In this way, since the prefetch vector of the compressed tile in the access history is determined only by the generated prefetch request in the initial period (i.e. when the number of entries in the table has not reached the threshold), and is determined by the access information of the target compressed tile after the number of entries in the table has reached the threshold, the prefetch information of the compressed tile to be accessed can indicate the inherent pattern of the access compression head to a certain extent, and can be used to filter the generated prefetch requests.

[0106] For each prefetch request generated based on the current access request, the access history can be checked to see if a record exists for a compressed tile that includes a compressed header corresponding to the prefetch request. If the record does not exist in the access history, the prefetch request can be filtered out, i.e., it is not sent to the prefetch queue. If the record exists in the access history, the element value in the prefetch vector for that compressed tile that corresponds to the compressed header of the prefetch request can be used to determine whether to send the prefetch request to the prefetch queue. If the element value indicates that the compressed header is prefetched, the prefetch request can be sent to the prefetch queue. If the element value indicates that the compressed header is not prefetched, the prefetch request can be filtered out, i.e., it is not sent to the prefetch queue. In this way, potentially accessed data can be prefetched more accurately, thereby improving the efficiency of data access.

[0107] Figure 9 A flowchart illustrating an example process 900 for prefetching texture data frames according to some embodiments of the present disclosure is shown. Process 900 can be implemented by any suitable device with computing power. For example, it can be implemented by... Figure 4 The compression header cache is 422.

[0108] In box 910, a request for target data of a texture data frame is received, the request including an address for accessing the target data. The target data may be a specific compressed header or other type of data from the texture data frame.

[0109] In box 920, multiple prefetch addresses are determined based on information about the address and the rendering and storage methods of the texture data frame. The associated data at these multiple prefetch addresses is predicted to be accessed after the target data.

[0110] In some embodiments, the information includes at least one of the following: the size of a rendered tile indicating the rendering granularity of the texture data frame, the rendering path, the size of a compressed tile indicating the storage granularity of the texture data frame, the stride of a compressed header stored row by row, the coordinates of a compressed tile containing the target data, the location of the target data in the compressed tile, and address translation information indicating the relationship between the luminance data base address and the chrominance data base address.

[0111] In some embodiments, the associated data includes at least one of the following: chroma data or luminance data corresponding to the target data; data corresponding to the same rendering tile as the target data; and data of other rendering tiles determined based on the rendering tile and rendering path corresponding to the target data. In this way, as much data as possible that may be accessed subsequently can be prefetched, thereby improving the efficiency of prefetching texture data frames and the efficiency of video and image processing.

[0112] In some embodiments, the method further includes filtering the plurality of prefetch addresses based on access history to determine the at least one prefetch address, wherein the access history includes records of recently accessed compressed tiles, the recently accessed compressed tiles comprising historical data accessed prior to the target data. In this manner, potentially accessed data can be prefetched more accurately based on patterns of requested data access, thereby improving the efficiency of data access.

[0113] In some embodiments, the record includes prefetch information and access information, the prefetch information indicating segments that have been prefetched in the compressed tile, and the access information indicating segments that have been accessed in the compressed tile.

[0114] In some embodiments, the texture data frame is divided into multiple compressed tiles, and filtering the multiple prefetch addresses based on the access history includes: determining a current compressed tile containing the target data among the multiple compressed tiles; determining a target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles; and filtering the multiple prefetch addresses based on the access information of the target compressed tile.

[0115] In some embodiments, filtering the plurality of prefetch addresses based on the access information of the target compressed map includes: determining, based on the access information of the target compressed map, a segment that has been accessed in the target compressed map; determining a target segment in the current compressed map corresponding to the segment that has been accessed in the target compressed map; and determining an address among the plurality of prefetch addresses corresponding to the target segment as the at least one prefetch address.

[0116] In some embodiments, the method further includes: creating a record of the current compressed tile, the record of the current compressed tile including prefetch information indicating the target segment and access information indicating the segment containing the target data; removing the record of the earliest accessed compressed tile from the recently accessed compressed tiles from the access history; and adding the record of the current compressed tile to the access history to update the access history.

[0117] In some embodiments, determining a target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles includes determining the target compressed tile based on at least one of the following: distance from the current compressed tile; a predetermined association rule; and the time when the most recently accessed compressed tile was accessed.

[0118] In some embodiments, the method further includes: determining the number of recently accessed compressed tiles in the access history based on the size of the rendering window and the compressed tile.

[0119] In box 930, at least a portion of the associated data is prefetched based on at least one of a plurality of prefetch addresses.

[0120] In some embodiments, prefetching at least a portion of the associated data includes: in response to a cache miss of the at least a portion of the associated data, retrieving the at least a portion of the associated data from external memory into the cache.

[0121] The above text refers to Figures 1 to 12. Figure 9 The process of prefetching texture data frames is described. According to the scheme of this disclosure, by using both the storage method and the rendering method based on texture data frames, the accuracy of predicting data that may be accessed subsequently can be improved, thereby improving the efficiency of data prefetching and thus improving the efficiency of data access.

[0122] In some embodiments, the above prefetching scheme can be applied to multi-GPU scenarios. Figure 10 A schematic diagram of an example environment 1000 is shown, illustrating access to data of a texture data frame based on access requests from multiple GPUs according to some embodiments of this disclosure. Figure 10 As shown, environment 1000 may include multiple GPUs, such as GPUs 1011, 1012, 1013, and 1014. Each GPU can send its own access request to access data in the corresponding texture data frame. For example, GPU 1011 can send access request 1021, GPU 1012 can send access request 1022, GPU 1013 can send access request 1023, and GPU 1014 can send access request 1024.

[0123] Environment 1000 also includes a routing unit 1030 for processing multiple access requests from multiple GPUs. The routing unit 1030 can divide the received multiple access requests into at least one group of access requests based on the storage and rendering methods of the texture data frames, and route each group of access requests to a corresponding processor (e.g., processors 1041, 1042, 1043, or 1044) to utilize that processor to process the group of access requests.

[0124] The request received by each processor from routing unit 1030 can be one or more access requests sent by the GPU to routing unit 1030. For example, routing unit 1030 can route request 1051 to processor 1041; routing unit 1030 can route request 1052 to processor 1042; routing unit 1030 can route request 1053 to processor 1043; and routing unit 1030 can route request 1054 to processor 1044. Request 1051 can be one of access requests 1021, 1022, 1023, and 1024.

[0125] The processor can be with Figure 4 The processor 420 shown is the same as or similar to the processor described above. The processor can generate an access request for a compressed header based on a received request (e.g., request 1051, 1052, 1053, or 1054) and generate a prefetch request based on the request to access the compressed header. The processor can retrieve the requested compressed header from storage based on the request to access the compressed header and access the corresponding compressed data based on the information indicated by the compressed header. The processor can also retrieve the associated compressed header from storage into a cache based on the prefetch request to improve the efficiency of data access. The processor can determine the data of the requested texture data frame based on the compressed data retrieved from storage.

[0126] The processor can return the data of the texture data frame requested for access (e.g., 1061, 1062, 1063, 1064) to the routing unit 1030 (e.g., requests 1051, 1052, 1053, 1054). The routing unit 1030 can return the data of the texture data frame corresponding to the received requests (1021, 1022, 1023, 1024) (e.g., 1071, 1072, 1073, 1074 respectively) to the GPU for rendering the texture data frame or performing other processing.

[0127] In some embodiments, the routing unit 1030 may divide multiple compressed tiles corresponding to the received access request into at least one set of associated compressed tiles based on the rendering and storage methods of the texture data frame, and may route access requests for the same set of associated compressed tiles to the same processor.

[0128] For example, routing unit 1030 can route access requests for the same set of associated compressed tiles to the same processor. Thus, prefetch requests generated in the same processor can be similar. For instance, in the same processor, the compressed header prefetched for the first access request might also be the compressed header to be prefetched for the second access request. This reduces prefetching operations and improves data processing efficiency. In another example, the compressed header prefetched for the first access request might be the compressed header to be accessed by the second access request. This improves the efficiency of accessing compressed headers.

[0129] In some embodiments, the multiple compressed tiles corresponding to the received multiple access requests can be divided into at least one group of associated compressed tiles. For example, the routing unit 1030 can determine compressed tiles corresponding to the same rendering tile as associated compressed tiles. Alternatively, compressed tiles corresponding to the same rendering path can be determined as associated compressed tiles. The routing unit 1030 can determine associated compressed tiles based on the location of the compressed tile requested for access.

[0130] Figure 11 A schematic diagram of associated compressed blocks according to some embodiments of the present disclosure is shown. Figure 11 In the example, the compressed tile size is 64×16 pixels, the rendered tile size is 32×32 pixels, and the GPU renders in a zigzag pattern. The location of the compressed tile can be represented by coordinates. For example, Tile (0,0) represents the compressed tile located in row 0 and column 0.

[0131] exist Figure 11 In the example shown, associated compressed tiles can be determined based on the size of the prefetch range. For example, if the prefetch range is the compressed tiles on the small zigzag path during GPU rendering, then n can determine the Tile (0,0), Tile (0,1), Tile (0,2), and Tile (0,3) corresponding to the four zigzag rendered tiles as associated compressed tiles.

[0132] If the prefetch range is the compressed tiles on the large zigzag path during GPU rendering, then n can identify the Tile (0,0) to Tile (0,7) and Tile (1,0) to Tile (1,7) corresponding to the 16 zigzag rendered tiles as associated compressed tiles.

[0133] Depending on the prefetch range, Tile (0,0) and Tile (0,1) corresponding to the same rendered tile can also be identified as associated compressed tiles. Alternatively, Tile (0,0), Tile (0,1), Tile (0,2), Tile (0,3), Tile (1,0), Tile (1,1), Tile (1,2), and Tile (1,3) corresponding to eight rendered tiles in a semi-zigzag pattern can be identified as associated compressed tiles.

[0134] In this way, by routing access requests for a set of associated compressed tiles to the same processor, the efficiency of accessing texture data frames can be improved.

[0135] Example devices and equipment Figure 12 A block diagram of an apparatus 1200 for prefetching texture data frames according to an embodiment of the present disclosure is shown. The apparatus 1200 may include multiple modules for performing, for example... Figure 9 The corresponding steps of process 900 discussed in the text. For example... Figure 12 As shown, the apparatus 1200 includes a request receiving unit 1210 configured to receive a request for target data of a texture data frame, the request including an address for accessing the target data; a prefetch address determining unit 1220 configured to determine a plurality of prefetch addresses based on the address and information indicating the rendering mode and storage mode of the texture data frame, wherein associated data at the plurality of prefetch addresses is predicted to be accessed after the target data; and a prefetch unit 1230 configured to prefetch at least a portion of the associated data based on at least one of the plurality of prefetch addresses.

[0136] In some embodiments, the information includes at least one of the following: the size of a rendered tile indicating the rendering granularity of the texture data frame, the rendering path, the size of a compressed tile indicating the storage granularity of the texture data frame, the stride of a compressed header stored row by row, the coordinates of a compressed tile containing the target data, the location of the target data in the compressed tile, and address translation information indicating the relationship between the luminance data base address and the chrominance data base address.

[0137] In some embodiments, the associated data includes at least one of the following: chroma data or luminance data corresponding to the target data; data corresponding to the same rendering tile as the target data; and data of other rendering tiles determined based on the rendering tile and rendering path corresponding to the target data.

[0138] In some embodiments, the apparatus 1200 further includes a filtering unit configured to filter the plurality of prefetch addresses based on access history to determine the at least one prefetch address, wherein the access history includes a record of recently accessed compressed tiles, the recently accessed compressed tiles comprising historical data accessed prior to the target data.

[0139] In some embodiments, the record includes prefetch information and access information, the prefetch information indicating segments that have been prefetched in the compressed tile, and the access information indicating segments that have been accessed in the compressed tile.

[0140] In some embodiments, the texture data frame is divided into a plurality of compressed tiles, and the filtering unit is further configured to: determine a current compressed tile containing the target data among the plurality of compressed tiles; determine a target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles; and filter the plurality of prefetch addresses based on the access information of the target compressed tile.

[0141] In some embodiments, the filtering unit is further configured to: determine the segment that has been accessed in the target compressed block based on the access information of the target compressed block; determine the target segment in the current compressed block that corresponds to the segment that has been accessed in the target compressed block; and determine the address corresponding to the target segment among the plurality of prefetch addresses as the at least one prefetch address.

[0142] In some embodiments, the apparatus 1200 further includes an access history update unit configured to: create a record of the current compressed tile, the record of the current compressed tile including prefetch information indicating the target segment and access information indicating the segment containing the target data; remove the record of the earliest accessed compressed tile from the recently accessed compressed tiles from the access history; and add the record of the current compressed tile to the access history to update the access history.

[0143] In some embodiments, the filtering unit is configured to determine the target compressed tile based on at least one of the following: distance to the current compressed tile; a predetermined association rule; and the time when the most recently accessed compressed tile was accessed.

[0144] In some embodiments, the prefetch unit 1230 is further configured to: in response to a cache miss of at least a portion of the associated data, retrieve the at least a portion of the associated data from a memory outside the cache back into the cache.

[0145] In some embodiments, the apparatus 1200 further includes an access history maintenance unit configured to determine the number of recently accessed compressed tiles in the access history based on the size of the rendering window and the compressed tiles.

[0146] Embodiments of this disclosure also provide an apparatus for accessing data in a texture data frame, comprising: an access request receiving unit configured to receive a plurality of access requests for the texture data frame from a plurality of graphics processors; a grouping unit configured to divide the plurality of access requests into at least one group of access requests based on a rendering mode and a storage mode of the texture data frame; and a processing unit configured to process the group of access requests using a processor corresponding to each of the at least one group of access requests, wherein processing the group of access requests includes, for each of the group of access requests: determining, based on the access request, a request for target data, the request including an address for accessing the target data; determining, based on the address and information indicating the rendering mode and the storage mode of the texture data frame, a plurality of prefetch addresses, the associated data at the plurality of prefetch addresses being predicted to be accessed after the target data; and prefetching at least a portion of the associated data based on at least one of the plurality of prefetch addresses.

[0147] In some embodiments, the grouping unit is further configured to: divide the plurality of compressed tiles into at least one group of associated compressed tiles based on the location of the plurality of compressed tiles corresponding to the plurality of access requests and the rendering path corresponding to the plurality of access requests; and divide the plurality of access requests into the at least one group of access requests, wherein each group of access requests corresponds to a corresponding group of associated compressed tiles in the at least one group of associated compressed tiles.

[0148] Figure 13 A schematic block diagram of an example device 1300 that can be used to implement embodiments of the present disclosure is shown. Device 1300 can be used to implement apparatus 1200. As shown, device 1300 includes a computing unit 1301 that can perform various appropriate actions and processes according to computer program instructions stored in random access memory (RAM) 1303 and / or read-only memory (ROM) 1302 or computer program instructions loaded from storage unit 1308 into RAM 1303 and / or ROM 1302. Various programs and data required for the operation of device 1300 may also be stored in RAM 1303 and / or ROM 1302. The computing unit 1301 and RAM 1303 and / or ROM 1302 are connected to each other via bus 1304. Input / output (I / O) interface 1305 is also connected to bus 1304.

[0149] Multiple components in device 1300 are connected to I / O interface 1305, including: input unit 1306, such as keyboard, mouse, etc.; output unit 1307, such as various types of monitors, speakers, etc.; storage unit 1308, such as disk, optical disk, etc.; and communication unit 1309, such as network card, modem, wireless transceiver, etc. Communication unit 1309 allows device 1300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0150] The computing unit 1301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1301 performs the various methods and processes described above, such as process 900. For example, in some embodiments, process 900 may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1308. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1300 via RAM and / or ROM and / or communication unit 1309. When the computer program is loaded into RAM and / or ROM and executed by the computing unit 1301, one or more steps of process 900 described above may be performed. Alternatively, in other embodiments, the computing unit 1301 may be configured to perform process 900 by any other suitable means (e.g., by means of firmware).

[0151] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a server or terminal, they generate all or part of the processes or functions described in the embodiments of this application. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic cable, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to the server or terminal, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, and magnetic tape), an optical medium (e.g., digital video disk (DVD), etc.), or a semiconductor medium (e.g., solid-state drive, etc.).

[0152] Furthermore, although the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0153] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for prefetching data from a texture data frame, comprising: Receive a request for target data of a texture data frame, the request including an address for accessing the target data; Based on the address and information indicating the rendering and storage methods of the texture data frame, multiple prefetch addresses are determined, and the associated data at the multiple prefetch addresses is predicted to be accessed after the target data; Based on at least one of the plurality of prefetch addresses, prefetch at least a portion of the associated data from the associated data; as well as The plurality of prefetch addresses are filtered based on access history to determine the at least one prefetch address, wherein the access history includes records of recently accessed compressed tiles, which contain historical data accessed before the target data.

2. The method of claim 1, wherein the information includes at least one of the following: The rendering granularity of the texture data frame is indicated by the size of the rendering tile, the rendering path, the storage granularity of the texture data frame by the size of the compressed tile, the stride of the compressed header stored in rows, the coordinates of the compressed tile containing the target data, the location of the target data in the compressed tile, and the address translation information indicating the relationship between the luminance data base address and the chrominance data base address.

3. The method of claim 2, wherein the associated data includes at least one of the following: The chromaticity data or luminance data corresponding to the target data; Data corresponding to the same rendered tile as the target data; and Data for other rendering tiles determined based on the rendering tiles and rendering paths corresponding to the target data.

4. The method of claim 1, wherein the record includes prefetch information and access information, the prefetch information indicating segments that have been prefetched in the compressed tile, and the access information indicating segments that have been accessed in the compressed tile.

5. The method of claim 4, wherein the texture data frame is divided into multiple compressed tiles, and filtering the multiple prefetch addresses based on the access history includes: Determine the current compressed tile containing the target data from the plurality of compressed tiles; Identify the target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles; as well as The multiple prefetch addresses are filtered based on the access information of the target compressed map.

6. The method of claim 5, wherein filtering the plurality of prefetch addresses based on the access information of the target compressed map includes: Based on the access information of the target compressed map block, determine the segments that have been accessed in the target compressed map block; Determine the target segment in the current compressed block that corresponds to the segment that has been visited in the target compressed block; as well as The address corresponding to the target segment among the plurality of prefetch addresses is determined as the at least one prefetch address.

7. The method according to claim 6, further comprising: Create a record for the current compressed tile, the record for the current compressed tile including prefetch information indicating the target segment and access information indicating the segment containing the target data; Remove the record of the earliest accessed compressed tile from the recently accessed compressed tile list in the access history; and Add the record of the current compressed tile to the access history to update the access history.

8. The method according to any one of claims 5 to 7, wherein determining the target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles comprises determining the target compressed tile based on at least one of the following: Distance to the currently compressed tile; Pre-defined association rules; and The time when the most recently accessed compressed tile was accessed.

9. The method according to any one of claims 1 to 7, wherein pre-fetching at least a portion of the associated data comprises: In response to a cache miss of at least a portion of the associated data, the at least a portion of the associated data is retrieved from external memory into the cache.

10. The method according to any one of claims 1 to 7, further comprising: Based on the size of the rendering window and the compressed tile, the number of the most recently accessed compressed tiles in the access history is determined.

11. A method for accessing data of a texture data frame, comprising: Receive multiple access requests for texture data frames from multiple graphics processors; Based on the rendering and storage methods of the texture data frames, the multiple access requests are divided into at least one group of access requests; as well as The set of access requests is processed using a processor corresponding to each of the at least one set of access requests, wherein processing the set of access requests includes processing each access request in the set of access requests: Based on the access request, a request for target data is determined, the request including an address for accessing the target data; Based on the address and information indicating the rendering method and storage method of the texture data frame, multiple prefetch addresses are determined, and the associated data at the multiple prefetch addresses is predicted to be accessed after the target data; as well as Based on at least one of the plurality of prefetch addresses, at least a portion of the associated data is prefetched from the associated data.

12. The method of claim 11, wherein dividing the plurality of access requests into at least one group of access requests based on the rendering and storage methods of the texture data frame includes: Based on the location of multiple compressed tiles corresponding to the multiple access requests and the rendering path corresponding to the multiple access requests, the multiple compressed tiles are divided into at least one group of associated compressed tiles; as well as The multiple access requests are divided into at least one group of access requests, and each group of access requests corresponds to a corresponding group of associated compressed blocks in the at least one group of associated compressed blocks.

13. An apparatus for prefetching data from a texture data frame, comprising: The request receiving unit is configured to receive a request for target data of a texture data frame, the request including an address for accessing the target data; The prefetch address determination unit is configured to determine multiple prefetch addresses based on the address and information indicating the rendering method and storage method of the texture data frame, wherein the associated data at the multiple prefetch addresses is predicted to be accessed after the target data; The prefetch unit is configured to prefetch at least a portion of the associated data based on at least one of the plurality of prefetch addresses; as well as A filtering unit is configured to filter the plurality of prefetch addresses based on access history to determine at least one prefetch address, wherein the access history includes records of recently accessed compressed tiles, the recently accessed compressed tiles being included in historical data accessed before the target data.

14. The apparatus of claim 13, wherein the information includes at least one of the following: The rendering granularity of the texture data frame is indicated by the size of the rendering tile, the rendering path, the storage granularity of the texture data frame by the size of the compressed tile, the stride of the compressed header stored in rows, the coordinates of the compressed tile containing the target data, the location of the target data in the compressed tile, and the address translation information indicating the relationship between the luminance data base address and the chrominance data base address.

15. The apparatus of claim 14, wherein the associated data comprises at least one of the following: The chromaticity data or luminance data corresponding to the target data; Data corresponding to the same rendered tile as the target data; and Data for other rendering tiles determined based on the rendering tiles and rendering paths corresponding to the target data.

16. The apparatus of claim 14, wherein the record includes prefetch information and access information, the prefetch information indicating segments that have been prefetched in the compressed tile, and the access information indicating segments that have been accessed in the compressed tile.

17. The apparatus of claim 16, wherein the texture data frame is divided into a plurality of compressed tiles, and the filtering unit is further configured to: Determine the current compressed tile containing the target data from the plurality of compressed tiles; Identify the target compressed tile associated with the current compressed tile among the most recently accessed compressed tiles; as well as The multiple prefetch addresses are filtered based on the access information of the target compressed map.

18. The apparatus of claim 17, wherein the filtering unit is further configured to: Based on the access information of the target compressed map block, determine the segments that have been accessed in the target compressed map block; Determine the target segment in the current compressed block that corresponds to the segment already accessed in the target compressed block; and The address corresponding to the target segment among the plurality of prefetch addresses is determined as the at least one prefetch address.

19. The apparatus of claim 18, further comprising an access history update unit, the access history update unit being configured to: Create a record for the current compressed tile, the record for the current compressed tile including prefetch information indicating the target segment and access information indicating the segment containing the target data; Remove the record of the earliest accessed compressed tile from the recently accessed compressed tile list in the access history; and Add the record of the current compressed tile to the access history to update the access history.

20. The apparatus according to any one of claims 17 to 19, wherein the filtering unit is configured to determine the target compressed tile based on at least one of the following: Distance to the currently compressed tile; Pre-defined association rules; and The time when the most recently accessed compressed tile was accessed.

21. The apparatus according to any one of claims 13 to 19, wherein the prefetch unit is further configured to: In response to a cache miss of at least a portion of the associated data, the at least a portion of the associated data is retrieved from external memory into the cache.

22. The apparatus according to any one of claims 13 to 19, further comprising an access history maintenance unit, the access history maintenance unit being configured to: Based on the size of the rendering window and the compressed tile, the number of the most recently accessed compressed tiles in the access history is determined.

23. An apparatus for accessing data of a texture data frame, comprising: The access request receiving unit is configured to receive multiple access requests for texture data frames from multiple graphics processors; The grouping unit is configured to divide the multiple access requests into at least one group of access requests based on the rendering and storage methods of the texture data frame; as well as A processing unit is configured to process a set of access requests using a processor corresponding to each of the at least one set of access requests, wherein processing the set of access requests includes processing each access request in the set of access requests: Based on the access request, a request for target data is determined, the request including an address for accessing the target data; Based on the address and information indicating the rendering method and storage method of the texture data frame, multiple prefetch addresses are determined, and the associated data at the multiple prefetch addresses is predicted to be accessed after the target data; as well as Based on at least one of the plurality of prefetch addresses, at least a portion of the associated data is prefetched from the associated data.

24. The apparatus of claim 23, wherein the grouping unit is further configured to: Based on the location of multiple compressed tiles corresponding to the multiple access requests and the rendering paths corresponding to the multiple access requests, the multiple compressed tiles are divided into at least one group of associated compressed tiles; and The multiple access requests are divided into at least one group of access requests, and each group of access requests corresponds to a corresponding group of associated compressed blocks in the at least one group of associated compressed blocks.

25. An electronic device, comprising: At least one computing unit; At least one memory coupled to the at least one computing unit and storing instructions for execution by the at least one computing unit, the instructions, when executed by the at least one computing unit, causing the electronic device to perform the method according to any one of claims 1-12.

26. A computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the method according to any one of claims 1-12.

27. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method according to any one of claims 1-12.

Images