Differential positioning method, system, device, medium and product of graphics pipeline

Abstract

This application provides a method, system, device, medium, and product for locating differences in a graphics pipeline. When differences occur in the rendering of a rendered entity within the graphics pipeline, the method acquires the first log data corresponding to each graphics stage in the pipeline. Following the rendering order defined in the rendering chain of the rendered entity, the method uses the first log data of the corresponding graphics stage to perform difference analysis, identifying the target graphics stage where the difference occurs earliest among multiple graphics stages. The rendering chain of the rendered entity represents the rendering chain from the vertex to the pixel corresponding to the rendered entity. The rendering chain of the rendered entity is determined based on pre-set anchor point data connecting adjacent graphics stages in the graphics pipeline. The anchor point data is constructed based on the attributes of the rendered entity, requiring no manual intervention and automatically identifying the earliest difference stage, thus improving the efficiency of difference location.

Description

Technical Field

[0001] This application relates to design verification and debugging techniques for computer graphics processors, and more particularly to a differential positioning method, system, device, medium, and product for a graphics pipeline. Background Technology

[0002] When discrepancies arise in the graphics rendering results and it is necessary to locate the differences in the graphics pipeline, the existing solutions involve manually tracing back the upstream graphics stages one by one to determine the stage of discrepancy, which is inefficient. Summary of the Invention

[0003] In view of this, embodiments of this application provide at least one differential positioning method, system, device, medium, and product for a graphics pipeline.

[0004] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a method for differential localization of a graphical pipeline, the method comprising: In the event of discrepancies in the rendering of entities in the graphics pipeline, the first log data corresponding to each graphics stage in the graphics pipeline is obtained. According to the rendering order defined in the rendering pipeline of the rendering entity, the first log data of the corresponding graphics stage is used for difference analysis to determine the target graphics stage with the earliest difference among multiple graphics stages; the rendering pipeline of the rendering entity represents the rendering pipeline from vertex to pixel corresponding to the rendering entity; the rendering pipeline of the rendering entity is determined based on the anchor point data connecting adjacent graphics stages in the pre-set graphics pipeline; the anchor point data is constructed based on the attributes of the rendering entity.

[0005] Secondly, embodiments of this application provide a differential positioning system for a graphical pipeline, the system comprising: The acquisition layer is used to obtain the first log data corresponding to each graphics stage in the graphics pipeline when there are differences in the rendering of the rendered entities in the graphics pipeline. The analysis layer is used to perform difference analysis using the first log data of the corresponding graphics stage according to the rendering order defined in the rendering pipeline of the rendering entity, and to determine the target graphics stage with the earliest difference among multiple graphics stages; the rendering pipeline of the rendering entity represents the rendering pipeline from vertex to pixel corresponding to the rendering entity; the rendering pipeline of the rendering entity is determined based on the anchor point data connecting adjacent graphics stages in the pre-set graphics pipeline; the anchor point data is constructed based on the attributes of the rendering entity.

[0006] Thirdly, embodiments of this application 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] Fourthly, embodiments of this application 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] Fifthly, embodiments of this application 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, it implements some or all of the steps in the above-described method.

[0009] Based on the embodiments provided in this application, the rendering link corresponding to a rendering entity is determined based on the anchor point data connecting adjacent graphics stages in a pre-set graphics pipeline. Since the anchor point data is constructed based on the attributes of the rendering entity, and the rendering link of the rendering entity represents the rendering link from the vertex to the pixel corresponding to the rendering entity, the corresponding vertex-to-pixel rendering link can be automatically constructed for the rendering entity. Therefore, when differences occur in the rendering of the rendering entity by the graphics pipeline, difference analysis is performed using the first log data of the corresponding graphics stage according to the vertex-to-pixel rendering link corresponding to the rendering entity. This identifies the target graphics stage with the earliest difference among multiple graphics stages, without manual intervention, and automatically identifies the earliest difference stage, improving the efficiency of difference localization.

[0010] 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 application. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0012] Figure 1 This is a flowchart illustrating the steps of a differential localization method for a graphical pipeline provided in this application embodiment; Figure 2 This is a schematic diagram of the differential positioning system for a graphical pipeline provided in an embodiment of this application; Figure 3 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0014] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely 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 application described herein can be implemented in an order other than that illustrated or described herein.

[0015] 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 application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0016] To facilitate understanding of this solution, the application background of the embodiments of this application will be explained before describing the embodiments of this application.

[0017] In the simulation verification phase of GPU chip design and driver development, the relevant debugging techniques (i.e., differential localization) mainly include the following three categories: Frame-level capture and replay tools: such as RenderDoc, NVIDIA Nsight, PIX, etc., which capture single-frame data by intercepting the graphics application programming interface (API) calls and check the shader state and resource content during replay, realizing the visualization and traceability of the entire single-frame rendering process and troubleshooting; Module-level offline logging technology: recording internal event logs at specific stages in each functional module of the GPU emulator or hardware driver for developers to analyze offline; Rendering result comparison, i.e., image consistency comparison: determining whether there are rendering anomalies by comparing the pixel values ​​and depth values ​​of the tested object with the final framebuffer or render target output by the reference model.

[0018] In summary, all relevant solutions require manual identification of differences and determination of the difference stage, resulting in low efficiency in difference identification.

[0019] To address the aforementioned issues, this application provides a method for difference localization in a graphics pipeline. Based on pre-set anchor point data connecting adjacent graphics stages in the graphics pipeline, the rendering link corresponding to a rendering entity is determined. Since the anchor point data is constructed based on the attributes of the rendering entity, and the rendering link of a rendering entity represents the rendering link from the vertex to the pixel corresponding to the rendering entity, the corresponding vertex-to-pixel rendering link can be automatically constructed for each rendering entity. Therefore, when differences occur in the rendering of a rendering entity within the graphics pipeline, difference analysis is performed using the first log data of the corresponding graphics stage according to the vertex-to-pixel rendering link of the rendering entity. This identifies the target graphics stage with the earliest difference among multiple graphics stages, eliminating the need for manual intervention and automatically identifying the earliest difference stage, thus improving the efficiency of difference localization.

[0020] Figure 1 This is a flowchart illustrating the steps of a differential localization method for a graphics pipeline provided in an embodiment of this application, as follows: Figure 1 As shown, the method may include the following steps S101 and S102.

[0021] Step S101: In the event of a difference in the rendering of the rendered entity in the graphics pipeline, obtain the first log data corresponding to each graphics stage in the graphics pipeline.

[0022] In this context, discrepancies in the rendering of rendering entities within the graphics pipeline (i.e., the graphics pipeline itself) indicate that the rendering results are inconsistent with the baseline, suggesting a difference in the rendering of a specific vertex, primitive, or pixel corresponding to a given rendering entity. Here, a rendering entity can be understood as the object that needs to be rendered.

[0023] The graphics stage refers to the sequential processing stages executed in the graphics pipeline during a single rendering process. In some embodiments, the graphics stage may include: Input Assembly (IA), Vertex Shading (VS), Hull Shading (HS), Domain Shading (DS), Geometry Shading (GS), Rasterization (Raster), Pixel Shading (PS), Depth Test (D / T), and Output Merger (OM).

[0024] The first log data consists of raw logs directly generated during the execution of each graphics or computation stage of the GPU. It reflects the actual execution status and data of each stage and serves as the foundation for subsequent difference comparisons. In some embodiments, the first log data may include: graphics stage, anchor data, payload data, sequence number or time information (seq_id / timestamp), schema version information (schema_version), etc. The payload data can also be referred to as effective payload data, and the graphics stage can also be referred to as the pipeline stage.

[0025] In some embodiments, the first log data can be generated based on observable semantics at the graph API level, enabling relevant personnel to collaborate within a unified semantic context, significantly shortening the problem communication and troubleshooting cycle, thereby improving the interpretability and collaboration efficiency of the debugging process, and increasing the efficiency of discrepancy analysis. For example, the vertex identifiers included in the anchor data can be represented using API-level observable semantics vertex_id.

[0026] In some possible implementations, during GPU simulation or debugging, initial log data for each graphics stage is generated in real-time by embedding data points within each graphics stage. For example, a GPU debugging and analysis system includes a data acquisition layer embedded in the GPU's modeling / simulation environment, or as an independent debugging intermediate layer. This layer generates structured logs, i.e., initial log data, at predetermined pipeline checkpoints (such as vertex output, primitive assembly, post-rasterization, pixel, fragment shading before and after, depth / stencil testing, output merging, etc.). In other possible implementations, the entire graphics pipeline log data is pre-recorded and stored in a log library. When differences are found through subsequent comparison of rendering results, the log records corresponding to the rendered entity at each graphics stage are retrieved, filtered, and extracted from the log library, and the initial log data for each graphics stage is reconstructed.

[0027] Step S102: According to the rendering order defined in the rendering chain of the rendering entity, perform difference analysis using the first log data of the corresponding graphics stage to determine the target graphics stage with the earliest difference among multiple graphics stages.

[0028] The rendering link of a rendering entity represents the rendering link from vertex to pixel corresponding to the rendering entity. A vertex-to-pixel rendering link refers to the complete end-to-end rendering link of the same rendering entity from vertex input to pixel output. In some embodiments, the rendering link of a rendering entity is determined based on anchor point data connecting adjacent graphics stages in a pre-defined graphics pipeline.

