Instruction generation method and device, equipment, storage medium and program product

Abstract

This disclosure provides a method for generating instructions for a graphics processor playback tool, an apparatus for generating instructions for a graphics processor playback tool, a computer device, a computer-readable storage medium, and a computer program product. The method includes: performing block-level filtering on currently used GPU buffer data based on block size to remove data blocks whose content has not changed in the GPU buffer data, obtaining data blocks to be processed; performing sub-block-level filtering on the data blocks to be processed based on sub-block size to remove sub-data blocks whose content has not changed in the data blocks to be processed, obtaining differential sub-data blocks; generating update instructions based on the differential sub-data blocks; the update instructions are used to update the content of the differential sub-data blocks in the GPU buffer data.

Description

Technical Field

[0001] This disclosure relates to, but is not limited to, the field of computer technology, and in particular to a method for generating instructions for a graphics processor playback tool, an apparatus for generating instructions for a graphics processor playback tool, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Traditional Graphics Processing Unit (GPU) playback tools generate update instructions with a fixed granularity. For example, the current frame buffer (cur_buf) file is divided into multiple data blocks based on a fixed block size, and update instructions are generated by comparing these multiple data blocks. This fixed-granularity update instruction generation method cannot reflect the actual distribution of data changes, resulting in a large number of redundant update instructions in sparse modification scenarios. This leads to increased storage size, transmission overhead, and playback overhead. Summary of the Invention

[0003] In view of the above, the present disclosure provides at least one instruction generation method for a graphics processor playback tool, an instruction generation apparatus for a graphics processor playback tool, a computer device, a computer-readable storage medium, and a computer program product.

[0004] The technical solution of this disclosure embodiment is implemented as follows: On one hand, embodiments of this disclosure provide a method for generating instructions for a graphics processor playback tool, including: Based on the block size, perform block-level filtering on the currently used GPU buffer data to remove data blocks whose content has not changed, and obtain the data blocks to be processed; Based on the size of the sub-block, the data block to be processed is filtered at the sub-block level to remove the sub-data blocks whose content has not changed, and obtain the difference sub-data blocks; Based on the difference sub-data blocks, update instructions are generated; these update instructions are used to update the contents of the difference sub-data blocks in the GPU buffer data.

[0005] On the other hand, embodiments of this disclosure provide an instruction generation apparatus for a graphics processor playback tool, comprising: The filtering module is configured to perform block-level filtering on the currently used GPU buffer data based on the block size, in order to remove data blocks in the GPU buffer data whose content has not changed, and obtain the data blocks to be processed; The filtering module is also configured to perform sub-block-level filtering on the data block to be processed based on the sub-block size, so as to remove sub-data blocks whose content has not changed in the data block to be processed, and obtain the difference sub-data blocks; The generation module is configured to generate update instructions based on the difference sub-data blocks; the update instructions are used to update part or all of the contents of the difference sub-data blocks in the GPU buffer data.

[0006] In another aspect, embodiments of this disclosure provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement some or all of the steps in the above-described method.

[0007] In another aspect, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described method.

[0008] In another aspect, embodiments of this disclosure provide a computer program including computer-readable code, which, when executed in a computer device, causes a processor in the computer device to perform some or all of the steps in the above-described method.

[0009] In another aspect, embodiments of this disclosure provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer device, it implements some or all of the steps in the above-described method.

[0010] In this embodiment, block-level filtering of the currently used GPU buffer data based on block size can remove data blocks whose content has not changed and retain data blocks whose content has changed. Sub-block-level filtering of the data blocks to be processed based on sub-block size can remove sub-data blocks whose content has not changed and retain differential sub-data blocks whose content has changed. Thus, through a two-level filtering mechanism based on fast block-level filtering and precise sub-block-level comparison, the differential sub-data blocks whose content has truly changed can be accurately located according to the distribution of data changes. Therefore, only data blocks whose content has truly changed are processed. The new instruction, compared to existing technologies that generate update instructions for unchanged data blocks due to their simpler detection mechanisms, reduces the number of update instructions. Furthermore, this disclosure uses hierarchical filtering based on block size and sub-block size, which provides finer granularity compared to existing technologies that use fixed block size. This further ensures that the filtered data blocks have changed content and prevents the generation of update instructions for unchanged data blocks. This effectively reduces the generation of a large number of redundant update instructions in sparse modification scenarios due to fixed granularity, effectively reducing the problems of increased storage volume, transmission overhead, and replay overhead, and achieving the best balance between the number of instructions and the amount of transmission.

[0011] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this disclosure. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the specification, serve to illustrate the technical solutions of this disclosure.

[0013] Figure 1 A schematic diagram of the implementation flow of an instruction generation method for a graphics processor playback tool provided in this embodiment of the present disclosure. Figure 1 ; Figure 2 A system architecture diagram of an instruction generation method for a graphics processor playback tool provided in this embodiment of the present disclosure; Figure 3 A schematic diagram of the implementation flow of an instruction generation method for a graphics processor playback tool provided in this embodiment of the present disclosure. Figure 2 ; Figure 4 A schematic diagram of the composition structure of an instruction generation device for a graphics processor playback tool provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this disclosure. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this disclosure. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0015] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0016] If similar descriptions such as "first / second" appear in the application documents, the following explanation shall be added: the terms "first / second / third" are used only to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this disclosure described herein can be implemented in an order other than that illustrated or described herein.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this disclosure.