[0029] Anchor point data is a type of identification information used to associate the same rendered entity at different graphics stages.

[0030] The anchor point data is constructed based on the attributes of the rendered entity. In some embodiments, the attributes of the rendered entity may include: draw_id, primitive_id, vertex_id, instance_id, pixel coordinates, sample_index, resource_id, etc., and the anchor point data includes at least one of the following: draw_id, primitive_id, vertex_id, instance_id, pixel coordinates, sample_index, and resource_id.

[0031] In some embodiments, the vertex-to-pixel rendering chain is determined based on vertex-level processing chains, primitive-level processing chains, and pixel-level processing chains. A vertex-level processing chain is a stage chain that processes vertices; a primitive-level processing chain is a stage chain that processes primitives; and a pixel-level processing chain is a stage chain that processes pixels and fragments.

[0032] In some possible implementations, based on the inherent execution order of the graphics pipeline, the vertex-level processing link, primitive-level processing link, and pixel-level processing link are pre-assembled in a fixed order to directly form a complete vertex-to-pixel rendering link.

[0033] The vertex-level processing chain is determined based on the vertex-level graphics stage set and anchor point data. The vertex-level graphics stage set is a set of stages where vertices are the primary processing objects. In some embodiments, anchor point data can be vertex identifiers. The vertex-level processing chain is determined based on the vertex-level graphics stage set and vertex identifiers.

[0034] The element-level processing link is determined based on the element-level graphic stage set and anchor point data. The element-level graphic stage set is a set of stages where elements are the main processing objects. In some embodiments, anchor point data can be element identifiers. The element-level processing link is determined based on the element-level graphic stage set and element identifiers.

[0035] The pixel-level processing chain is determined based on the pixel-level graphics stage set and anchor point data. The pixel-level graphics stage set is a set of stages that primarily process pixels and fragments. In some embodiments, anchor point data can be pixel coordinates and sample indices. The pixel-level processing chain is determined based on the pixel-level graphics stage set, pixel coordinates, and sample indices.

[0036] The vertex-level, primitive-level, and pixel-level graphics stage sets are determined based on the multiple graphics stages included in the graphics pipeline. In some possible implementations, all graphics stages are divided into three sets according to the type of rendering entities processed by each stage in the graphics pipeline: stages primarily processing vertices are classified as vertex-level graphics stage sets; stages primarily processing primitives are classified as primitive-level graphics stage sets; and stages primarily processing pixels and fragments are classified as pixel-level graphics stage sets. In other possible implementations, graphics stages are dynamically assigned to corresponding sets based on the actual type of rendering entities output by each graphics stage (vertex, primitive, pixel). For example, the vertex-level graphics stage set includes: Input Assembly (IA), Vertex Shading (VS), Shell Shading (HS), Domain Shading (DS); the primitive-level graphics stage set includes: Geometry Shading (GS), Primitive Assembly (PA), Rasterization (Raster); and the pixel-level graphics stage set includes: Pixel Shading (PS), Depth Testing (D / T), Output Merging (OM).

[0037] Based on the above technical means, using anchor point data, vertex-level processing links, primitive-level processing links, and pixel-level processing links can be automatically reconstructed. This allows for the automatic reconstruction of the complete processing link from vertex to pixel of a rendered entity, enabling rapid location of the pipeline stage where the earliest discrepancy occurs and significantly improving the efficiency of discrepancy localization.

[0038] In some embodiments, a vertex-level processing link is generated for any two adjacent vertex stages in the vertex-level graphics stage set, provided that the output vertex identifier of one vertex stage is the same as the input vertex identifier of the other vertex stage. For example, taking any two adjacent vertex stages as input assembly and vertex shading, if the output vertex identifier of the input assembly is the same as the input vertex identifier of the vertex shading, a processing link from input assembly to vertex shading corresponding to the rendered entity is generated, until all adjacent vertex stages in the vertex-level graphics stage set have been analyzed, thus generating a vertex-level processing link.

[0039] A primitive-level processing link is a processing link generated for any two adjacent primitive stages in a primitive-level graphics stage set, provided that the output primitive identifier of one primitive stage is the same as the input primitive identifier of the other primitive stage. For example, taking geometry shading and primitive assembly as any two adjacent primitive stages, if the output primitive identifier of geometry shading is the same as the input primitive identifier of primitive assembly, a processing link from geometry shading to primitive assembly corresponding to the rendered entity is generated. This process continues until all adjacent primitive stages in the primitive-level graphics stage set have been analyzed, resulting in a primitive-level processing link.

[0040] A pixel-level processing link is generated when the output pixel coordinates and output sample index of one pixel stage are the same as the input pixel coordinates and input sample index of the other pixel stage within the pixel-level graphics stage set. For example, taking pixel shading and depth testing as two adjacent pixel stages, if the output pixel coordinates and output sample index of pixel shading are the same as the input pixel coordinates and input sample index of depth testing, a processing link from pixel shading to depth testing corresponding to the rendered entity is generated. This process continues until all adjacent primitive stages in the pixel-level graphics stage set have been analyzed, resulting in a pixel-level processing link.

[0041] Based on the above technical means, by defining the associated anchor points between adjacent graphics stages in the graphics pipeline, the vertex-level processing link, primitive-level processing link, and pixel-level processing link corresponding to the rendered entity can be automatically reconstructed, thereby facilitating subsequent difference localization.

[0042] For the above discrepancy analysis process, in some possible implementations, the first log data of each graphics stage (vertex, primitive, and pixel) is compared stage by stage according to the rendering order defined in the rendering chain of the rendering entity. Once a discrepancy is detected in a certain graphics stage, that graphics stage is directly identified as the earliest target graphics stage with a discrepancy, and the comparison of subsequent graphics stages is terminated. In other possible implementations, the existence of a discrepancy is first determined by the final pixel-level rendering result, and then the first log data of each graphics stage is traced back from the end to the beginning. The pixel-level stage, primitive-level stage, and vertex-level stage are compared until the position where the states of the preceding and following stages are consistent, but the current graphics stage is the first to show a discrepancy, is found, and that stage is identified as the earliest target graphics stage with a discrepancy.

[0043] Based on the aforementioned technical means, the rendering link corresponding to a rendering entity is determined based on the anchor point data connecting adjacent graphics stages in the pre-set graphics pipeline. Since the anchor point data is constructed based on the attributes of the rendering entity, and the rendering link of a rendering entity represents the rendering link from the vertex to the pixel corresponding to the rendering entity, the corresponding vertex-to-pixel rendering link can be automatically constructed for each rendering entity. Therefore, when differences occur in the rendering of a rendering entity by the graphics pipeline, difference analysis is performed using the first log data of the corresponding graphics stage according to the vertex-to-pixel rendering link of the rendering entity. This identifies the target graphics stage with the earliest difference among multiple graphics stages, without manual intervention, and automatically identifies the earliest difference stage, improving the efficiency of difference localization.

[0044] In some embodiments, the step S102 above, "according to the rendering order defined in the rendering chain of the rendering entity, performing difference analysis using the first log data of the corresponding graphics stage, and determining the target graphics stage with the earliest difference among multiple graphics stages," can be implemented through the following steps S111 to S114: Step S111: For each piece of first log data, perform a standardized mapping to obtain second log data.

[0045] The standardization mapping is used to map the first log data into a standard format. In some embodiments, each collected field in the first log data is mapped according to a defined standard data structure. For example, the first log data may be the following logical fields: schema_version; stage (e.g., IA / VS / HS / DS / GS / Raster / PS / D / T / OM / ComputeWrite, etc.); anchors (e.g., draw_id, primitive_id, vertex_id, instance_id, pixel_x, pixel_y, sample_index, resource_id, etc.); payload (e.g., transformed coordinates, interpolation attributes, depth, color, write-back data, etc.); seq_id, ts (sorting / playback support); meta (e.g., field source, adapter version, completion flags, etc.).

[0046] Step S112: In the case of second log data with different architectures, perform architecture mapping on the second log data with different architectures to obtain the corresponding third log data.

[0047] When the second log data to be compared comes from different GPU architectures, different simulation implementations, and different driver versions, the field names and data meanings of these second log data may differ. Through architecture mapping, the second log data of each architecture is normalized and semantically transformed according to unified rules, and converted into standardized logs (i.e., third log data) with consistent structure and semantic equivalence, so as to facilitate subsequent cross-architecture difference comparison.

[0048] In some possible implementations, a set of field mapping rule tables is pre-configured for each GPU architecture or version. During mapping, the corresponding mapping table is loaded according to the architecture type, and the fields of the second log data are mapped one by one to generate the third log data. In other possible implementations, corresponding version information is pre-defined for each GPU architecture or version, and each second log data carries its version information. Based on the version information, the corresponding parser and mapping logic are selected to perform structured parsing, field normalization, and semantic transformation on the second log data, outputting third log data with a uniform format.

[0049] Step S113: In the absence of second log data with a different architecture, the second log data is identified as the third log data.

[0050] When the two sets of second log data participating in the comparison come from the same GPU architecture, the same driver version, or the same simulation platform, and their field meanings, stage naming, and data formats are already consistent and there is no need to perform cross-architecture format conversion, the original second log data is directly used as the third log data for difference comparison, and no additional architecture mapping and format normalization processing is performed.

[0051] Step S114: According to the rendering order defined in the rendering chain of the rendering entity, perform difference analysis using the third log data of the corresponding graphics stage to determine the target graphics stage with the earliest difference among multiple graphics stages.

[0052] In some possible implementations, the third log data of each graphics stage—vertex, primitive, and pixel—is compared stage by stage according to the rendering order defined in the rendering chain of the rendering entity. Once a difference is detected in a certain graphics stage, that stage is directly identified as the earliest target graphics stage with the difference, and the comparison of subsequent graphics stages is terminated. In other possible implementations, the difference is first determined by the final pixel-level rendering result, and then the third log data of each graphics stage is traced back from the end to the beginning. The pixel-level stage, primitive-level stage, and vertex-level stage are compared until the position where the states of the preceding and following stages are consistent, and the current graphics stage is the first to show inconsistency, is found, and that stage is identified as the earliest target graphics stage with the difference.

[0053] Based on the above technical means, through standardized mapping and architecture mapping, the first log data of different GPU architectures, different simulation implementations and different driver versions are converted into comparable third log data, which facilitates subsequent unified storage, analysis and comparison, and also makes the analysis tool more reusable during cross-generational verification, reducing maintenance costs.

[0054] In some embodiments, the difference localization method for graphical pipelines provided in this application further includes querying third log data, which may specifically include: in response to a query instruction, querying the corresponding stored record from a table storing the third log data based on the anchor point data or payload data to be queried carried by the query instruction.

[0055] The third log data is stored in a preset format. In some embodiments, the preset format may include coexistence and table partitioning. That is, third log data from different stages can be stored in the same table and distinguished by stage, or stored in separate tables, depending on the scale of the project and query performance requirements.

[0056] In some embodiments, after obtaining the third log data, the third log data can be stored in a structured manner (e.g., relational, columnar, time-series, or NoSQL), but the following conditions must be met: anchor data is indexed as a retrieval / association primary key; stage identifiers and version information are used to record different sub-stages of different architectures; and appropriate indexes or signature fields are created for the payload data (used for comparison and filtering). Table 1 shows one storage method for geometric sub-stages, and Table 2 shows one storage method for rasterization and fragment sub-stages. Both Table 1 and Table 2 include sub-stage log types, anchor data, and payload data.

[0057] Table 1

[0058] Table 2

[0059] In some possible implementations, the user or upper-level tools can perform query operations on the table storing the third-party log data, retrieve the table storing the third-party log data by the anchor data to be queried or the payload data to be queried, and export the filtered results into a standardized data format for offline analysis or import into third-party tools.

[0060] Based on the above technical means, by using anchor data or payload data as indexes, accurate and fast retrieval of third-party log data can be achieved without traversing the entire log data.

[0061] In some embodiments, the first log data includes version information; the version information represents the format version number of the first log data; the "normalizing and mapping the first log data to obtain the second log data" in step S111 above can be implemented by the following steps S121 and S122: Step S121: Determine the correspondence between the original fields and the standardized fields based on the version information.

[0062] Each version of the information has a mapping rule between its original fields and a unified standardized field. In some embodiments, the version information may be the format version number of the first log data.

[0063] In some possible implementations, an independent field mapping table can be pre-configured for each version number, representing the correspondence between raw fields and standardized fields. The version number of the current first log data is used as an index to find the corresponding field mapping table, thus determining the one-to-one correspondence between raw fields and standardized fields. In other possible implementations, based on the version information, the field parsing rules and semantic definitions corresponding to that version information are loaded, and the correspondence between raw fields and standardized fields is dynamically derived and generated.

[0064] Step S122: Based on the correspondence between the original fields and the standardized fields, the first log data is standardized and mapped to obtain the second log data.

[0065] In some possible implementations, each collected field in the first log data is iterated through, and according to the established correspondence between the original fields and standardized fields, each field is replaced with a standardized field name and value, directly assembling the data to generate standardized second log data. In other possible implementations, the first log data is parsed into a structured object according to a predefined data structure, and then the overall structure is mapped based on the correspondence between the original fields and standardized fields to output structured second log data.

[0066] Based on the above technical means, by establishing field correspondence through version information, heterogeneous logs can be uniformly mapped to a standardized format, eliminating comparison barriers caused by architectural differences and realizing unified processing of cross-architecture and cross-version logs.

[0067] In some embodiments, the step S122 above, "based on the correspondence between the original fields and the standardized fields, the first log data is standardized and mapped to obtain the second log data", can be implemented through the following steps S131 to S133: Step S131: For each collected field in the first log data, determine the target standardized field corresponding to the collected field based on the correspondence between the original field and the standardized field.

[0068] In some embodiments, based on the correspondence between the original fields and the standardized fields, the target original field corresponding to the collected field is found, and the standardized field corresponding to the target original field is determined as the target standardized field.

[0069] Step S132: For each collected field, determine the field value corresponding to the target standardized field based on the field value corresponding to the collected field.

[0070] In some possible implementations, if the meaning of the field value corresponding to the collected field is completely consistent with the meaning of the field value specified by the standardized field, then no calculation or conversion is needed, and the field value corresponding to the collected field is directly assigned to the standardized field. In other possible implementations, if the meaning of the field value corresponding to the collected field is different from the meaning of the field value specified by the standardized field, it is converted according to the defined rules as needed to obtain the field value corresponding to the standardized field.

[0071] Step S133: Generate second log data based on the field values ​​corresponding to each of the target standardized fields.

[0072] In some possible implementations, each target standardized field and its corresponding value are written into a structured object one by one according to the standardized format requirements, and then concatenated to generate complete second log data. In other possible implementations, based on a predefined standardized log template, the transformed field values ​​are filled into the corresponding template positions according to their names, generating standardized second log data in one go.

[0073] Based on the above technical means, by standardizing and mapping each collected field in the first log data, the second log data can be obtained. The first log data can be transformed into second log data with a unified structure, so as to facilitate unified storage and subsequent difference analysis, thereby improving analysis efficiency.

[0074] In some embodiments, the step S112 above, "performing architecture mapping on the second log data of different architectures to obtain their respective corresponding third log data", can be implemented by the following steps: for each second log data in the second log data of different architectures, based on predefined architecture mapping rules, performing architecture mapping on each target normalized field in the second log data to obtain the third log data.

[0075] The predefined architecture mapping rules include, but are not limited to: field name mapping, enumeration value normalization, unit conversion, format conversion, and missing field padding. Field name mapping can directly replace field names using a key-value pair mapping table; for example, replacing `prim_id` and `triangle_id` with `primitive_id`. Enumeration value normalization can convert architecture-specific enumerations to standard enumerations using an enumeration lookup table; for example, converting `raster_mode` and `depth_test_enum`. Unit conversion can be performed using fixed coefficients; for example, pixel coordinates, depth range, and coordinate space scaling. Format conversion can include: data type conversion (fixed-point to floating-point conversion) / byte order conversion, coordinate system normalization, etc. Missing field padding can use default values, or it can be left blank, or it can be derived from associated fields (calculating missing fields based on existing anchor points).

[0076] By using preset architecture mapping rules (field name mapping, enumeration value normalization, unit conversion, format conversion, missing field completion, etc.), the standardized fields of each second log data are transformed across architectures to obtain third log data that can be directly used for difference comparison.

[0077] Based on the above technical means, architecture mapping ensures that information with the same meaning has consistent field representation in logs from different sources, avoiding matching errors caused by inconsistent field names and meanings, and improving the accuracy of subsequent difference analysis.

[0078] In some embodiments, the load data is used for difference comparison in the difference analysis; the step S114 above, "according to the rendering order defined in the rendering chain of the rendering entity, performing difference analysis using the third log data of the corresponding graphics stage, and determining the target graphics stage with the earliest difference among multiple graphics stages", can be implemented through the following steps S141 to S143: Step S141: Determine the current graphics stage for differential analysis according to the rendering order defined in the rendering chain of the rendered entity.

[0079] In some embodiments, the corresponding graphics stages can be determined as the current graphics stage from front to back according to the rendering order defined in the rendering chain of the rendering entity. For example, if the rendering order defined in the rendering chain of the rendering entity is input assembly, vertex shading, hull shading, domain shading, geometry shading, rasterization, pixel shading, depth testing, and output merging, the input assembly is first determined as the current graphics stage. After the difference analysis of the input assembly is completed, if the target graphics stage is not found, the vertex shading is then determined as the current graphics stage, and difference analysis is performed until the target graphics stage is found.

[0080] Step S142: Determine the reference data corresponding to the comparison load data of the rendered entity in the current graphics stage.

[0081] The load data to be compared can be the load data used for comparison within the load data set, while the reference data is the baseline load data, serving as the comparison benchmark for the load data to be compared. The load data to be compared can be obtained through debugging, and the reference data can be stored in a reference library. In some embodiments, each graphics stage has corresponding load data to be compared, as shown in Tables 1 and 2 above. The load data in Tables 1 and 2 are the load data to be compared at this point.