[0018] The fixed-granularity update instruction generation method in related technologies has at least the following problems: 1. Based on a fixed granularity, the cur_buf file is divided into data blocks of uniform size. The underlying hardware and instruction mechanism only support complete blocks as the smallest update unit, failing to recognize minor local changes within a block. This uniform, one-size-fits-all block division method is completely unsuitable for the real-world characteristics of sparse changes: few, discrete, and distributed across blocks. If any modification occurs within a data block, a complete block update instruction must be generated for that block. In sparse change scenarios, a few scattered modifications are often distributed across multiple non-overlapping data blocks. Each block corresponding to a modification requires a separate update instruction, and each instruction must carry all the original data of the entire block. Most of these bytes are unmodified redundant content, resulting in a large number of redundant update instructions. For example, with a fixed granularity of 64 bytes, if only three single-byte variables located in different cache lines are sparsely modified, the fixed granularity mechanism must generate three complete 64-byte block update instructions, transmitting a total of 192 bytes of data. However, only 3 bytes of data are actually modified, resulting in a large number of useless update instructions and redundant payloads.

[0019] 2. Fixed granularity divides the cur_buf file into uniformly sized data blocks and requires update operations to use complete data blocks as the smallest unit of transmission. It cannot remove unmodified content within a block. When the data change density is low, each local modification will only change a small number of bytes within the block, and most of the data in the block will remain in its original state. However, the entire data block still needs to be transmitted to complete the update. Each update transmission stream will carry a large amount of redundant data that has not changed, ultimately resulting in additional data transmission overhead far exceeding the actual effective modification amount.

[0020] 3. The fixed-granularity data block partitioning scheme pre-defines a complete data block of uniform size as the only minimum update unit, supporting only the whole block update operation mode. It lacks a dynamic cost trade-off strategy to adapt to the differences of scattered data. It cannot generate fine-grained instructions carrying only offset and changed data for a small number of local changes within a block to reduce invalid transmission load, nor can it merge multiple small changes distributed in neighboring blocks into a single batch update instruction to reduce the total number of instructions. When facing distributed data changes, it can only mechanically issue update instructions to each complete data block with changes, and cannot flexibly adjust the update granularity or make dynamic trade-offs between the total number of instructions and the amount of redundant data transmitted per instruction. Therefore, it is difficult to achieve the best balance between the two types of overhead and the overall cost.

[0021] This disclosure aims to solve the following technical problems: 1. How to dynamically adjust the granularity of update commands based on differences in file content rather than file size; 2. How to reduce the number of redundant update instructions caused by fixed granularity; 3. How to improve the accuracy of update commands to reduce data transfer volume.

[0022] This disclosure provides an instruction generation method for a graphics processor playback tool, which can be executed by the processor of a computer device. The computer device refers to a device with data processing capabilities, such as a server, laptop, tablet, desktop computer, smart TV, set-top box, or mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device). Figure 1 As shown, the method includes the following steps 101 to 103: Step 101: Perform block-level filtering on the currently used GPU buffer data based on block size to remove data blocks in the GPU buffer data whose content has not changed, and obtain the data blocks to be processed.

[0023] The graphics processor buffer data currently in use refers to the cur_buf file. The cur_buf file is a mirror image maintained by the trace tool at the playback end, representing the complete content that a certain resource (texture / buffer) on the GPU should currently have.

[0024] Block size refers to the granularity of block-level partitioning, and can be represented as `blockSize`. In some implementations, the block size can be an empirical value determined through multiple trials based on the size of the `cur_buf` file. The data block to be processed refers to the data block in the GPU buffer whose content has changed.

[0025] In some implementations, the GPU buffer data can be divided based on the block size to obtain multiple data blocks; block-level filtering can be performed on the multiple data blocks to remove data blocks whose content has not changed in the GPU buffer data, and obtain data blocks whose content has changed, which are then used as data blocks to be processed.

[0026] The size of multiple data blocks is equal to or less than the block size. In some implementations, if the cur_buf file size and the block size are multiples of each other, then the size of all data blocks is the block size. If the cur_buf file size and the block size are not multiples of each other, then the size of the last partitioned data block is less than the block size, and the size of all other data blocks is the block size.

[0027] In some implementations, the block size can be determined based on the relationship between the size of the currently used GPU buffer data (cur_buf file size) and a preset total threshold.

[0028] In some implementations, if the size of the currently used GPU buffer data (cur_buf file size) is less than or equal to a preset total threshold, the block size is determined as a first block size; if the size of the currently used GPU buffer data (cur_buf file size) is greater than the preset total threshold, the block size is determined as a second block size; the second block size is greater than the first block size. For example, the preset total threshold can be 64KB, the first block size can be 1KB, and the second block size can be 4KB. Of course, the preset total threshold can also be set to other values ​​based on the cur_buf file size, and the first and second block sizes can also be set to other values ​​based on the correlation between the cur_buf file size and the block-level partitioning granularity; this disclosure does not limit this.