[0082] The payload data to be compared in the current graph phase is determined based on the third log data of the current graph phase. In some embodiments, the third log data includes the payload data to be compared.

[0083] In some possible implementations, the reference data corresponding to the load data to be compared can be determined based on the sequence number. In other possible implementations, the reference data corresponding to the load data to be compared can be determined based on the order.

[0084] Step S143: Determine the target graphic stage based on the load data to be compared and the benchmark data.

[0085] In some possible implementations, the load data to be compared in the current graphics stage is compared with the corresponding benchmark data. If the comparison results show differences, i.e. inconsistency, the current graphics stage is determined as the target graphics stage.

[0086] Based on the above technical means, the current graphics stage is determined according to the rendering order defined in the rendering chain of the rendering entity, and the target graphics stage with the earliest difference is obtained by comparing the load data to be compared with the benchmark data of the current graphics stage. No manual intervention is required, which can realize automated positioning and improve the efficiency of difference analysis.

[0087] In some embodiments, the step S142 above, "determining the reference data corresponding to the comparison load data of the rendered entity in the current graphics stage", can be achieved through the following steps S151 and S152: Step S151: If the load data to be compared has a corresponding serial number, the reference data with the same serial number as the load data to be compared is determined as the reference data corresponding to the load data to be compared.

[0088] The sequence number is used to identify the reference data corresponding to the load data to be compared. In some embodiments, the sequence number can be the accumulation of sub-stages within the anchor data.

[0089] Regarding the above-mentioned method of determining the reference data corresponding to the load data to be compared based on the serial number, the reference data with the same serial number as the load data to be compared can be determined as the reference data corresponding to the load data to be compared.

[0090] In some embodiments, the reference data is stored in advance in the form of key-value pairs of sequence number-reference data (e.g., hash table). Each load data to be compared is traversed, its sequence number is extracted, the location is directly determined by looking up the table, and the reference data with the same sequence number is extracted and identified as the corresponding reference data.

[0091] Step S152: If the load data to be compared does not have a corresponding sequence number, determine the reference data corresponding to the load data to be compared according to the respective order of the load data to be compared and the reference data.

[0092] Regarding the above-mentioned determination of the reference data corresponding to the load data to be compared based on the order, the reference data corresponding to the load data to be compared can be determined according to the respective order of the load data to be compared and the reference data.

[0093] In some possible implementations, the payload data to be compared and the baseline data are assigned consecutive indices (e.g., 0, 1, 2, ...) according to their generation order (e.g., the execution order of the graphics pipeline). The baseline data with the same index is identified as the baseline data corresponding to the payload data to be compared; that is, the payload data to be compared at index i corresponds to the baseline data at index i. In other possible implementations, the payload data to be compared and the baseline data are first grouped according to the graphics stage. Within the same graphics stage, the payload data to be compared and the baseline data are sequentially matched according to the order in which the data is generated (e.g., the order in which the rendered entities flow through the stage) to determine the baseline data corresponding to the payload data to be compared.

[0094] Based on the above technical means, by determining the reference data through serial numbers or order, a one-to-one correspondence between the load data to be compared and the reference data can be achieved, avoiding matching errors, providing a reliable correspondence basis for subsequent difference analysis, and improving the accuracy of difference location.

[0095] In some embodiments, the "determine the target graphic stage based on the load data to be compared and the reference data" in step S143 above can be implemented by the following steps S161 to S164: Step S161: Determine the field type of each load field to be compared in the load data to be compared.

[0096] In some embodiments, the payload data to be compared may include multiple payload fields to be compared, and the field types of the multiple payload fields to be compared may be the same or different. For example, referring to Table 1 above, for the vertex shading stage, the multiple payload fields to be compared may include: vertex input attributes, transformed vertex coordinates, output interpolation attributes, etc.

[0097] The field types of the load fields to be compared can include: numeric fields, enumerated fields, Boolean fields, and transient fields. Numeric fields take continuous floating-point numbers or integers, such as vertex coordinates, depth values, and color components. Enumerated fields take a limited number of fixed values, such as primitive type and stage. Boolean fields take only 0 / 1 and true / false values, such as data validity markers. Transient fields change randomly with each run, such as timestamps.

[0098] In some possible implementations, corresponding keyword, prefix, or suffix rules can be pre-configured for the four field types; the field type is automatically determined based on the field name matching rules of the payload fields to be compared. In other possible implementations, the type is automatically analyzed and determined based on the characteristics of the actual values ​​of the payload fields to be compared. For example, for Boolean fields, which can only take values ​​of 0 / 1, true / false, etc., this method automatically identifies the type through data characteristics.

[0099] Step S162: For each load field to be compared, determine the comparison rule corresponding to the load field to be compared based on the field type corresponding to the load field to be compared.

[0100] The comparison rules corresponding to the load fields to be compared are used to determine the target graphic stage in the difference analysis. The comparison rules corresponding to the load fields to be compared may include: supporting preset tolerance ranges, comparing one by one, ignoring, etc.

[0101] In some possible implementations, the mapping relationship between field types and comparison rules can be pre-configured. Based on the field type corresponding to the field to be compared, the corresponding comparison rule can be obtained by querying the mapping relationship between field types and comparison rules.

[0102] Step S163: Determine the comparison rules for the load data to be compared based on the comparison rules corresponding to all the load fields to be compared.

[0103] The comparison rules for the load data to be compared include the comparison rules corresponding to all the load fields to be compared.

[0104] In some possible implementations, the comparison rules corresponding to all the load fields to be compared can be combined to obtain the comparison rules for the load data to be compared.

[0105] Step S164: Determine the target graphic stage based on the load data to be compared, the reference data, and the comparison rules of the load data to be compared.

[0106] In some possible implementations, the load data to be compared is compared with the corresponding reference data based on the comparison rules of the load data to be compared. If the comparison results show differences, i.e., inconsistencies, the current graphics stage is determined as the target graphics stage. For example, if there is a load field to be compared in the load data to be compared, and a difference is found when comparing it with the reference field based on its corresponding comparison rules, then the current graphics stage is determined as the target graphics stage. Here, the reference field is the field in the reference data that corresponds to the load field to be compared.

[0107] Based on the above technical means, by determining the corresponding comparison rules based on the field type of the load field to be compared, and performing difference analysis based on the comparison rules, the accuracy of difference judgment can be improved.

[0108] In some embodiments, the step S162 above, "determining the comparison rule corresponding to the field of the payload to be compared based on the field type of the field to be compared", can be achieved through the following steps S171 to S173: Step S171: If the field type of the load field to be compared is a numeric field, determine that the comparison rule of the load field to be compared is to support the preset tolerance range.

[0109] When the field to be compared is identified as a numeric field, the comparison rule set for that field is no longer strictly equal. Instead, it allows the difference between the field value of the field to be compared and the field value of the reference field. As long as the difference is within a pre-defined tolerance range, the values ​​are considered to be identical. In other words, floating-point numbers and integers are not required to be exactly the same; as long as the error is within the allowable range, they are considered to be indistinguishable.

[0110] Under different GPU architectures and different precision calculations, numerical fields may have slight errors. Using tolerance comparison can eliminate these non-functional differences and identify the real differences.

[0111] Step S172: If the field type of the payload field to be compared is an enumeration or a Boolean field, determine that the comparison rule for the payload fields to be compared is to compare them one by one.

[0112] When the type of the load field to be compared is an enumerated field or a Boolean field, since these fields only represent finite or discrete states, the comparison rule configured for them is a strict equality comparison one by one. That is, the field value of the load field to be compared is compared with the field value of the benchmark field one by one. Only when the two are completely consistent is it determined that there is no difference; otherwise, it is determined that there is a difference.

[0113] Step S173: If the field type of the load field to be compared is a transient field, determine that the comparison rule for the load field to be compared is to ignore.

[0114] When the field type of the payload field to be compared is a transient field, this field will not be included in the comparison range during the difference comparison process. The comparison of the value of this field will be skipped directly, and its change will not be judged as a rendering difference.

[0115] Transient fields change with each execution, and if they are included in the comparison, they will generate a large number of false differences. Setting them to ignore ensures that the difference judgment only focuses on the real rendering issues, avoids false differences, and improves the accuracy of difference location.

[0116] Based on the above technical means, strict comparison is performed on Boolean and enumeration fields, tolerance is supported for numerical fields, and transient fields are directly ignored, avoiding false alarms caused by floating-point errors, timestamps, etc., which can improve the accuracy of difference location.

[0117] In some embodiments, the "determining the target graphic stage based on the comparison rules of the load data to be compared, the reference data, and the load data to be compared" step S164 above can be implemented through the following steps S181 and S182: Step S181: For each load field to be compared, the load field to be compared and the benchmark field are compared based on the comparison rules corresponding to the load field to be compared, and the comparison result is obtained.

[0118] In some embodiments, when the comparison rule corresponding to the load field to be compared supports a preset tolerance range, if the load field to be compared and the reference field do not differ, or the difference is within the allowable preset tolerance range, the comparison result is the same; otherwise, the comparison result is different. When the comparison rule corresponding to the load field to be compared is to compare one by one, if the load field to be compared and the reference field are completely identical, the comparison result is the same; otherwise, the comparison result is different. When the comparison rule corresponding to the load field to be compared is to ignore, the comparison result can be ignored.

[0119] Step S182: If there is a difference in the comparison results, the current graphic stage is determined as the target graphic stage.

[0120] If the comparison results show differences, it indicates that there is a discrepancy between the load field to be compared and the baseline field in the load data to be compared. At this point, the earliest graphical stage with the difference is found, and the current graphical stage is determined as the target graphical stage.

[0121] Based on the above technical means, each load field to be compared is compared according to the corresponding comparison rules to obtain the comparison results, which can improve the accuracy of difference analysis.

[0122] In some embodiments, the difference localization method for the graphics pipeline provided in this application further includes generating difference records, which may specifically include generating difference records based at least on difference identifiers, target graphics stages, anchor point data, and difference summaries.

[0123] The difference record should include at least the difference identifier (diff_id), anchor data (anchors), difference summary (field_diffs), and target graph stage (stage). Of course, as shown in Table 3 below, the difference record may also include: sequence number, time stamp, difference processing status, etc.

[0124] Among them, the difference summary represents the comparison payload data and the corresponding baseline data that show differences during the difference analysis process; the difference identifier is a unique identifier for the difference record, used to distinguish multiple different difference records; the target graphics stage is the graphics stage where the difference occurs earliest; and the anchor point data is the set of anchor points used to locate the rendered entities.

[0125] Table 3

[0126] Furthermore, to facilitate users' subsequent analysis and presentation of the differences obtained from the comparison, this application stores the identified differences in a structured record database and provides query and export interfaces for upper-level tools (such as desktop or web applications) to filter, sort, replay triggers, and perform causal analysis. For example, this application provides basic data access capabilities for users or upper-level tools to operate on the difference records, including but not limited to: retrieving difference records by anchor data, stage identifier, time identifier, or difference processing status, and exporting the filtered results into a standardized data format for offline analysis or importing into third-party tools.

[0127] Based on the above technical means, the differences are recorded in a structured manner to achieve complete retention and traceability of the difference information, which facilitates subsequent backtracking of problems and reproduction of differences.

[0128] In some embodiments, the graphics pipeline further includes a computation stage; the difference localization method for the graphics pipeline provided in this application embodiment further includes steps S191 and S192: Step S191: If an abnormality is detected during the graphics stage reading, obtain the resource coordinates corresponding to the reading operation.

[0129] Among them, graphics stage read exceptions refer to abnormal situations that occur in a certain graphics stage of the graphics pipeline when performing operations to read data from resources such as memory, buffers, and textures, such as reading errors, invalid data, inability to read, or data that does not match expectations.

[0130] Resource coordinates are used to locate the coordinates of data storage locations within GPU resources, enabling precise location of read anomalies and tracing upstream computational data. In some embodiments, resource coordinates may include: texture coordinates, thread coordinates, pixel coordinates, buffer addresses, primitive indexes, etc.

[0131] In some possible implementations, when a read exception is detected, the base address of the currently executing buffer is captured, and the corresponding resource coordinates (e.g., pixel coordinates (x, y), texture coordinates (u, v), thread group coordinates, etc.) are deduced through address mapping. In other possible implementations, when a read exception is detected during the graphics stage, the recorded exception resource coordinates are read directly from the GPU hardware exception register, debug port, or exception packet.

[0132] Step S192: Add the calculation data of the calculation stage corresponding to the resource coordinates to the first log data in order to analyze the read anomaly.

[0133] In some embodiments, the computational data may include computational results and intermediate results corresponding to the computational stage.

[0134] In some embodiments, the computation writing in the computation phase and the graphics reading in the graphics phase can be associated through anchor point data. For example, anchor point data may include resource coordinates, as shown in Table 4 below.

[0135] Table 4

[0136] In some embodiments, based on resource coordinates, the corresponding graphics stage is found in reverse, and the calculated data corresponding to the resource coordinates is added to the first log data of the corresponding graphics stage, thereby realizing the root cause analysis of read anomalies.

[0137] In some possible implementations, the resource coordinates are used as keys to index the original computation data at the corresponding location in the output results of the computation phase, and this computation data is appended to the first log data. In other possible implementations, the corresponding computation thread or computation task is located based on the resource coordinates, the local computation process is retried, the input, intermediate values ​​and output results during the computation process are collected, and these are added to the first log data.

[0138] Based on the above technical means, the write operation in the calculation stage and the read operation in the graphics stage can be linked by resource coordinates, which facilitates the automatic tracking of the causal relationship between calculation and graphics and enhances the ability to locate problems across stages.

[0139] The GPU debugging and analysis system (i.e., the graphics pipeline differential localization system) and the graphics pipeline differential localization method provided in this application embodiment will be described in detail below with reference to specific application scenarios.

[0140] The GPU debugging and analysis system provided in this application embodiment is discussed in detail from five aspects: system architecture, standardized data model and adapter mechanism, adjacent stage anchor point design, difference comparison and location method, and debugging intermediate layer embedding strategy.

[0141] 1.1 System Architecture.

[0142] The GPU debugging and analysis system proposed in this application comprises two parts: a data acquisition layer and an analysis layer. The data acquisition layer is embedded in the GPU's modeling / simulation environment or serves as an independent debugging intermediate layer. It generates structured logs (i.e., the aforementioned first log data) at predetermined pipeline checkpoints (such as vertex output, primitive assembly, post-rasterization, pixel, fragment shading before and after, depth / stencil testing, output merging, etc.) and reliably transmits them to the analysis layer. Each log entry uses observable semantics at the graphics API level as anchor points, including common anchor point fields (such as draw call identifier, primitive identifier, vertex identifier, pixel coordinates, etc.) and stage-specific fields. The analysis layer receives and stores these raw logs, retrieves them through an index (anchor data), and then calls an adapter to map them to a unified, normalized data model for subsequent comparison and tracing analysis.

[0143] 1.2 Standardized data model and adapter mechanism.

[0144] This application defines a unified, standardized data model, which includes a set of common fields and their semantic descriptions, such as draw_id (draw call identifier), primitive_id (primitive identifier), vertex_id (vertex identifier), instance_id (instance identifier), pixel coordinates (pixel), sample_index (sample index), resource_id (resource identifier), and stage (graphics stage). Each field specifies the data type, comparison strategy, and version information.

[0145] For different GPU simulation implementations or architecture versions, an adapter module is used to process the original log fields by performing alias mapping, enumeration unification, unit conversion, or missing value imputation, converting them into a normalized model representation. Each log record includes schema version information, and the analysis layer selects the corresponding adaptation strategy based on the version during parsing to achieve cross-version compatibility.

[0146] 1.3 Anchor point design for adjacent stages.

[0147] This application's embodiments employ adjacent stage anchor point association logs instead of a single global identifier. Example anchor points for each adjacent stage include: vertex identifier `vertex_id` for input assembly to the vertex shading stage; primitive identifier `primitive_id` for primitive assembly to the rasterization stage; pixel coordinates `pixel` and sample index `sample_index` for rasterization to the fragment stage; and `resource_id` and write / read coordinate information for computation and writing to the graphics read stage. Through these anchor points, the GPU debugging and analysis system can construct an end-to-end processing chain from vertex to final pixel output in the normalized data layer within the analysis layer.

[0148] 1.4 Difference Comparison and Positioning Methods.

[0149] Log records are organized hierarchically according to the drawing call identifier (draw_id), primitive identifier (primitive_id), pixel coordinates (sample_index), and graphics stage, forming basic comparison units. Log entries are paired within the same anchor point range, preferentially using sequence numbers for one-to-one correspondence; if no sequence number exists, sequential alignment is used for matching. Then, normalized fields are compared item by item: numeric fields support specified tolerance ranges, enumerated and boolean fields are strictly compared, and transient fields such as timestamps can be ignored. The comparison results are used to sequentially identify the stage where the same primitive or pixel first shows a difference along the pipeline, marking it as the earliest difference stage and outputting its location information.

[0150] For cross-stage causal relationships, when the graphics stage detects an abnormal reading value, the system retrieves the previously calculated data for the same resource coordinates from the normalized data and writes it to the log, establishing a correlation chain from the calculation stage to the graphics stage to help trace the root cause.

[0151] 1.5 Debugging the intermediate layer embedding strategy.

[0152] This application proposes integrating log collection as an independent debugging middleware layer into the environment under test. Key features include: providing a unified log submission interface based on graphics API semantics, which the GPU simulation model or the module under test calls to submit logs after completing each visible API operation; decoupling the collection process from the GPU's main functional path to ensure that it does not affect the functional behavior of the module under test; and recording optional internal fields (such as tile indexes) in the simulation environment as auxiliary information, but marking them as internal simulation fields in the normalized model and not using them as necessary anchor points.

[0153] The method for locating differences in the graphical pipeline provided in this application is discussed in detail from eight aspects: overall design and boundaries, log collection and serialization methods, normalized model (Schema) and Adapter mapping (analysis layer), normalized log storage and indexing strategies, log field structure and anchor point relationship between adjacent stages, entity model and one-to-one correspondence guarantee, difference identification and stage location, and structured storage and export of difference points.

[0154] 2.1 Overall Design and Boundaries.