[0029] In some implementations, data fingerprints of multiple data blocks can be determined, and block-by-block comparisons can be performed based on the data fingerprints of multiple data blocks to identify the data blocks whose content has changed and which need to be processed.

[0030] In some implementations, the data fingerprints of multiple data blocks can be compared with the data fingerprint of a baseline data block to identify the data blocks whose content has changed and require further processing. The data fingerprint of the baseline data block can be determined based on the data fingerprints of data blocks whose content has not changed. The baseline data block can be a pre-selected data block whose content has not changed. For example, the baseline data block can be a data block in the current cur_buf file whose content has not changed, or it can be a data block in the previous cur_buf file whose content has not changed.

[0031] In some implementations, multiple data blocks of the current cur_buf file can be compared sequentially with multiple data blocks of the previous cur_buf file to identify data blocks whose content has changed, which are then designated as data blocks to be processed. In this case, the data blocks of the previous cur_buf file are used as reference data blocks for comparison with the data blocks of the current cur_buf file. The comparison is performed sequentially according to the position of the data blocks within the cur_buf file; that is, the i-th data block of the current cur_buf file is compared with the i-th data block of the previous cur_buf file.

[0032] In some implementations, the data fingerprints of multiple data blocks can be determined based on a first preset algorithm. The first preset algorithm may be one or more of the following algorithms: Cyclic Redundancy Check (CRC), hash check algorithm, checksum algorithm, etc.

[0033] Step 102: Based on the sub-block size, perform sub-block-level filtering on the data block to be processed to remove sub-data blocks whose content has not changed, and obtain the difference sub-data blocks.

[0034] Sub-block size refers to the granularity of sub-block level partitioning, and can be represented as subBlockSize. In some implementations, the sub-block size can be an empirical value determined through multiple trials based on the correlation between the cur_buf file size, data block size, and sub-data block size. The data block to be processed refers to the data block in the GPU buffer where the content has changed. The difference sub-data block refers to the sub-data block in the data block to be processed where the content has changed.

[0035] In some implementations, the data block to be processed can be divided into multiple sub-data blocks based on the sub-block size; the multiple sub-data blocks are then filtered to remove sub-data blocks whose content has not changed, and the sub-data blocks whose content has changed are obtained as the difference sub-data blocks.

[0036] In some implementations, data fingerprints of multiple sub-data blocks can be determined, and block-by-block comparisons can be performed based on the data fingerprints of the multiple sub-data blocks to identify the sub-data blocks with changed content.

[0037] In some implementations, the data fingerprints of each of multiple sub-data blocks can be compared with the data fingerprint of a reference sub-data block to identify the sub-data blocks whose content has changed. The data fingerprint of the reference sub-data block can be determined based on the data fingerprints of sub-data blocks whose content has not changed. A reference sub-data block is a sub-data block within a reference data block whose content has not changed. The reference sub-data blocks corresponding to different sub-data blocks can be the same or different, depending on the specific content of the data block. For example, based on the position of the sub-data blocks within the data block, multiple sub-data blocks in the current data block can be mapped one-to-one with multiple sub-data blocks in the reference data block, in which case each sub-data block corresponds to a different reference sub-data block.

[0038] In some implementations, the data fingerprints of each of the multiple sub-data blocks can be determined based on a second preset algorithm. The second preset algorithm may be the same as or different from the first preset algorithm, and this disclosure does not limit this.

[0039] In some implementations, detection functions within the GPU playback tool can be used to perform block-level and sub-block-level filtering to identify differing sub-data blocks. The detection function in the GPU playback tool can be BufferDiffer:Compare. BufferDiffer:Compare compares two buffer snapshots byte-by-byte (or at a configured granularity) to identify differing sub-data blocks.

[0040] Step 103: Generate update instructions based on the difference sub-data blocks; the update instructions are used to update the contents of the difference sub-data blocks in the GPU buffer data.

[0041] The update instruction refers to the update instruction used for playback. In some implementations, the update instruction can be implemented by the GPU playback tool accessing GPU memory through memory mapping. Therefore, the GPU playback tool can execute the instruction generation method of the graphics processor playback tool provided in this disclosure embodiment, specifically, it can be executed by the GPU memory access module in the GPU playback tool.

[0042] In some implementations, update instructions can be generated directly based on the differencing sub-data blocks. For example, a text-based update instruction can be generated for each differencing sub-data block.

[0043] In some implementations, differing sub-data blocks can be merged to obtain merged sub-data blocks; update instructions are then generated based on the merged sub-data blocks. For example, a text-based update instruction is generated for each merged sub-data block. The basis for merging differing sub-data blocks includes one or more of the following: the positional relationship between the differing sub-data blocks and the merging cost of the differing sub-data blocks.