[0155] This application's embodiments do not only compare the final rendering results, but also collect structured debug logs with clear semantics and anchor relationships at multiple stages of GPU graphics and computing units. Through a unified normalization model, data from different implementations, versions, and log formats are mapped, enabling unified storage, association, and subsequent processing at the analysis layer.

[0156] This application emphasizes data semantic consistency and anchor point design, without limiting specific transmission protocols or underlying storage implementations. The comparison algorithm can be an independent module, and the comparison is mainly based on normalized one-to-one correspondence verification (primarily non-fuzzy matching).

[0157] 2.2 Log collection and serialization methods.

[0158] 2.2.1 Data collection location.

[0159] Log collection can occur at the debug interface layer of GPU emulators, functional models, verification models, or real hardware. Each log entry, when generated, contains at least: a graphics stage; anchor data; payload data for difference comparison during difference analysis; sequence number or time information (seq_id / timestamp); and schema version information (schema_version).

[0160] The acquisition layer can select any format for serialization and writing or transmission according to the scenario: JSON: suitable for scenarios with small-scale debugging and requiring human readability; JSONL (JSON Lines): one line per log, suitable for streaming generation and incremental parsing; Binary format (BIN): fixed-length fields or TLV encoding, suitable for large-scale logs and high-performance writing; Compressed encapsulation format: compress any of the above formats (e.g., zip, zstd, etc.) for offline analysis or log archiving.

[0161] Logs are not directly compared at the analysis layer. Instead, they first undergo schema mapping and normalization to convert raw logs from different sources and with different field layouts into a unified normalized record structure.

[0162] 2.3 Standardized Schema and Adapter Mapping.

[0163] 2.3.1 Schema standardizes the record structure.

[0164] Map the raw logs to the following logical fields: schema_version; stage (IA / VS / HS / DS / GS / Raster / PS / D / T / OM / ComputeWrite, etc.); anchors (a set of anchor points, such as draw_id, primitive_id, vertex_id, instance_id, pixel_x, pixel_y, sample_index, resource_id, etc.); payload (stage-specific data, such as transformed coordinates, interpolation attributes, depth, color, write-back data, etc.); seq_id, ts (sorting / replay support); meta tags (field source, adapter version, completion tags, etc.).

[0165] 2.3.2 Adapter mapping.

[0166] Perform the following actions on raw logs from different sources: field alias mapping (e.g., prim_id, triangle_id-primitive_id); enumeration value normalization (e.g., raster_mode, depth_test_enum); unit / format conversion (fixed-point to floating-point, coordinate system normalization, etc.); and complete missing fields and label their source (raw / derived / default).

[0167] Version 2.3.3 Management.

[0168] Each normalized record carries a schema_version, and the analysis layer processes historical data according to version branches or compatibility strategies.

[0169] 2.4 Standardized log storage and indexing strategies.

[0170] 2.4.1 Warehousing principles.

[0171] Write normalized records into structured storage (relational, columnar, time-series, or NoSQL), but the following must be met: anchor data (anchors) should be indexed as the primary key for retrieval / association; the schema_version field should be used to distinguish different types of records and record different sub-stages of different architectures; and appropriate indexes or signature fields should be created for key payload data (used for comparison and filtering).

[0172] 2.4.2 Coexistence and Table Separation.

[0173] Logs from different stages can be stored in the same table and distinguished by stage, or stored in separate tables, depending on the scale of the project and the query performance requirements.

[0174] 2.5 Log field structure and relationship with adjacent stage anchor points.

[0175] Auxiliary fields and internal extended fields: Each log record contains schema version information (schema_version), sequence number (seq_id), and timestamp, etc., for compatibility management and sorting. Optional internal auxiliary fields (such as tile indexes) can also be recorded in the simulation environment, but they are marked as simulation internal fields in the normalized model and are not used as necessary anchor data.

[0176] 2.6 Entity model and one-to-one correspondence guarantee.

[0177] Entity Definition: At the normalization level, a set of entities is abstracted, such as Draw, Primitive, Vertex, Pixel / Sample, etc., each uniquely identified by its set of anchor points. One-to-One Correspondence Guarantee Mechanism: Anchor points originate from API observable semantics, not internal private IDs; the acquisition layer includes a sequence number (seq_id) or other sequence information to aid in sorting when generating logs; the Adapter ensures semantic alignment during mapping, completing fields and annotating their source; phased logs verify connections through shared anchor points (e.g., the primitive identifier (primitive_id) from the vertex shader VS output appears as an input anchor point in the rasterization stage). Under these guarantees, for the same entity, the same stage, and the same combination of anchor points, Reference and Debug theoretically have only one matching record at the normalization level.

[0178] 2.7 Difference identification and stage positioning.

[0179] 2.7.1 Comparison principle.

[0180] Driven by Reference, one record is retrieved from both the Reference and Debug libraries based on anchor data, and each field is validated (numerical fields are tolerated, enumeration is strict, and transient fields are ignored). The comparison and positioning are based on normalized one-to-one correspondence validation, rather than fuzzy matching.

[0181] 2.7.2 The earliest stage of difference.

[0182] The comparison process involves sequentially comparing the same entity along the complete pipeline stages and determining the earliest discrepancy stage. The recommended stage order is: Input Assembly (IA) - Vertex Shading (VS) - Shell Shading (HS) / Domain Shading (DS) - Geometry Shading (GS) / Mesh Shading - Primitive Assembly (PA) - Rasterization (Raster) - Pixel Shading (PS) - Depth Testing (D / T) - Output Merging (OM). The comparison process checks the comparison results of the same entity at each stage in the above order from front to back: the stage where the first field inconsistency occurs is recorded as the earliest discrepancy stage.

[0183] The ComputeWrite / GraphicsRead phase establishes a horizontal relationship with the graphics phase through resource access anchors to assist in determining cross-phase causality, but it does not replace the earliest difference determination logic along the rendering pipeline described above.

[0184] 2.8 Structured import and export of discrepancies (for use by upper-level tools for causal analysis).

[0185] To facilitate subsequent analysis and visualization of the differences obtained through comparison, this application records the identified differences in a structured manner into a database at the analysis layer and provides query and export interfaces for upper-layer tools (such as desktop or web applications) to filter, sort, replay triggers, and perform causal analysis. This application does not limit or require the system to complete the final causal determination internally; causal analysis is performed by the user or upper-layer tools based on the data provided by the system.

[0186] 2.8.1 Difference Records.

[0187] When the comparison engine identifies a difference or missing value at a certain anchor point at a certain stage, it generates a difference record and writes it to the difference database. Each difference record can be found in Table 3 above.

[0188] 2.8.2 Query and export capabilities (for use by upper-level tools).

[0189] This application provides basic data access capabilities at the analysis layer, allowing users or upper-layer tools to manipulate discrepancy records. This includes, but is not limited to: retrieving discrepancy records by anchor point data, stage identifier, time identifier, or discrepancy processing status; exporting the filtered results into a standardized data format for offline analysis or importing into third-party tools; providing discrepancy records along with corresponding standardized log views (payload snapshots and sequence numbers or time information seq_id / ts for Reference / Debug) for replay or in-depth analysis in upper-layer tools; and writing the discrepancy processing status back to the discrepancy records to support the issue tracking process. The specific implementation of the above functions (interface protocol, export format, visualization implementation, etc.) belongs to the upper-layer tools or engineering implementation.

[0190] The technical solution of this application has many advantages over related technologies: Improved interpretability: Logs directly correspond to graphics API-level semantics, allowing developers and testing teams to intuitively understand and share analysis results, thereby improving the interpretability and collaboration efficiency of the debugging process. Reduced localization time: Utilizing adjacent stage anchors to automatically reconstruct the complete processing chain from vertex to pixel, the earliest pipeline stage where differences occur can be quickly located, significantly improving the efficiency of difference localization. Enhanced cross-version compatibility: Standardized data models and adapter mechanisms ensure consistent comparison semantics for logs across different GPU implementations or versions, making analysis tools more reusable during cross-generational verification and reducing maintenance costs. Support for cross-stage causal analysis: The resource-level anchor mechanism can establish a correlation between computation shader writes and graphics pipeline read operations, facilitating automatic tracking of causal relationships between computation and graphics, enhancing cross-module problem localization capabilities. Facilitates automated verification: Layered comparison and tracing methods based on standardized data can be integrated into automated regression testing processes, improving the reliability and repeatability of verification.

[0191] Based on the above embodiments, this application also provides a differential positioning system for a graphics pipeline. Figure 2 A schematic diagram of the structure of the differential positioning system 20 for the graphic pipeline provided in this application embodiment is shown below. Figure 2 As shown, the differential positioning system 20 of the graphics pipeline includes: The acquisition layer 201 is used to acquire the first log data corresponding to each graphics stage in the graphics pipeline when there are differences in the rendering of the rendered entity in the graphics pipeline. Analysis layer 202 is used to perform difference analysis using the first log data of the corresponding graphics stage according to the rendering order defined in the rendering chain of the rendering entity, and to determine the target graphics stage with the earliest difference among multiple graphics stages; the rendering chain of the rendering entity represents the rendering chain from vertex to pixel corresponding to the rendering entity; the rendering chain of the rendering entity is determined based on the anchor point data connecting adjacent graphics stages in the pre-set graphics pipeline; the anchor point data is constructed based on the attributes of the rendering entity.