[0044] In this embodiment, block-level filtering of the currently used GPU buffer data is performed based on block size. This removes data blocks whose content has not changed and retains data blocks whose content has changed. Sub-block-level filtering is also performed based on sub-block size. This removes sub-data blocks whose content has not changed and retains sub-data blocks whose content has changed. This two-level filtering mechanism, based on fast block-level filtering and precise sub-block-level comparison, first filters at the whole block level and then at the sub-block level. This identifies minor changes within a block. This two-level blocking mechanism matches the characteristics of sparse changes—few, discrete, and distributed across blocks—ensuring that update instructions are generated only for sub-data blocks whose content has truly changed. Each instruction only needs to carry the changed data, eliminating redundant content. This solves the problem of redundant updates caused by fixed granularity in existing technologies. The issue with the instructions: Because this disclosure further divides the data block into sub-data blocks, the update operation uses the sub-data blocks with changed content as the smallest transmission unit. This allows for the removal of unmodified content within the block. Each update transmission stream only carries the data with changed content and does not carry the unmodified content within the block. Therefore, it does not bring additional data transmission overhead far exceeding the actual effective modification amount. The embodiments of this disclosure only update the sub-data blocks with changed content, which can adapt to the dynamic cost trade-off strategy of scattered data differences. It can generate fine-grained instructions carrying only offset and changed data for a small number of local changes within the block to reduce invalid transmission load. It can also merge multiple small changes distributed in the block into a single batch update instruction to reduce the total number of instructions. When facing distributed data changes, only mechanical updates can be issued to each complete data block with changes. By flexibly adjusting the update granularity and making dynamic trade-offs between the total number of instructions and the amount of redundant data transmitted per instruction, the optimal balance between the number of instructions and the amount of transmission can be achieved.

[0045] In some embodiments, the instruction generation method for the graphics processor playback tool provided in this disclosure further includes the following steps 104 to 107: Step 104: Write the update command and its data fields into the trajectory file in sequence.

[0046] Each update instruction's data fields include, but are not limited to: the buffer's identifier name (bufferName), the buffer's offset in the video memory / memory surface (surface_offset), the buffer's total size in bytes (size), the file descriptor or file path (for memory-mapped files) (file), and the data's offset position in the file (file_offset), etc.

[0047] In some implementations, the trace file may refer to a trace file. Update instructions and their data fields are written to the trace file in the order they are generated. The generation order reflects the position of the difference sub-data blocks within the GPU buffer data.

[0048] Step 105: Use the graphics processor playback tool to parse the update instructions in the trajectory file.

[0049] Step 106: Based on the update instruction, update the contents of the difference sub-data block in the GPU buffer data.

[0050] In some implementations, the contents of the difference sub-data blocks in the GPU buffer data can be updated based on update instructions in the order of generation.

[0051] Step 107: Replay using the updated GPU buffer data.

[0052] In this embodiment of the disclosure, the update instruction and the data field of the update instruction are written sequentially into the trajectory file, which helps the graphics processor playback tool to parse the update instruction in the trajectory file and update the content of the difference sub-data block in the GPU buffer data based on the update instruction, so that the GPU uses the updated GPU buffer data for playback.

[0053] In some embodiments, step 102 above can be implemented by the following steps 1021 to 1022: Step 1021: Divide the data block to be processed based on the size of the sub-blocks to obtain multiple sub-data blocks of the data block to be processed.

[0054] The size of multiple sub-data blocks is equal to or less than the sub-block size. In some implementations, if the data size of the data block to be processed is a multiple of the sub-block size, then the data size of all sub-data blocks is the sub-block size. If the data size of the data block to be processed is not a multiple of the sub-block size, then the data size of the last sub-data block is less than the sub-block size, and the data size of the remaining data blocks excluding the last sub-data block is the sub-block size.

[0055] Step 1022: Compare multiple sub-data blocks in the current GPU buffer data with multiple sub-data blocks in the previous GPU buffer data to remove sub-data blocks whose content has not changed, and obtain the difference sub-data blocks in the data block to be processed.

[0056] The process involves comparing multiple sub-data blocks in the current GPU buffer with multiple sub-data blocks in the previous GPU buffer. This process uses the multiple sub-data blocks in the previous GPU buffer as a reference base to determine whether the contents of the multiple sub-data blocks in the current GPU buffer have changed.

[0057] In some implementations, multiple sub-data blocks in the current GPU buffer data can be compared sequentially with multiple sub-data blocks in the previous GPU buffer data according to their positions in the GPU buffer data, so as to remove sub-data blocks whose content has not changed and obtain the difference sub-data blocks in the data block to be processed.

[0058] In this embodiment of the disclosure, the data block to be processed is divided based on the size of the sub-blocks to obtain multiple sub-data blocks of the data block to be processed. The multiple sub-data blocks in the current GPU buffer data are compared with the multiple sub-data blocks in the previous GPU buffer data in turn. This can accurately remove sub-data blocks whose content has not changed and retain the sub-data blocks in the data block to be processed whose content has changed, thereby achieving accurate positioning of the sub-data blocks with differences.

[0059] In some embodiments, step 103 above can be implemented by the following steps 1031 to 1033: Step 1031: Determine multiple differential sub-data blocks whose distance gap meets the merging gap threshold as adjacent differential sub-data blocks.

[0060] The merge gap threshold is used to merge differing sub-data blocks and can be represented as sparse_threshold. The merge gap threshold can be preset, specifically set to an empirical value obtained through multiple trials, such as 512 bytes.

[0061] In some implementations, multiple differential sub-data blocks with a distance threshold less than or equal to a merge gap threshold are identified as adjacent differential sub-data blocks. In this case, the distance gap satisfying the merge gap threshold means that the distance threshold is less than or equal to the merge gap threshold.

[0062] Step 1032: Merge adjacent differing sub-data blocks to obtain merged sub-data blocks.

[0063] In some implementations, adjacent differencing sub-data blocks can be merged based on the merging cost of adjacent differencing sub-data blocks to obtain merged sub-data blocks. The merging cost of adjacent differencing sub-data blocks indicates the resources required to merge adjacent differencing sub-data blocks, such as time and memory.

[0064] Step 1033: Generate update instructions based on the merged sub-data blocks.

[0065] In this embodiment, multiple differential sub-data blocks whose distance gap meets the merging gap threshold are identified as adjacent differential sub-data blocks. These adjacent differential sub-data blocks are then merged to obtain merged sub-data blocks, and update instructions are generated based on these merged sub-data blocks. This merging of adjacent differential sub-data blocks further reduces the number of instructions, thereby mitigating the problems of increased storage size, transmission overhead, and playback overhead.

[0066] In some embodiments, the "merging gap threshold" in step 1031 above can be achieved through the following steps A1 to A2: Step A1: Determine the difference density based on the data size of the difference sub-data blocks and the data size of the GPU buffer data.

[0067] In some implementations, an aggregation operation is performed on the data sizes of all differing sub-data blocks to obtain a third value; this third value is the aggregated value of the data sizes of all differing sub-data blocks; a non-linear operation is then performed on the third value and the data size of the GPU buffer data to obtain the difference density. For example, the aggregation operation can be a summation operation, in which case the third value is the total data size of the differing sub-data blocks. The non-linear operation can be a division operation.

[0068] Step A2: If the difference density is less than or equal to the density threshold, determine the merging gap threshold as the second value.

[0069] The density threshold, denoted as sparse_threshold, is used to switch between "compact update" and "sparse update" strategies. The density threshold can be preset, specifically set to an empirical value obtained through multiple trials, such as 0.03. The second value can be a larger value, such as 512 bytes.

[0070] In some implementations, when the density difference is greater than a density threshold, the merging gap threshold is determined to be a fourth value; the fourth value is less than the second value.

[0071] In this embodiment of the disclosure, the difference density is determined based on the data size of the difference sub-data block and the data size of the GPU buffer data. When the difference density is less than or equal to the density threshold, the merging gap threshold is set to a larger second value. In this way, by adjusting the merging gap threshold in real time by the difference density, the number of instructions and the amount of data transmitted can be significantly reduced, thereby reducing the size of the trajectory file and the playback delay.

[0072] In some embodiments, step 1032 described above can be implemented by the following steps B1 to B3: Step B1: Determine the cost threshold based on the graphics processor's hardware configuration and network transmission conditions.

[0073] A cost threshold is used to determine whether to merge. The cost threshold can be preset, specifically set to an empirical value obtained through multiple trials, such as 256 bytes. Alternatively, the cost threshold can be adjusted in real-time based on the graphics processor's hardware configuration and network transmission conditions. Network transmission conditions may include, but are not limited to, network bandwidth and network latency.

[0074] Step B2: Determine the merging cost of adjacent differential sub-data blocks based on the individual data size of each adjacent differential sub-data block and the combined data size of adjacent differential sub-data blocks.

[0075] The merge cost is used to indicate the time and memory required to merge adjacent differential sub-data blocks.

[0076] In some implementations, an aggregation operation is performed on the data size of each adjacent differential sub-data block to obtain a first value; the first value is the aggregated value of the data sizes of adjacent differential sub-data blocks; a difference operation is performed on the first value and the merged data size of the adjacent differential sub-data blocks to obtain the merging cost of the adjacent differential sub-data blocks.

[0077] For example, the individual data sizes of adjacent differing sub-data blocks can be summed to obtain a first value; the merged data size of the adjacent differing sub-data blocks can be subtracted from the first value to obtain the merge cost of the adjacent differing sub-data blocks. For instance, the merge cost of adjacent differing sub-data blocks can be calculated as: merge_cost = combined_size - (len1 + len2); where merge_cost is the merge cost of adjacent differing sub-data blocks, combined_size is the merged data size of adjacent differing sub-data blocks, and len1 and len2 are the aggregated values ​​of the data sizes of adjacent differing sub-data blocks.

[0078] Step B3: If the merging cost is less than or equal to the cost threshold, merge adjacent differing sub-data blocks to obtain merged sub-data blocks.

[0079] In this embodiment of the disclosure, the cost threshold is adjusted in real time based on the hardware configuration of the graphics processor and the network transmission status, so that the cost threshold is the optimal solution for the current scenario; thereby improving the effectiveness of merging adjacent differential sub-data blocks, and thus significantly reducing the number of instructions and data transmission, thereby reducing the size of the trajectory file and playback delay.

[0080] The following describes the application of the instruction generation method for the graphics processor playback tool provided in this embodiment in a real-world scenario.

[0081] This disclosure provides a dynamic granularity update instruction generation method based on hierarchical difference detection and intelligent merging (corresponding to the instruction generation method of the graphics processor playback tool mentioned above), which enables the overall overhead (number of update instructions and amount of data transmission) to be minimized while maintaining high accuracy in different difference density scenarios.