[0192] In some embodiments, the analysis layer is further configured to: perform a standardized mapping on each first log data to obtain second log data; perform architecture mapping on the second log data with different architectures when there are second log data with different architectures to obtain corresponding third log data; determine the second log data as third log data when there are no second log data with different architectures; and perform difference analysis using the third log data of the corresponding graphics stage according to the rendering order defined in the rendering chain of the rendering entity to determine the target graphics stage with the earliest difference among multiple graphics stages.

[0193] In some embodiments, the first log data includes version information; the version information represents the format version number of the first log data; the analysis layer is further configured to determine the correspondence between the original fields and the standardized fields based on the version information; and to perform standardized mapping on the first log data based on the correspondence between the original fields and the standardized fields to obtain the second log data.

[0194] In some embodiments, the analysis layer is further configured to: for each collected field in the first log data, determine the target standardized field corresponding to the collected field based on the correspondence between the original field and the standardized field; for each collected field, determine the field value corresponding to the target standardized field based on the field value corresponding to the collected field; and generate second log data based on the field values ​​corresponding to all target standardized fields.

[0195] In some embodiments, the analysis layer is further configured to perform architecture mapping on each target normalized field in the second log data for each second log data with different architectures, based on predefined architecture mapping rules, to obtain third log data; the predefined architecture mapping rules include, but are not limited to: field name mapping, enumeration value normalization, unit conversion, format conversion, and missing field padding.

[0196] In some embodiments, the vertex-to-pixel rendering pipeline is determined based on the vertex-level processing pipeline, the primitive-level processing pipeline, and the pixel-level processing pipeline; the vertex-level processing pipeline is determined based on the vertex-level graphics stage set and anchor point data; the primitive-level processing pipeline is determined based on the primitive-level graphics stage set and anchor point data; the pixel-level processing pipeline is determined based on the pixel-level graphics stage set and anchor point data; and the vertex-level graphics stage set, the primitive-level graphics stage set, and the pixel-level graphics stage set are determined based on the multiple graphics stages included in the graphics pipeline.

[0197] In some embodiments, a vertex-level processing link is generated when the output vertex identifier of one vertex stage is the same as the input vertex identifier of the other vertex stage for any two adjacent vertex stages in the vertex-level graphics stage set; a primitive-level processing link is generated when the output primitive identifier of one primitive stage is the same as the input primitive identifier of the other primitive stage for any two adjacent primitive stages in the primitive-level graphics stage set; a pixel-level processing link is generated when the output pixel coordinates and output sample index of one pixel stage are the same as the input pixel coordinates and input sample index of the other pixel stage for any two adjacent pixel stages in the pixel-level graphics stage set.

[0198] In some embodiments, the first log data includes payload data; the payload data is used for difference comparison in the difference analysis; the analysis layer is further used to determine the current graphics stage for difference analysis according to the rendering order defined in the rendering chain of the rendering entity; determine the baseline data corresponding to the payload data to be compared in the current graphics stage; the payload data to be compared in the current graphics stage is determined based on the third log data of the current graphics stage; and determine the target graphics stage based on the payload data to be compared and the baseline data.

[0199] In some embodiments, the analysis layer is further configured to, when the load data to be compared has a corresponding sequence number, determine the reference data with the same sequence number as the load data to be compared as the reference data corresponding to the load data to be compared; when the load data to be compared does not have a corresponding sequence number, determine the reference data corresponding to the load data to be compared according to the respective order of the load data to be compared and the reference data.

[0200] In some embodiments, the analysis layer is further configured to: determine the field type of each load field to be compared in the load data to be compared; for each load field to be compared, determine the comparison rule corresponding to the load field to be compared based on the field type corresponding to the load field to be compared; determine the comparison rule of the load data to be compared based on the comparison rules corresponding to all load fields to be compared; and determine the target graphics stage based on the load data to be compared, the reference data, and the comparison rule of the load data to be compared.

[0201] In some embodiments, the analysis layer is further configured to: determine that the comparison rule for the load field to be compared is to support a preset tolerance range when the field type of the load field to be compared is a numeric field; determine that the comparison rule for the load field to be compared is to compare one by one when the field type of the load field to be compared is an enumeration or a Boolean field; and determine that the comparison rule for the load field to be compared is to ignore when the field type of the load field to be compared is a transient field.

[0202] In some embodiments, the analysis layer is further configured to, for each load field to be compared, compare the load field to be compared with the benchmark field based on the comparison rule corresponding to the load field to be compared, and obtain a comparison result; if there is a difference in the comparison result representation, determine the current graphics stage as the target graphics stage; the benchmark field is the field in the benchmark data that corresponds to the load field to be compared.

[0203] In some embodiments, the graphics pipeline further includes a computation stage; the analysis layer is also configured to, in the event of a reading anomaly detected in the graphics stage, obtain the resource coordinates corresponding to the reading operation; and add the computation data of the computation stage corresponding to the resource coordinates to the first log data to analyze the reading anomaly.

[0204] In some embodiments, the analysis layer is further configured to, in response to a query instruction, query the corresponding stored record from the table storing the third log data based on the anchor data to be queried or the payload data to be queried carried by the query instruction; the third log data is stored in a preset format.

[0205] In some embodiments, the analysis layer is further configured to generate a difference record based at least on the difference identifier, the target graphic stage, the anchor point data, and the difference summary; the difference summary characterizes the comparison load data and the corresponding benchmark data that show differences during the difference analysis process.

[0206] It should be noted that the layers included in the differential positioning system of the graphics pipeline provided in this application embodiment can be implemented by a processor in an electronic device; of course, they can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), microprocessor unit (MPU), digital signal processor (DSP), or field-programmable gate array (FPGA), etc.

[0207] The description of the system embodiments above is similar to that of the method embodiments above, and has similar beneficial effects. For technical details not disclosed in the system embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0208] It should be noted that, in the embodiments of this application, if the above-described differential positioning system for the graphics pipeline 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 application, 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 described in the various embodiments of this application. 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 application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0209] This application 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.

[0210] 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 referred to interchangeably. The descriptions of the device embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0211] Figure 3This application provides a hardware entity diagram of a computer device as an embodiment of the present application, such as... Figure 3 As shown, the hardware entity of the computer device 300 includes a processor 301 and a memory 302, wherein the memory 302 stores a computer program that can run on the processor 301, and the processor 301 executes the program to implement the steps in the method of any of the above embodiments.

[0212] The memory 302 stores computer programs that can run on the processor. The memory 302 is configured to store instructions and applications that can be executed by the processor 301. It can also cache data to be processed or already processed by the processor 301 and various modules in the computer device 300 (e.g., image data, audio data, voice communication data and video communication data). It can be implemented by flash memory or random access memory (RAM).

[0213] The processor 301 executes the steps of the differential localization method for the graphics pipeline described above when executing the program. The processor 301 typically controls the overall operation of the computer device 300.

[0214] This application provides a computer-readable storage medium storing a computer program or instructions thereon, which, when executed by a processor, implements the steps in any of the differential localization methods for graphics pipelines provided in the above embodiments.

[0215] This application provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, they implement the steps in any of the differential localization methods for graphics pipelines provided in the above embodiments.

[0216] It should be noted that the descriptions of the above embodiments of storage media, devices, systems, and program products are similar to the descriptions of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the embodiments of storage media, devices, systems, and program products of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0217] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0218] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0219] It should be understood that the phrase "one embodiment" or "an 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 application. Therefore, "in one embodiment" or "in an 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 application, 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 application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0220] 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.

[0221] In the several embodiments provided in this application, 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 can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0222] 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.

[0223] Furthermore, in the various embodiments of this application, all functional units 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 a combination of hardware and software functional units. 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 capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0224] 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 application, 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 described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0225] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

[0226] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for differential positioning in a graphical pipeline, characterized in that, The method includes: In the event of discrepancies in the rendering of the rendered entity in the graphics pipeline, the first log data corresponding to each graphics stage in the graphics pipeline is obtained. According to the rendering order defined in the rendering chain of the rendering entity, the first log data of the corresponding graphics stage is used for difference analysis to determine the target graphics stage with the earliest difference among the multiple graphics stages; the rendering chain of the rendering entity represents the rendering chain from vertex to pixel corresponding to the rendering entity; the rendering chain of the rendering entity is determined based on the anchor point data connecting adjacent graphics stages in the pre-set graphics pipeline; the anchor point data is constructed based on the attributes of the rendering entity.

2. The method according to claim 1, characterized in that, The step of performing difference analysis using the first log data of the corresponding graphics stage according to the rendering order defined in the rendering chain of the rendering entity, and determining the target graphics stage with the earliest difference among multiple graphics stages, includes: For each piece of the first log data, the first log data is standardized and mapped to obtain the second log data; In the case of second log data with different architectures, architecture mapping is performed on the second log data with different architectures to obtain the corresponding third log data; In the absence of second log data with a different architecture, the second log data is identified as the third log data; According to the rendering order defined in the rendering chain of the rendering entity, the third log data of the corresponding graphics stage is used for difference analysis to determine the target graphics stage with the earliest difference among the multiple graphics stages.