[0082] The embodiments of this disclosure are performed in the following main steps in sequence: 1) Preprocessing and block segmentation: Select the initial blockSize based on the cur_buf file size (1KB for file size ≤ 64KB; 4KB for file size > 64KB), and segment the buffer into blocks based on the blockSize; 2) Block-level fast filtering: Calculate the CRC (CRC32, initial value 0xFFFFFFFF) for each block. If the CRCs are the same, skip the block. 3) Sub-block level precise comparison: For blocks with different CRC (corresponding to the data blocks to be processed mentioned above), perform sub-block comparisons at subBlockSize (default 16 bytes) to accurately locate the difference sub-blocks (corresponding to the difference sub-data blocks mentioned above). 4) Merging and optimization of difference segments: First, perform basic adjacent / overlapping merging, and select whether to enable sparse scene optimization based on the difference density (diff_density); in sparse scenes, adopt the merging gap threshold (dynamic merge_gap_threshold) and cost-benefit merging strategy to balance the amount of data transmission and instructions. 5) Update instruction generation: Generate textual update instructions for each merged difference segment (merged sub-data block), with fields including the identifier name of the buffer (bufferName), the offset of the buffer in the video memory / memory surface (surface_offset), the total size of the buffer (bytes) (size), the file descriptor or file path (for memory-mapped files) (file), the offset position of the data in the file (file_offset), etc., and write them to the trace file in order; 6) Execute playback: The GPU playback tool parses the textual update instructions and executes the updates in sequence.

[0083] The following are several embodiments to illustrate the implementation details of the embodiments of this disclosure (exemplary, not limiting): Example 1 (Basic Process): BufferDiffer:Compare is executed based on blockSize and subBlockSize to generate a list of diffs (a list of diffs consisting of diffs sub-data blocks); basic adjacency merging is performed on diffs to generate merged (merged sub-data blocks); updateInfo (data fields of update instructions) is generated for merged and written to trace.

[0084] Example 2 (Cost-Benefit Combination of Sparse Differences): Calculate the difference density: `diff_density = sum(diff.length) / fileSize`; where `diff.length` is the size of the difference sub-data block. If `diff_density <= sparse_threshold` (density threshold, example 0.03), set the merge gap threshold `merge_gap_threshold` to a larger value (e.g., 512 bytes), and perform iterative cost-effective merging on merged segments: For adjacent segments, calculate `merge_cost = combined_size - (len1 + len2)`, and perform merging when `merge_cost <= cost_threshold` (cost threshold, example 256 bytes) and merging reduces the number of instructions.

[0085] like Figure 2 As shown in the system architecture diagram of this embodiment, the system includes: a trace generator, a diff detector, an update instr generator, a trace file, a replay tool, and a GPU device. The trace generator provides pre_buf (previous GPU buffer data) and cur_buf (current GPU buffer data). The diff detector performs block-level and sub-block-level filtering on the GPU buffer data. The update instr generator generates update instructions based on the diff sub-data blocks. The trace file stores the textual update instructions and their corresponding data fields. The replay tool updates the content of the diff sub-data blocks in the GPU buffer data. The GPU device performs replay using the updated GPU buffer data.

[0086] like Figure 3As shown, the implementation flow of this embodiment includes: Step 301: Calculate the size of the cur_buf file. Step 302: Determine whether the size of the cur_buf file is less than or equal to 64KB; if the size of the cur_buf file is less than or equal to 64KB, proceed to step 303; if the size of the cur_buf file is greater than 64KB, proceed to step 304. Step 303: The block size is 1KB. Step 304: The block size is 4KB. After steps 303 and 304, proceed to step 305. Step 305: Divide the file into blocks according to the block size and read them. Step 306: Calculate the CRC for each block. Step 307: Determine whether the CRC of each block is correct. If the CRC of each block is incorrect, proceed to step 309; if the CRC of each block is correct, proceed to step 308. Step 308: Skip the block. Step 309: Compare sub-blocks one by one according to the sub-block size. Step 310: Record the difference sub-segment (start, length). Step 311: Perform basic merging (adjacent / overlapping) on ​​the differing segments. Step 312: Calculate the difference density (diff_density). Step 313: Determine if the difference density is less than or equal to the density threshold; if so, proceed to step 314; if greater than the threshold, proceed to step 315. Step 314: Set a wider merge gap threshold (merge_gap_threshold). Step 315: Maintain strict merging. Step 316: Perform cost-benefit merging. Step 317: Generate an Updatelnfo list (a list of multiple update commands). Step 318: Write the update commands to the trace file.

[0087] The technical solutions of the embodiments disclosed herein can bring at least the following technical effects: 1. It can significantly reduce the number of update instructions and data transmission volume in various scenarios with varying densities, thereby reducing trace size and replay latency; 2. Two-level verification (block-level + sub-block-level comparison) improves comparison efficiency while ensuring accuracy; 3. By introducing cost-effective merging and hierarchical granularity strategies, the number of instructions can be effectively avoided in sparse and differential scenarios.

[0088] The objectives of this invention can also be achieved through the following alternative solutions: 1) Parallelize CRC or difference comparisons (using multithreading or GPU acceleration) to improve comparison throughput; 2) Use more sophisticated statistical or machine learning methods to determine the differential distribution and granularity (involving various thresholds); 3) In network-constrained scenarios, dynamically correlate cost_threshold with network bandwidth / latency metrics for real-time parameter tuning.

[0089] The key points and points to be protected in the embodiments of this disclosure include at least the following: 1. Dynamically determine the granularity of update instructions based on actual differences (not just based on file size); 2. Two-level comparison mechanism: block-level fast filtering + sub-block-level precise comparison; 3. Intelligent merging strategies for different segments, including basic adjacent merging and cost-effective merging decisions; 4. A hybrid strategy of layered granularity (fine-grained + intelligent coarse-grained) to balance transmission volume and instruction count; The main technical advantages of the embodiments disclosed herein compared to existing technologies based on fixed granularity include: 1. Improved accuracy: By comparing and merging differences at the sub-block level, the generated update instructions are closer to the actual changed area, thereby reducing transmission redundancy; 2. Overhead Optimization: The cost-effective merging strategy reduces a large number of instructions in sparse and differential scenarios, thereby reducing replay and storage overhead overall; 3. Flexibility and configurability: Parameterized thresholds (blockSize, subBlockSize, sparse_threshold, cost_threshold, etc.) allow for scenario-based optimization.

[0090] Based on the foregoing embodiments, this disclosure provides an instruction generation device for a graphics processor playback tool. The device includes various units and modules included in each unit, which can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0091] Figure 4 This is a schematic diagram of the composition structure of an instruction generation device for a graphics processor playback tool provided in an embodiment of this disclosure, as shown below. Figure 4 As shown, the instruction generation device 400 for the graphics processor playback tool includes: a filtering module 410 and a generation module 420, wherein: The filtering module 410 is configured to perform block-level filtering on the currently used GPU buffer data based on the block size, so as to remove data blocks in the GPU buffer data whose content has not changed, and obtain data blocks to be processed. The filtering module 410 is also configured to perform sub-block-level filtering on the data block to be processed based on the sub-block size, so as to remove sub-data blocks whose content has not changed in the data block to be processed, and obtain the difference sub-data blocks. The generation module 420 is configured to generate update instructions based on the difference sub-data blocks; the update instructions are used to update part or all of the contents of the difference sub-data blocks in the GPU buffer data.

[0092] In some embodiments, the generation module 420 is further configured to determine multiple differential sub-data blocks whose distance gap meets the merging gap threshold as adjacent differential sub-data blocks; merge adjacent differential sub-data blocks to obtain merged sub-data blocks; and generate update instructions based on the merged sub-data blocks.

[0093] In some embodiments, the generation module 420 is further configured to determine the merging cost of adjacent differential sub-data blocks based on the data size of each adjacent differential sub-data block and the data size of the merged adjacent differential sub-data blocks; the merging cost is used to indicate the time and memory required to merge the adjacent differential sub-data blocks; if the merging cost is less than or equal to the cost threshold, the adjacent differential sub-data blocks are merged to obtain merged sub-data blocks.

[0094] In some embodiments, the generation module 420 is further configured to perform an aggregation operation on the data size of each adjacent differential sub-data block to obtain a first value; the first value is the aggregated value of the data sizes of adjacent differential sub-data blocks; and to perform a difference operation on the first value and the merged data size of the adjacent differential sub-data blocks to obtain the merging cost of the adjacent differential sub-data blocks.

[0095] In some embodiments, the merge gap threshold is determined as follows: the difference density is determined based on the data size of the difference sub-data block and the data size of the GPU buffer data; if the difference density is less than or equal to the density threshold, the merge gap threshold is determined to be a second value.

[0096] In some embodiments, the generation module 420 is further configured to perform an aggregation operation on the data size of all differential sub-data blocks to obtain a third value; the third value is the aggregated value of the data size of all differential sub-data blocks; and to perform a non-linear operation on the third value and the data size of the GPU buffer data to obtain the difference density.

[0097] In some embodiments, the filtering module 410 is further configured to divide the data block to be processed based on the sub-block size to obtain multiple sub-data blocks of the data block to be processed; and to compare the multiple sub-data blocks in the current GPU buffer data with the multiple sub-data blocks in the previous GPU buffer data in turn to remove sub-data blocks whose content has not changed, thereby obtaining the difference sub-data blocks in the data block to be processed.

[0098] In some embodiments, the instruction generation apparatus 400 for the graphics processor playback tool further includes: The playback module is configured to write update instructions and their data fields sequentially to the trajectory file; use the graphics processor playback tool to parse the update instructions in the trajectory file; update the contents of the difference sub-data blocks in the GPU buffer data based on the update instructions; and perform playback using the updated GPU buffer data.

[0099] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this disclosure can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this disclosure, please refer to the descriptions of the method embodiments of this disclosure for understanding.

[0100] It should be noted that, in the embodiments of this disclosure, if the instruction generation method of the graphics processor playback tool described above is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this disclosure, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this disclosure are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0101] This disclosure provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0102] This disclosure provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0103] This disclosure provides a computer program including computer-readable code. When the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0104] This disclosure provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0105] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referenced interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this disclosure, please refer to the descriptions of the method embodiments of this disclosure for understanding.