3. The method according to claim 2, characterized in that, The first log data includes version information; the version information represents the format version number of the first log data; the standardization mapping of the first log data to obtain the second log data includes: The correspondence between the original fields and the standardized fields is determined based on the version information; Based on the correspondence between the original fields and the standardized fields, the first log data is standardized and mapped to obtain the second log data.

4. The method according to claim 3, characterized in that, The step of standardizing and mapping the first log data based on the correspondence between the original fields and the standardized fields to obtain the second log data includes: For each collected field in the first log data, a target standardized field corresponding to the collected field is determined based on the correspondence between the original field and the standardized field. For each of the collected fields, the field value corresponding to the target standardized field is determined based on the field value corresponding to the collected field; The second log data is generated based on the field values ​​corresponding to each of the aforementioned target standardized fields.

5. The method according to claim 2, characterized in that, The process of mapping the second log data for different architectures to obtain their respective corresponding third log data includes: For each piece of second log data in the second log data with different architectures, based on predefined architecture mapping rules, architecture mapping is performed on each target standardized field in the second log data to obtain the third log data; the predefined architecture mapping rules include, but are not limited to: field name mapping, enumeration value normalization, unit conversion, format conversion, and missing field padding.

6. The method according to claim 2, characterized in that, The vertex-to-pixel rendering pipeline is determined based on the vertex-level processing pipeline, the primitive-level processing pipeline, and the pixel-level processing pipeline; the vertex-level processing pipeline is determined based on the vertex-level graphics stage set and the anchor point data; the primitive-level processing pipeline is determined based on the primitive-level graphics stage set and the anchor point data; the pixel-level processing pipeline is determined based on the pixel-level graphics stage set and the anchor point data; the vertex-level graphics stage set, the primitive-level graphics stage set, and the pixel-level graphics stage set are determined based on the multiple graphics stages included in the graphics pipeline.

7. The method according to claim 6, characterized in that, The vertex-level processing link is a processing link generated when the output vertex identifier of one vertex stage is the same as the input vertex identifier of the other vertex stage for any two adjacent vertex stages in the vertex-level graphics stage set. The primitive-level processing link is a processing link generated for any two adjacent primitive stages in the primitive-level graphics stage set, where the output primitive identifier of one primitive stage is the same as the input primitive identifier of the other primitive stage. The pixel-level processing link is generated when the output pixel coordinates and output sample index of one pixel stage are the same as the input pixel coordinates and input sample index of the other pixel stage for any two adjacent pixel stages in the pixel-level graphics stage set.

8. The method according to any one of claims 2 to 7, characterized in that, The first log data includes payload data; the payload data is used for difference comparison in the difference analysis; the step of performing difference analysis using the third log data of the corresponding graphics stage according to the rendering order defined in the rendering chain of the rendering entity, and determining the target graphics stage with the earliest difference among multiple graphics stages, includes: Determine the current graphics stage for differential analysis according to the rendering order defined in the rendering chain of the rendering entity; Determine the baseline data corresponding to the comparison load data of the rendered entity in the current graphics stage; the comparison load data in the current graphics stage is determined based on the third log data of the current graphics stage; Based on the load data to be compared and the benchmark data, the target graphic stage is determined.

9. The method according to claim 8, characterized in that, Determining the reference data corresponding to the comparison load data of the rendered entity in the current graphics stage includes: If the load data to be compared has a corresponding serial number, the reference data that has the same serial number as the load data to be compared is determined as the reference data corresponding to the load data to be compared. If the load data to be compared does not have a corresponding sequence number, the reference data corresponding to the load data to be compared is determined according to the respective order of the load data to be compared and the reference data.

10. The method according to claim 8, characterized in that, The step of determining the target graphic based on the load data to be compared and the reference data includes: Determine the field type of each load field to be compared in the load data to be compared; For each of the aforementioned payload fields to be compared, a comparison rule corresponding to the payload field to be compared is determined based on the field type corresponding to the payload field to be compared. Based on the comparison rules corresponding to all the load fields to be compared, the comparison rules for the load data to be compared are determined. The target graphic stage is determined based on the load data to be compared, the reference data, and the comparison rules of the load data to be compared.

11. The method according to claim 10, characterized in that, The step of determining the comparison rule corresponding to the field to be compared based on the field type of the payload field to be compared includes: When the field type of the load field to be compared is a numeric field, the comparison rule for the load field to be compared is determined to support a preset tolerance range; If the field type of the payload field to be compared is an enumeration or a boolean field, the comparison rule for the payload field to be compared is determined to be a comparison one by one. If the field type of the load field to be compared is a transient field, the comparison rule for the load field to be compared is determined to be ignored.

12. The method according to claim 10, characterized in that, The stage of determining the target graphic based on the comparison data to be compared, the reference data, and the comparison rules of the comparison data to be compared includes: For each of the load fields to be compared, the load field to be compared and the benchmark field are compared based on the comparison rules corresponding to the load field to be compared, and the comparison result is obtained. If the comparison results show a difference, the current graphics stage is determined as the target graphics stage; the reference field is the field in the reference data that corresponds to the field of the load to be compared.

13. The method according to any one of claims 1 to 12, characterized in that, The graphics pipeline also includes a computation phase; the method further includes: If an abnormality is detected during the graphics stage reading, the resource coordinates corresponding to the reading operation are obtained; The calculation data of the calculation stage corresponding to the resource coordinates is added to the first log data to analyze read anomalies.

14. The method according to any one of claims 2 to 12, characterized in that, The method further includes: In response to a query command, based on the anchor data or payload data to be queried carried by the query command, the corresponding stored record is queried from the table storing the third log data; the third log data is stored in a preset format.

15. The method according to claim 12, characterized in that, The method further includes: A difference record is generated based at least on the difference identifier, the target graphic stage, the anchor point data, and the difference summary; the difference summary characterizes the comparison load data and the corresponding benchmark data that show differences during the difference analysis process.

16. A differential positioning system for a graphics pipeline, characterized in that, The system includes: The acquisition layer is used to acquire the first log data corresponding to each graphics stage in the graphics pipeline when there are differences in the rendering of the rendered entity in the graphics pipeline. The analysis layer is used to perform difference analysis using the first log data of the corresponding graphics stage according to the rendering order defined in the rendering pipeline of the rendering entity, and to determine the target graphics stage with the earliest difference among the multiple graphics stages; the rendering pipeline of the rendering entity represents the rendering pipeline from vertex to pixel corresponding to the rendering entity; the rendering pipeline of the rendering entity is determined based on the anchor point data connecting adjacent graphics stages in the pre-set graphics pipeline; the anchor point data is constructed based on the attributes of the rendering entity.

17. The system according to claim 16, characterized in that, The analysis layer is further configured to: for each first log data, perform standardized mapping on the first log data to obtain second log data; in the case of second log data with different architectures, perform architecture mapping on the second log data with different architectures respectively to obtain their respective corresponding third log data; in the case of no second log data with different architectures, determine the second log data as the third log data; and perform difference analysis using the third log data of the corresponding graphics stage according to the rendering order defined in the rendering chain of the rendering entity to determine the target graphics stage with the earliest difference among the multiple graphics stages.

18. The system according to claim 17, characterized in that, The vertex-to-pixel rendering pipeline is determined based on the vertex-level processing pipeline, the primitive-level processing pipeline, and the pixel-level processing pipeline; the vertex-level processing pipeline is determined based on the vertex-level graphics stage set and the anchor point data; the primitive-level processing pipeline is determined based on the primitive-level graphics stage set and the anchor point data; the pixel-level processing pipeline is determined based on the pixel-level graphics stage set and the anchor point data; the vertex-level graphics stage set, the primitive-level graphics stage set, and the pixel-level graphics stage set are determined based on the multiple graphics stages included in the graphics pipeline.

19. The system according to claim 18, characterized in that, The vertex-level processing link is generated when the output vertex identifier of one vertex stage is the same as the input vertex identifier of the other vertex stage for any two adjacent vertex stages in the vertex-level graphics stage set. The primitive-level processing link is generated when the output primitive identifier of one primitive stage is the same as the input primitive identifier of the other primitive stage for any two adjacent primitive stages in the primitive-level graphics stage set. The pixel-level processing link is generated when the output pixel coordinates and output sample index of one pixel stage are the same as the input pixel coordinates and input sample index of the other pixel stage for any two adjacent pixel stages in the pixel-level graphics stage set.

20. The system according to any one of claims 17 to 19, characterized in that, The first log data includes payload data; the payload data is used to perform difference comparison in the difference analysis; the analysis layer is also used to determine the current graphics stage for difference analysis according to the rendering order defined in the rendering chain of the rendering entity. Determine the reference data corresponding to the comparison load data of the rendered entity in the current graphics stage; The payload data to be compared in the current graph phase is determined based on the third log data of the current graph phase; Based on the load data to be compared and the benchmark data, the target graphic stage is determined.

21. 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 program, it implements the steps of the method according to any one of claims 1 to 15.

22. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program performs the steps of the method according to any one of claims 1 to 15.

23. A computer program product, said computer program product comprising a non-transitory computer-readable storage medium storing a computer program, characterized in that, When the computer program is read and executed by a computer, it implements the steps of the method according to any one of claims 1 to 15.

Images