[0106] It should be noted that, Figure 5 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this disclosure, such as... Figure 5 As shown, the hardware entity of the computer device 500 includes: a processor 501, a communication interface 502, and a memory 503, wherein: Processor 501 typically controls the overall operation of computer device 500.

[0107] Communication interface 502 enables computer devices to communicate with other terminals or servers via a network.

[0108] The memory 503 is configured to store instructions and applications executable by the processor 501, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) of the processor 501 and various modules in the computer device 500. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 501, the communication interface 502, and the memory 503 can be performed via bus 504.

[0109] It should be understood that the phrase "an embodiment" or "one embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this disclosure. Therefore, "in one embodiment" or "one embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this disclosure, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure. The sequence numbers of the above embodiments of this disclosure are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0110] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0111] In the several embodiments provided in this disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0112] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0113] In addition, each functional unit in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0114] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0115] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0116] The above are merely embodiments of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for generating instructions for a graphics processor playback tool, characterized in that, The method includes: Based on the block size, the GPU buffer data currently in use is filtered at the block level to remove data blocks in the GPU buffer data whose content has not changed, and the data blocks to be processed are obtained. The data block to be processed is filtered at the sub-block level based on the sub-block size to remove sub-data blocks whose content has not changed, thus obtaining the difference sub-data blocks; Based on the difference sub-data block, an update instruction is generated; the update instruction is used to update the content of the difference sub-data block in the GPU buffer data.

2. The method according to claim 1, characterized in that, The step of generating update instructions based on the difference sub-data blocks includes: Multiple differential sub-data blocks whose distance gap meets the merging gap threshold are identified as adjacent differential sub-data blocks; The adjacent differing sub-data blocks are merged to obtain merged sub-data blocks; An update instruction is generated based on the merged sub-data blocks.

3. The method according to claim 2, characterized in that, The step of merging adjacent differing sub-data blocks to obtain merged sub-data blocks includes: Based on the individual data size of each adjacent differential sub-data block and the combined data size of the adjacent differential sub-data blocks, the merging cost of the adjacent differential sub-data blocks is determined; the merging cost is used to indicate the time and memory required to merge the adjacent differential sub-data blocks. If the merging cost is less than or equal to the cost threshold, adjacent differing sub-data blocks are merged to obtain merged sub-data blocks.

4. The method according to claim 3, characterized in that, The determination of the merging cost of adjacent differing sub-data blocks based on the individual data sizes of the adjacent differing sub-data blocks and the merged data size of the adjacent differing sub-data blocks includes: An aggregation operation is performed on the data sizes of adjacent differing sub-data blocks to obtain a first value; the first value is the aggregated value of the data sizes of adjacent differing sub-data blocks. A difference-based operation is performed on the first value and the size of the merged adjacent difference sub-data blocks to obtain the merging cost of the adjacent difference sub-data blocks.

5. The method according to claim 2, characterized in that, The merging gap threshold is determined in the following manner: The difference density is determined based on the data size of the difference sub-data block and the data size of the GPU buffer data; If the difference density is less than or equal to the density threshold, the merging gap threshold is determined to be a second value.

6. The method according to claim 5, characterized in that, Determining the difference density based on the data size of the difference sub-data block and the data size of the GPU buffer data includes: An aggregation operation is performed on the data sizes of all the different sub-data blocks to obtain a third value; the third value is the aggregated value of the data sizes of all the different sub-data blocks. The difference density is obtained by performing a non-linear operation on the third value and the data size of the GPU buffer data.

7. The method according to any one of claims 1 to 6, characterized in that, The step of filtering the data block to be processed based on its size at the sub-block level to remove sub-data blocks whose content has not changed, thereby obtaining differential sub-data blocks, includes: The data block to be processed is divided based on the size of the sub-block to obtain multiple sub-data blocks of the data block to be processed; The current sub-data blocks in the GPU buffer data are compared with the previous sub-data blocks in the GPU buffer data to remove sub-data blocks whose content has not changed, thereby obtaining the difference sub-data blocks in the data block to be processed.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Write the update instruction and its data fields into the trajectory file in sequence; The update instructions in the trajectory file are parsed using the graphics processor playback tool. Based on the update instruction, update the content of the difference sub-data block in the GPU buffer data; Playback is performed using the updated GPU buffer data.

9. An instruction generation apparatus for a graphics processor playback tool, characterized in that, The device includes: The filtering module is configured to perform block-level filtering on the currently used graphics processor (GPU) buffer data based on the block size, in order to remove data blocks in the GPU buffer data whose content has not changed, and obtain data blocks to be processed. The filtering module is also configured to perform sub-block-level filtering on the data block to be processed based on the sub-block size, so as to remove sub-data blocks whose content has not changed in the data block to be processed, and obtain differential sub-data blocks; The generation module is configured to generate update instructions based on the difference sub-data blocks; the update instructions are used to update part or all of the contents of the difference sub-data blocks in the GPU buffer data.

10. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a non-transitory computer-readable storage medium storing a computer program that, when read and executed by a computer device, implements the steps of the method according to any one of claims 1 to 8.

Images