Viewport conversion method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a viewport transformation method and device, electronic equipment, a storage medium and a program product, and the method comprises the steps: for a to-be-transformed target vertex, obtaining a vertex identifier of the target vertex and a viewport identifier corresponding to the transformation; acquiring a first vertex transformation record matched with the vertex identifier from a cache space according to a first matching result between the vertex identifier and vertex information in a vertex transformation record stored in the cache space; according to a second matching result between the viewport identifier and viewport information in the first vertex transformation record, acquiring associated transformation data corresponding to the transformation from the first vertex transformation record; and according to the association transformation data, transforming the target vertex to a viewport corresponding to the viewport identifier. According to the mode, the correlation transformation data can be multiplexed according to the matching result, so that the operand of viewport transformation is greatly reduced, and the operation efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of graphics processing, and in particular, to a viewport transformation method and device, electronic equipment, storage medium and program product. BACKGROUND

[0002] In computer graphics, the process of rendering a three-dimensional scene to a two-dimensional screen is usually accomplished by the rendering pipeline of a graphics processing unit (GPU). Viewport transformation is a key step in the rendering pipeline, aiming to map the vertex coordinates after geometry processing and primitive assembly from the normalized device coordinate system to the pixel coordinate system of the window region on the screen, so as to determine the display position of each primitive on the screen.

[0003] With the development of graphics applications, the demand for displaying multiple independent views in a single screen region is increasing, such as split-screen games, picture-in-picture display, multi-view rendering in virtual reality (VR), etc. For this purpose, modern graphics APIs (such as DirectX, Vulkan) can support multi-viewport (Multi-Viewport) technology. Under this technology, a rendering target can be divided into multiple viewport regions, and different viewport transformation parameters can be applied to each region.

[0004] In the multi-viewport rendering scene, the complete viewport transformation is usually performed independently for all vertices contained in a primitive according to the viewport identifier carried by the primitive in a per-primitive manner. However, since the operation amount of the viewport transformation process is large and the operation resources consumed are more, how to improve the efficiency of multi-viewport transformation has become a technical problem to be solved at present. SUMMARY

[0005] The present disclosure provides a viewport transformation method, device, electronic equipment, storage medium and program product.

[0006] In a first aspect, the present disclosure provides a viewport transformation method, comprising:

[0007] For a target vertex to be transformed, obtaining a vertex identifier of the target vertex and a viewport identifier corresponding to the current transformation;

[0008] According to a first matching result between the vertex identifier and vertex information in a vertex transformation record stored in a cache space, obtaining a first vertex transformation record matched with the vertex identifier from the cache space;

[0009] According to a second matching result between the viewport identifier and viewport information in the first vertex transformation record, obtaining associated transformation data corresponding to the current transformation from the first vertex transformation record;

[0010] Based on the associated transformation data, the target vertex is transformed to the viewport corresponding to the viewport identifier.

[0011] Secondly, this disclosure provides a viewport switching device, the device comprising:

[0012] The acquisition module is adapted to acquire, for the target vertex to be transformed, the vertex identifier of the target vertex and the viewport identifier corresponding to the current transformation;

[0013] The vertex matching module is adapted to obtain a first vertex transformation record that matches the vertex identifier from the cache space based on a first matching result between the vertex identifier and the vertex information in the vertex transformation record stored in the cache space;

[0014] The viewport matching module is adapted to obtain the associated transformation data corresponding to the current transformation from the first vertex transformation record based on the second matching result between the viewport identifier and the viewport information in the first vertex transformation record;

[0015] The transformation module is adapted to transform the target vertex to the viewport corresponding to the viewport identifier based on the associated transformation data.

[0016] Thirdly, this disclosure provides an electronic device, including:

[0017] At least one processor; and

[0018] A memory communicatively connected to the at least one processor; wherein,

[0019] The processor is configured to execute the above-described method.

[0020] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described method.

[0021] Fifthly, this disclosure provides a computer program product comprising computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the method described above.

[0022] In the embodiments provided in this disclosure, firstly, the vertex identifier of the target vertex to be transformed is matched with the vertex information in the vertex transformation record stored in the cache space to determine the first vertex transformation record that matches the vertex identifier; then, the viewport identifier is matched with the viewport information in the first vertex transformation record, and the associated transformation data corresponding to this transformation is obtained from the first vertex transformation record according to the matching result, and then the viewport transformation is implemented according to the associated transformation data. Therefore, by establishing vertex transformation records in the cache space and performing a two-level matching query using vertex identifiers and viewport identifiers, associated transformation data can be reused according to the matching result, thereby significantly reducing the computational load of viewport transformation and improving computational efficiency.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0024] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0025] Figure 1 A flowchart of a viewport transformation method provided in this embodiment of the disclosure;

[0026] Figure 2 A schematic diagram of the viewport transformation matrix is ​​shown;

[0027] Figure 3 A schematic diagram of a viewport transformation device in an example is shown;

[0028] Figure 4 A schematic diagram of the pre-rasterization module is shown.

[0029] Figure 5 A schematic diagram of the viewport transformation module is shown;

[0030] Figure 6 This example illustrates a flowchart of a process for determining a cache hit for transformation results.

[0031] Figure 7 A flowchart illustrating the process of processing the target vertex to be transformed in a primitive is shown.

[0032] Figure 8 A structural diagram of a viewport conversion device provided in an embodiment of this disclosure;

[0033] Figure 9 A block diagram of an electronic device is provided in this disclosure. Detailed Implementation

[0034] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0035] Unless otherwise specified, the various embodiments and features of this disclosure may be combined with each other. As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries.

[0036] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0037] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0038] Figure 1 This is a flowchart illustrating a viewport transformation method provided in an embodiment of this disclosure. This method can be executed by various hardware, software, or a combination of hardware and software entities possessing computing and control capabilities. This application does not limit the specific type or form of the executing entity. See also... Figure 1 The method includes:

[0039] Step S110: For the target vertex to be transformed, obtain the vertex identifier of the target vertex and the viewport identifier corresponding to this transformation.

[0040] In this context, the target vertex is typically a single geometric vertex that requires viewport transformation in the current processing cycle of the graphics rendering pipeline. It is usually a basic element constituting primitives such as points, lines, or triangles, and can carry attribute data such as position, color, and normals. A vertex identifier is used to uniquely identify a vertex. For example, a vertex identifier can be a vertex index value provided by the application in a draw call. A viewport identifier can be an index or label used to identify a specific rectangular display area on the screen. In graphics APIs that support multiple viewports, applications can predefine multiple viewports, each with independent transformation parameters. The shader program can specify a viewport identifier for the output primitive to indicate which preset viewport the primitive should be rendered to. Accordingly, based on the viewport identifier corresponding to this transformation, the target viewport to which the primitive to which the current target vertex belongs can be determined.

[0041] Step S120: Based on the first matching result between the vertex identifier and the vertex information in the vertex transformation record stored in the cache space, retrieve the first vertex transformation record that matches the vertex identifier from the cache space.

[0042] The cache space is a high-speed storage area located within the graphics processing unit (GPU) used to temporarily store vertex transformation records. A vertex transformation record can be a data entry stored in the cache space, recording relevant information about a vertex during its historical transformation process. Typically, a complete vertex transformation record contains at least three parts: vertex information, viewport information, and transformation data. The vertex information is used to find a vertex transformation record in the cache that matches the vertex identifier of the target vertex; it is usually generated directly from the vertex identifier. Accordingly, the first vertex transformation record refers to the data entry whose vertex information matches the vertex identifier of the target vertex. If a first vertex transformation record is found, it means that the target vertex has already undergone a vertex transformation during its historical transformation process; therefore, the corresponding data entry for that vertex is stored in the cache space.

[0043] Step S130: Based on the second matching result between the viewport identifier and the viewport information in the first vertex transformation record, obtain the associated transformation data corresponding to this transformation from the first vertex transformation record.

[0044] The viewport information is a data field stored in the first vertex transformation record, used to characterize the historical viewport identifier of the historical transformation process corresponding to the first vertex transformation record. The second matching result is used to characterize whether the viewport identifier of the target vertex is consistent with the viewport information in the first vertex transformation record, thereby determining whether the transformation to be performed now is a transformation operation of the same vertex under the same viewport as the historical transformation in the cached first vertex transformation record. If the viewport identifier of the target vertex is inconsistent with the viewport information in the first vertex transformation record, it indicates that the transformation to be performed now is a transformation operation of the same vertex under different viewports as the historical transformation in the cached first vertex transformation record. Correspondingly, associated transformation data refers to the data extracted from the first vertex transformation record used to assist in completing this viewport transformation. If the viewport identifier of the target vertex is consistent with the viewport information in the first vertex transformation record, it indicates that the transformation to be performed now is a transformation operation of the same vertex under the same viewport as the historical transformation in the cached first vertex transformation record. Correspondingly, associated transformation data refers to the data extracted from the first vertex transformation record that can directly complete this viewport transformation. Therefore, the specific content of the associated transformation data depends on the second matching result. For example, if the viewport identifier of the target vertex matches the viewport information in the first vertex transformation record, the associated transformation data may include the final transformation result stored in the first vertex transformation record, and this final transformation result is directly determined as the calculation result of this transformation. Conversely, if the viewport identifier of the target vertex does not match the viewport information in the first vertex transformation record, the associated transformation data may include reusable intermediate calculation results. In summary, this application does not limit the specific type and content of the associated transformation data, as long as it can reduce the amount of computation based on the matching situation.

[0045] Optionally, when retrieving a first vertex transformation record matching the vertex identifier from the cache space based on the first matching result between the vertex identifier and the vertex information in the vertex transformation record stored in the cache space, the first vertex transformation record matching the vertex identifier is retrieved from the cache space only if the first matching result indicates that the vertex identifier matches the vertex information in the vertex transformation record stored in the cache space; if the first matching result indicates that the vertex identifier does not match the vertex information in the vertex transformation record stored in the cache space, the data in the cache cannot be used to simplify the calculation, and the vertex transformation data of the target vertex needs to be calculated in the traditional way, and the calculation result is stored in the cache space so that the vertex transformation record corresponding to the target vertex is added to the cache space.

[0046] Step S140: Based on the associated transformation data, transform the target vertex to the viewport corresponding to the viewport identifier.

[0047] This can be achieved by applying viewport transformation formulas and other methods to map the coordinates of the target vertex from the normalized device coordinate system to the specific pixel (or sampling point) position within the screen rectangular area specified by the viewport identifier. By using associated transformation data, the computational load can be reduced.

[0048] Therefore, in this application, by establishing vertex transformation records in the cache space and performing two-level matching queries using vertex identifiers and viewport identifiers, the associated transformation data can be reused based on the matching results, thereby significantly reducing the computational load of viewport transformations and improving computational efficiency.

[0049] In addition, those skilled in the art can make various modifications and variations to the above embodiments:

[0050] In one optional implementation, the vertex transformation record stored in the cache space is used to store the vertex transformation data of the transformed vertices in the historical transformation process; wherein, the vertex transformation data includes: a first type of transformation data and a second type of transformation data; wherein, the first type of transformation data is used to represent the screen position coordinates of the transformed vertices in the historical transformation process, and the second type of transformation data is used to represent the intermediate calculation results of the transformed vertices in the historical transformation process; and, the viewport information in the vertex transformation record is used to represent the viewport identifier corresponding to the historical transformation process.

[0051] In this context, "transformed vertices" refers to vertices that have already undergone viewport transformation before the current transformation operation. The historical transformation process corresponds to the viewport transformation operations performed on the transformed vertices. The first type of transformation data can be the data ultimately output to subsequent graphics pipeline stages (usually the rasterization stage) after a complete viewport transformation of the vertex. This mainly includes the vertex's coordinates in screen space or window space. Screen position coordinates are typically three-dimensional coordinates, for example, screen position coordinates include (X_t, Y_t, Z_t). Here, X_t and Y_t represent the horizontal and vertical positions of the corresponding pixels (or subsamples) in the rendering target (such as the framebuffer), respectively. Z_t represents the vertex's depth value, which can be normalized and stored in a depth buffer for subsequent depth testing. The second type of transformation data can be reusable intermediate results generated during the calculation of screen position coordinates (X_t, Y_t, Z_t) from the vertex's homogeneous coordinates (x, y, z, w). Therefore, the second type of transformed data is not the final output, but recalculating this part of the data requires significant computing resources.

[0052] By dividing vertex transformation data into two parts, namely, first-type transformation data and second-type transformation data, the associated transformation data can be obtained as needed, regardless of whether the second matching result between the viewport identifier and the viewport information is successful or not. This improves transformation efficiency through data reuse.

[0053] Optionally, if the second matching result is a first-type hit result, the associated transformation data corresponding to this transformation is obtained based on the second-type transformation data in the first vertex transformation record. The first-type hit result indicates that the viewport identifier does not match the viewport information in the first vertex transformation record. Therefore, if the second matching result is a first-type hit result, it means that the vertex identifier matches the vertex information in at least one vertex transformation record stored in the cache space, but the viewport identifier does not match the viewport information in the first vertex transformation record. Thus, the first-type hit result can also be called a partial hit result. Accordingly, based on the second-type transformation data in the first vertex transformation record, the screen position coordinates of the target vertex during this transformation process are calculated; based on the screen position coordinates of the target vertex during this transformation process, the target vertex is transformed to the viewport corresponding to the viewport identifier.

[0054] In partially hit scenarios (i.e., identical vertices but different viewports), traditional methods directly trigger a completely new viewport transformation calculation. During the development of this invention, the inventors discovered that, for the same vertex, even if two transformation operations correspond to different viewports, there is still an inherent connection between the two operations: although the translation and scaling parameters change under different viewports, the core parameters generated by the same vertex during the perspective projection stage and used for subsequent perspective division remain constant. Therefore, this application utilizes the above characteristics to improve computational efficiency in partially hit scenarios.

[0055] In this process, obtaining associated transformation data based on the second type of transformation data in the first vertex transformation record can be achieved in several ways. In the first method, the core reciprocal 1 / w can be reused; that is, the associated transformation data obtained from the second type of transformation data is 1 / w. This method has low storage overhead, requiring only an additional floating-point value to be stored for each vertex, solving the core reciprocal operation reuse problem and significantly improving performance. In the second method, intermediate products can also be reused. For example, the second type of transformation data further stores (x / w), (y / w), and (z / w). Correspondingly, the associated transformation data can be (x / w), (y / w), and (z / w). Consequently, when calculating X_t = a0 + m0 × (x / w) later, (x / w) can be directly reused without first performing the multiplication of x × (1 / w), further reducing computational overhead. In summary, in the case of partial hits, reusing intermediate results from transformations of the same vertex under different viewports can significantly improve the efficiency of this viewport transformation.

[0056] Optionally, in one embodiment, the second type of transformation data may include perspective parameters for perspective division calculated based on the homogeneous coordinates of the transformed vertices. The homogeneous coordinates of the transformed vertices can be the coordinate data of the target vertex that has been processed and output by the upstream shader before the current viewport transformation is performed, typically represented as (x, y, z, w), where x, y, z, and w are real numbers. Therefore, when the homogeneous coordinates include a first component (i.e., the x-component), a second component (i.e., the y-component), a third component (i.e., the z-component), and a fourth component (i.e., the w-component), the perspective parameters can be used to characterize the reciprocal of the fourth component (i.e., 1 / w). Thus, the perspective parameters for perspective division can be key parameters in the division operation (x / w, y / w, z / w) required when performing the transformation from homogeneous coordinates to three-dimensional Cartesian coordinates, specifically referring to the reciprocal of the divisor w, 1 / w. Furthermore, the first type of transformation data can include a first component, a second component, and a third component; where the first, second, and third components correspond to the three dimensions of a three-dimensional coordinate system. For example, the first, second, and third components correspond to screen space coordinates (X_t, Y_t, Z_t), where X_t and Y_t are pixel positions, and Z_t is the depth buffer value. Accordingly, if all values ​​are hit, the final transformation result can be directly reused based on the first type of transformation data.

[0057] In the graphics pipeline, vertex data is typically calculated in homogeneous coordinates (x, y, z, w). However, in traditional viewport transformations, this data is discarded after calculation, and the system only outputs the final screen coordinates (X_t, Y_t, Z_t). Therefore, intermediate calculation results for a vertex cannot be reused across different viewports. This application improves computational efficiency by storing reusable intermediate results in a cache space.

[0058] In one optional implementation, when obtaining the associated transformation data corresponding to the current transformation based on the second type of transformation data in the first vertex transformation record, it can be determined whether the third component of the same vertex is the same in multiple different viewports based on the state value of the pre-configured state register and / or the received configuration command. Accordingly, if it is determined that the third component of the same vertex is the same in multiple different viewports based on the state value of the pre-configured state register and / or the received configuration command, the associated transformation data corresponding to the current transformation is obtained based on the second type of transformation data in the first vertex transformation record and the third component in the first type of transformation data.

[0059] The pre-configured status register can be a dedicated register inside the graphics processing unit, writable by the driver. Specific bits in the register can be assigned specific meanings. For example, when a preset bit in the status register is 1, it indicates that the depth transformation parameters of all active viewports in the current rendering context are configured to be the same. The received configuration command can be a special instruction or data packet sent to the GPU via the graphics command stream. This command contains an opcode and / or data fields to indicate that the depth transformation parameters of all active viewports are configured to be the same. The same third component of the same vertex in multiple different viewports means that vertices with the same vertex identifier have the same depth component Z_t in screen space coordinates after viewport transformation in all viewports defined on the current rendering target (e.g., the screen). In other words, when the depth transformation parameters of all viewports are completely equal, for the same vertex, regardless of which viewport the vertex is assigned to for transformation, the final calculated Z_t value is exactly the same.

[0060] By using the above method, the calculation process can be further optimized when the depth transformation parameters are the same for all viewports. On the basis of reusing the second type of transformation data, the third component in the first type of transformation data can be further reused, thereby further reducing the resource consumption of the transformation process.

[0061] Optionally, after calculating the screen-space coordinates of the target vertex during the current transformation process, the following operations are performed to achieve dynamic updates to the cache: The vertex transformation records stored in the cache are updated based on the screen-space coordinates of the target vertex during the current transformation process. This updating of the vertex transformation records can be achieved through an overwrite update method. For example, in a partially hit scenario, the first type of transformation data in the first vertex transformation record can be updated based on the screen-space coordinates of the target vertex during the current transformation process, so that the first type of transformation data in the first vertex transformation record is updated to the screen-space coordinates of the target vertex during the current transformation process. This method does not require increasing the total number of cache entries; it always writes the latest, newly calculated (vertex, new viewport) transformation result into the old entries in this partially hit scenario to overwrite the old (vertex, old viewport) records. If the rendering stream intensively accesses the transformation of the current vertex in the current new viewport within a certain period, this method ensures that all subsequent accesses are hits, resulting in better performance. This method follows the principle of locality, where recently used data is likely to be used again.

[0062] For example, in scenarios with partial hits, an additive update approach can be used: a vertex transformation record corresponding to the current transformation is added to the cache space; this record contains the same vertex information as the first vertex transformation record. This method retains the old (vertex, old viewport) record while adding a new (vertex, new viewport) record. This ensures that the transformation results of the same vertex under two different viewports can exist in the cache, thereby improving performance in scenarios with complex access patterns: if a vertex is frequently and alternately accessed across multiple viewports, this method ensures that all viewsports will be hit regardless of which viewport is requested next.

[0063] In one optional implementation, when the second matching result is a second type of hit result, the associated transformation data corresponding to this transformation is obtained based on the first type of transformation data in the first vertex transformation record. The second type of hit result is used to characterize the match between the viewport identifier and the viewport information in the first vertex transformation record. Therefore, when the second matching result is a second type of hit result, it indicates that the vertex identifier matches the vertex information in at least one vertex transformation record stored in the cache space, and the viewport identifier also matches the viewport information in the first vertex transformation record. Thus, the second type of hit result can also be called a full hit result. Accordingly, the first type of transformation data in the first vertex transformation record is determined as the screen position coordinates of the target vertex during this transformation process; based on the screen position coordinates of the target vertex during this transformation process, the target vertex is transformed to the viewport corresponding to the viewport identifier. If the viewport identifier matches the viewport information in the first vertex transformation record, it means that the viewport transformation operation to be performed on the current vertex has already been performed. That is, the first vertex transformation record stores the vertex transformation data of the same vertex under the same viewport. At this time, the associated transformation data corresponding to this transformation can be the first type of transformation data in the first vertex transformation record. Then, the coordinate data recorded in the first type of transformation data can be directly determined as the screen position coordinates of the target vertex in this transformation process, thereby saving all the calculation processes related to vertex transformation.

[0064] In one optional implementation, the vertex transformation record stored in the cache space may further include a validity identifier; this validity identifier is used to characterize whether the vertex transformation record is currently in a valid state, thereby querying only vertex transformation records in a valid state. Furthermore, the target vertex can be any vertex in the current primitive to be transformed from multiple primitives; wherein multiple primitives can reuse the same vertex; and the viewport identifier corresponding to this transformation is used to identify one of the multiple viewports, and the same vertex can be transformed to different viewports in different primitives. In this scenario, the same vertex can belong to different viewports in different primitives; therefore, the cache reuse method in this application can significantly improve transformation efficiency.

[0065] To facilitate understanding, the following example illustrates the specific implementation details of the memory access request handling method provided in this application.

[0066] This example relates to a high-performance multi-viewport transformation method and apparatus, specifically involving the technical fields of GPU, graphics, and viewport transformation. The GPU rendering pipeline is a key concept in computer graphics, corresponding to a stage in the graphics processing unit (GPU) responsible for processing and transforming graphics data for rendering. The main task of the rendering pipeline is to convert input geometric primitives (such as points, lines, triangles, etc.) into pixels visible on the screen, specifically consisting of multiple stages, each performing specific geometric calculations and transformations. For example, a typical geometry pipeline rendering stage includes the following processes:

[0067] (1) Vertex Input: This stage passes vertex data from the application to the geometry pipeline. Vertex data includes attributes such as position, color, and normal.

[0068] (2) Vertex Shader: In this stage, the vertex shader calculates for each input vertex and can perform various transformations and operations, such as model transformation, view transformation, projection transformation, etc. It can also calculate the lighting and texture coordinates of the vertex.

[0069] (3) Primitive Assembly: In this stage, the primitive assembler converts vertices into complete geometric primitives, such as points, line segments, triangles, etc.

[0070] (4) Geometry Shader: In the geometry shading stage, the geometry shader can manipulate and generate geometric primitives. Specifically, it can create new primitives and change the shape, size, and position of primitives.

[0071] (5) Clipping: In this stage, the clipper compares the primitives with the screen boundary and discards the parts that are outside the view volume.

[0072] (6) Screen Mapping: This stage is used to map the clipped primitives to pixel coordinates in screen space.

[0073] (7) Rasterization: The rasterization stage converts geometric primitives into pixels on the screen and determines the position, color and other attributes of each pixel.

[0074] (8) Fragment Shader: In the fragment shading stage, the fragment shader performs calculations for each rasterized pixel. Specifically, it can perform pixel-level lighting calculations, texture sampling, depth testing, and other operations.

[0075] (9) Pixel Operations: The last stage is pixel operations, which are used to perform final pixel processing, such as blending, dithering, anti-aliasing, etc.

[0076] The goal of the rendering pipeline is to process geometry and generate the final image efficiently. Through parallel processing and specialized hardware support, the GPU can perform these calculations quickly to achieve real-time graphics rendering. Screen mapping, also known as viewport transformation, is a crucial step in computer graphics, responsible for transforming the image from normalized device coordinates (NDC) to screen coordinates, i.e., determining the pixel positions of the image ultimately displayed on the screen. Multi-viewport transformation is a technique in graphics rendering used to define multiple viewport regions within the same rendering window, enabling effects such as split-screen display, picture-in-picture, debug views, and nested UI rendering. In DirectX, Vulkan, and OpenGL, a geometry shader is allowed to output a viewport identifier (vp id), which specifies that a primitive is mapped to a particular viewport in a defined array of multiple viewports. The latest DirectX and Vulkan versions further expand this application, allowing viewport identifiers to be output from vertex shaders or domain shaders.

[0077] In multi-viewport scenarios, the existing approach is to perform viewport transformation on each vertex of each primitive individually. Since viewport identifiers are at the primitive level, and different primitives may share vertices, some vertices need to be transformed using different viewport identifiers and different viewport transformation matrices.

[0078] Figure 2 A schematic diagram of the viewport transformation matrix is ​​shown, such as... Figure 2 As shown, x, y, z, and w are the coordinates output by the shader, while x_t, y_t, z_t, and w_t are the transformed coordinates. The transformed coordinates need to be normalized, becoming x_t / w_t, y_t / w_t, and z_t / w_t, to obtain the three-dimensional spatial coordinates. The matrix formed by a0, a1, a2, and m0, m1, m2 is the viewport transformation matrix. In multi-viewport scenes, applications can set up to 16 different viewport transformation matrices. The shader, by outputting a viewport identifier, can select the viewport transformation matrix from these 16 matrices to transform the current primitive, thus mapping the primitive to a specified viewport region on the screen.

[0079] In related technologies, the calculation is usually performed as follows: First, calculate 1 / w, and then perform viewport transformation on X / Y / Z in sequence according to the following formulas: x_t = a0 + m0×x× (1 / w), y_t = a1 + m1×y×(1 / w) and z_t = a2 + m2×z ×(1 / w).

[0080] Therefore, in multi-viewport scenarios, the relevant technical solutions select a viewport identifier for each primitive and then perform viewport transformation on all vertices that make up the primitive sequentially. For scenarios where primitives share vertices, the same vertex needs to be transformed separately in different primitives. However, viewport calculation is very complex, and the above solutions significantly reduce the throughput of primitives in multi-viewport scenarios, severely impacting system performance.

[0081] To address the computational challenges of multi-viewport transformation, this example proposes a high-performance multi-viewport transformation method and a corresponding viewport transformation device.

[0082] Figure 3 A schematic diagram of the viewport transformation device in this example is shown, as follows: Figure 3 As shown, the viewport transformation device includes a shader, a pre-rasterization module, and a rasterization module. The shader further incorporates local memory. Optionally, the pre-rasterization module and the rasterization module can be combined into a single module; this application does not limit the specific details. The shader runs user-defined shading programs (including vertex shading, shell shading, domain shading, geometry shading, mesh shading, etc.) and outputs the results to the local memory. In the pre-rasterization stage, the results of the shading programs in the local memory are read, and pre-rasterization stages including viewport transformation, clipping, and culling are performed. The results are then output to the rasterization section for further rasterization and pixel processing during the rasterization stage.

[0083] Figure 4 A schematic diagram of the pre-rasterization module (Pre-Rast) is shown, as follows: Figure 4As shown, the pre-rasterization module further includes: a local memory read module (LM Read), a viewport transformation module (Vpt Transform), and a culling and clipping module. The local memory read module reads the Local Memory content output by the shader and sends the results to the viewport transformation module and the culling and clipping module respectively. The viewport transformation module receives the position coordinates and possible viewport identifiers (vp-id) from the shader output results obtained by the local memory read module and performs viewport transformation. The result of the viewport transformation is output to the culling and clipping module to perform culling and clipping operations. After culling and clipping, the primitives have other attribute information obtained by the culling and clipping module and are sent out of the pre-rasterization module to enter the rasterization processing flow.

[0084] Figure 5 A schematic diagram of the viewport transformation module is shown, as follows: Figure 5 As shown, the viewport transformation module further includes: a Transform Controller, an Arithmetic Logic Unit (ALU), and a TransformedCache. The Transform Controller is responsible for the main transformation control, including performing cache hit tests and scheduling the ALU to execute viewport transformations. The ALU is the component that provides computational resources for viewport transformations. The TransformedCache is the cache component proposed in this example used to store the results of viewport transformations (including in multi-viewport scenes). Therefore, this example adds a Transform Controller and a TransformedCache to the viewport transformation module to achieve cache reuse. The TransformedCache is the cache space mentioned above.

[0085] Table 1 shows a schematic diagram of a cached entry in the transformation result cache:

[0086] Table 1

[0087]

[0088] In this context, `valid` is a validity flag, which can be 1 bit, used to indicate whether the current entry is valid; `vertex id` is the vertex index value, also called the vertex identifier, used to uniquely identify a vertex; `vp id` is the viewport identifier, used to uniquely identify a viewport; `x_t`, `y_t`, and `z_t` are the screen position coordinates after the viewport transformation, which is the first type of transformation data mentioned above. `1 / w` is the second type of transformation data mentioned above. The transformation result cache can consist of one or more cache entries. The cache can adopt a fully associative structure, or a set-associative or cascaded associative structure; this application does not limit the specific structure of the cache.

[0089] Figure 6 This example illustrates the flowchart for determining a cache hit in the transformation result cache. Figure 6 As shown, during the hit test, each valid entry in the cache is checked sequentially (invalid entries are skipped). The vertex ID of each entry is checked to see if it matches the vertex identifier of the target vertex to be transformed. If both the vertex ID and the vp-id match, a full hit result (i.e., hit-vp-id) is returned. If the vertex ID matches but the vp-id does not, a partial hit result (i.e., hit-no-vp-id) is returned. If, after checking all valid entries, no entry matching the vertex ID is found, a no-hit result is returned.

[0090] Therefore, the core task of the hit test algorithm is to find a completely matching entry for the current input (vertex id, vpid) in the cache, specifically including three possible results: (1) Full hit, returning hit-vp-id: a completely matching entry was found. (2) Partial hit, returning hit-no-vp-id: the vertex was found, but the viewport does not match. (3) Miss: the vertex was not found at all. Specifically, it includes the following steps:

[0091] S601: Select the first item to be detected from multiple items to be detected and perform the detection.

[0092] Specifically, the entry to be checked can be initialized to the first one. For example, the system initializes a "pointer" or "counter" to point to the first entry in the cache.

[0093] S602: Determine whether the item to be tested is valid. Specifically, the determination is made based on the value of the valid bit of the item to be tested. If the determination result is "No" (invalid), proceed to step S607. If the determination result is "Yes" (valid), continue to execute the subsequent step S603.

[0094] S603: Determine whether the vertex identifier of the entry to be detected matches the vertex identifier to be transformed.

[0095] Vertex identifiers can be represented by vetex id. If the vertex identifier of the entry to be detected matches the vertex identifier to be transformed, then proceed to step S604; otherwise, jump to step S607.

[0096] Step S604: Determine whether the viewport identifier of the item to be detected matches the viewport identifier to be transformed.

[0097] The viewport identifier can be represented by the VP ID. Specifically, the VP ID stored in the current detection entry is compared with the VP ID in this transformation request. If the comparison result is a match, the subsequent step S605 is executed; if the comparison result is a mismatch, the process jumps to step S606.

[0098] Step S605: Determine that the comparison result is a full hit, and return a hit success response message. Specifically, a hit-vp-id response message can be returned. In this case, it indicates that the currently detected entry records the transformation result of the current vertex under the currently requested viewport, which can be directly read from the cache without recalculation.

[0099] Step S606: Determine the comparison result as a partial hit (i.e., not a complete hit), and return a response message characterizing the partial hit. Specifically, a hit-no-vp-id response message can be returned. In this case, although the target vertex was found, the vertex was transformed in a different viewport; therefore, the transformation result cannot be directly used for this request.

[0100] Step S607: Move to the next entry to be detected and execute step S608. For example, the pointer corresponding to the current entry to be detected can be incremented by 1, causing the pointer to move to the next entry, so as to continue sequentially traversing the cache.

[0101] Step S608: Determine whether the number of entries to be detected exceeds the total number of entries. Specifically, the system needs to check whether the pointer to the current entry being detected has already pointed to a position after the last entry in the cache (i.e., whether all entries in the cache have been checked). If not, proceed to step S602; if yes, execute step S609.

[0102] Step S609: Return a miss response message.

[0103] Figure 7 This diagram illustrates the process of processing target vertices to be transformed within primitives. Figure 7 As shown, the transformation process for a target vertex in a primitive includes the following steps:

[0104] Step S701: Obtain the primitive and the vertex identifier of the target vertex in the primitive.

[0105] Step S702: Traverse each vertex in the primitive.

[0106] The process involves iterating through the graph primitives and performing the following steps on each vertex in turn. The vertex being processed during the current iteration is the target vertex.

[0107] Step S703: Perform a cache hit test based on the vertex identifier and viewport identifier.

[0108] For the specific process of cache hit testing, please refer to [link / reference]. Figure 6 .

[0109] Step S704: Determine if the hit test result is a miss. If the result is yes, it means that the current vertex has not undergone any viewport transformation processing; therefore, proceed to step S705. If the result is no, it means that the current vertex has undergone viewport transformation processing; therefore, proceed to step S707.

[0110] Step S705: If it is determined that the current vertex has not undergone any viewport transformation processing, perform viewport transformation processing on the vertex in a conventional manner.

[0111] For example, the x, y, z, and w values ​​of a target vertex can be transformed using the viewport selected by the viewport identifier.

[0112] Step S706: Store the result of the viewport transformation into a cache entry.

[0113] Specifically, a new cache entry can be added, which stores the vertex identifier, viewport identifier, and transformation result of the vertex. The transformation result can include the first type of transformation result and the second type of transformation result mentioned above.

[0114] Step S707: If it is determined that the current vertex has undergone viewport transformation processing, further determine whether the hit test result is a partial hit.

[0115] If the hit test result is a partial hit, it means that the viewport transformation performed on the current vertex is inconsistent with the current viewport to be transformed. Therefore, step S709 is executed. If the hit test result is not a partial hit, it means that the viewport transformation performed on the current vertex is consistent with the current viewport to be transformed (i.e., a full hit). Therefore, step S708 is executed.

[0116] Step S708: If all cached entries are hit, reuse the screen position coordinates from the hit cached entries to directly obtain the transformation result for this transformation. For example, the cached transformation result can be directly retrieved from the hit cached entries to obtain the viewport transformation result for this transformation.

[0117] Step S709: In the case of partial hits, reuse the intermediate calculation results in the cached entries that were hit.

[0118] Specifically, in the case of partial hits, intermediate calculation results from the hit cache entries can be reused, i.e., the second type of transformation results mentioned above. For example, 1 / w from the hit cache entry can be retrieved.

[0119] Step S710: Calculate the result of this viewport transformation based on the intermediate calculation results.

[0120] For example, based on 1 / w in the hit cache entry, the viewport selected by the vertex identifier is used to perform viewport transformation on the x, y, and z of the current vertex.

[0121] Therefore, when performing viewport transformations on vertices, the transformation controller can use vertex identifiers and viewport identifiers to perform a hit test on the transformation result cache. If the hit result is a full hit, the transformation result is directly retrieved from the cache, saving the computation process. If the hit result is a partial hit, 1 / w of the transformation result is directly retrieved from the cache, and only the ALU is called to perform the X / Y / Z transformations, thus reducing the computational load. If the result is a miss, the transformation controller will call the ALU to perform viewport transformations on the vertex's x / y / z / w and put the result into the cache.

[0122] For example, suppose the geometry shader outputs a vertex sequence of a strip topology as v0, v1, v2, v3, v4, with viewport identifiers for each vertex being 0, 1, 0, 2, 3 respectively. These five vertices can form the following three primitives: Primitive A: v0-v1-v2, with vertex identifier 0; Primitive B: v1-v3-v2. It should be noted that during the formation of this primitive, a change in orientation is involved, so the vertex order in Primitive B is not v1-v2-v3, but v1-v3-v2, with vertex identifier 1; Primitive C: v2-v3-v4, with vertex identifier 0. In this example, each primitive uses the viewport identifier corresponding to its first vertex as its viewport identifier. Of course, those skilled in the art can use other methods to construct primitives. This application does not limit the number of primitives, the method of construction, or the rules for setting viewport identifiers.

[0123] The processing procedure for the above three graphic elements is as follows:

[0124] First, a viewport transformation is performed on the first primitive (i.e., primitive A). At this point, the cache is empty, so the cache test result under viewport 0 will be a miss for vertices v0, v1, and v2. After the transformation of the first primitive is completed, the cache will store three sets of transformation results: (v0, 0), (v1, 0), and (v2, 0). Each set of transformation results is identified by a combination of vertex identifier and viewport identifier, and each set of transformation results also includes the 1 / w value of each vertex.

[0125] Then, a viewport transformation is performed on the second primitive (i.e., primitive B). At this point, vertex v1 is transformed in viewport 1, so the cache hit result is a partial hit, meaning the vertex is hit but the viewport identifier does not match. Therefore, when performing a viewport transformation on vertex v1, the 1 / w value of vertex v1 is first retrieved from the cache, and then the x / y / z values ​​of vertex v1 are transformed in viewport 1. The cache test result for vertex v3 in viewport 1 is a miss. The cache test result for vertex v2 in viewport 1 is the same as for vertex v0, both being partial hits. Therefore, the 1 / w value of v2 is also retrieved, and then the x / y / z values ​​of v2 are transformed in viewport 1.

[0126] Finally, a viewport transformation is performed on the third primitive (i.e., primitive C). At this point, vertex v2 is transformed in viewport 0, and the cache result is a full hit, meaning the vertex is hit and its identifier matches. Therefore, the viewport transformation result of v2 can be directly retrieved from the cache without recalculation. The result for vertex v3 is a partial hit, meaning the vertex is hit but the viewport identifier does not match. Therefore, 1 / w of v3 is retrieved and transformed in viewport 0. The result for vertex v4 is a miss, so a viewport transformation is performed on v4 in viewport 0, and then the result of v4 is saved to the cache.

[0127] In another optional implementation, if the result is a partial hit, after retrieving 1 / w and performing x / y / z transformation, the corresponding entry in the cache can be updated simultaneously. The viewport identifier in the hit cache entry is updated to the viewport identifier of this viewport transformation, and the transformed result is updated in the cache so that the transformation result of that vertex in the cache is updated to the viewport result under this viewport transformation.

[0128] In another alternative implementation, if the result is a partial hit, after retrieving 1 / w and performing the x / y / z transformation, a new cache entry is added, containing the vertex identifier, viewport identifier, and the result of this transformation. In this approach, if a cache entry results in a partial hit, it is not returned directly but marked as a candidate entry. This process continues until all entries have been scanned. If no entry matches completely, the result of a candidate entry is returned, marked as a partial hit. If, after scanning all entries, a vertex identifier and viewport identifier match, the matching entry is returned, and the result is marked as a complete hit.

[0129] In one possible implementation, the user can specify, or the driver / hardware can detect, whether the matrix parameters for all viewport transformations in the Z direction are the same. If so, the driver can notify the GPU that during viewport transformation, if the cache test result is a partial hit, when reusing 1 / w, the Z transformation result can be retrieved simultaneously, and viewport transformations can be performed only on the X / Y directions. The driver can inform the GPU of the Z-direction matrix parameters (i.e., whether they are the same) for all viewport matrices through methods including, but not limited to, setting status registers and issuing command streams. This is because, in multi-viewport transformations, multiple viewports may only change the X / Y mapping to the screen, without altering the Z-direction mapping. Therefore, reusing the Z-direction transformation result can further improve transformation efficiency.

[0130] This example fully utilizes the computation results of vertices under possible different viewport identifiers in a multi-viewport transformation scenario, reducing the number of viewport transformations and computational loads for vertices in a multi-viewport environment, reducing system power consumption, increasing system throughput, and thus improving the overall performance of the system.

[0131] In this example, in a multi-viewport scenario, a cache can be designed. The vertex index and viewport identifier are used as tags for cache hit detection, allowing reuse of the same vertex under the same viewport transformation. Furthermore, in a multi-viewport scenario, if the cache test result is a partial hit, the saved 1 / w value can be retrieved, reducing the computational load of the current vertex viewport transformation. Moreover, in a multi-viewport scenario, if the cache test result is a full hit, the saved result can be directly reused. Additionally, in a multi-viewport scenario, if the cache test result is a miss, a new cache entry is created to store the vertex index, viewport identifier, and 1 / w value.

[0132] Additionally, in potential optimization scenarios, users can specify (or the driver / hardware can detect) that the Z-direction viewport transformation remains consistent across multiple viewports, thus reusing the Z-direction viewport transformation results. Furthermore, in partial hit scenarios, the hit entries can be updated with the latest viewport identifier and transformation result. Alternatively, the latest viewport identifier and transformation result can be inserted into a new cached entry. During hit testing, if a valid entry is found to have a vertex match but a viewport mismatch, it is not returned directly but treated as a candidate entry until all entries have been scanned. After scanning all entries, if all entries match, the result is considered a full hit. If only vertex matches but no viewport matches, a candidate entry is selected, and the result is considered a partial hit.

[0133] In summary, this example fully utilizes the computation results of vertices under possible different viewport identifiers in a multi-viewport transformation scenario, reducing the number of viewport transformations and computational loads for vertices in a multi-viewport environment, reducing system power consumption, increasing system throughput, and thus improving the overall performance of the system.

[0134] This disclosure also provides a viewport switching device. For example... Figure 8 As shown, the device includes:

[0135] The acquisition module 81 is adapted to acquire the vertex identifier of the target vertex to be transformed and the viewport identifier corresponding to the current transformation.

[0136] Vertex matching module 82 is adapted to obtain a first vertex transformation record that matches the vertex identifier from the cache space based on a first matching result between the vertex identifier and the vertex information in the vertex transformation record stored in the cache space;

[0137] The viewport matching module 83 is adapted to obtain the associated transformation data corresponding to the current transformation from the first vertex transformation record based on the second matching result between the viewport identifier and the viewport information in the first vertex transformation record;

[0138] The transformation module 84 is adapted to transform the target vertex to the viewport corresponding to the viewport identifier according to the associated transformation data.

[0139] This disclosure also provides an electronic device, characterized in that it includes:

[0140] At least one processor; and

[0141] A memory communicatively connected to the at least one processor; wherein,

[0142] The processor is configured as described above.

[0143] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0144] In addition, this disclosure also provides a request processing device, an electronic device, and a computer-readable storage medium, all of which can be used to implement any of the graphics processing methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding section of the method and will not be repeated here.

[0145] Figure 9This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0146] Reference Figure 9 This disclosure provides an electronic device, which includes: at least one processor 701; at least one memory 702; and one or more I / O interfaces 703 connected between the processor 701 and the memory 702; wherein the memory 702 stores one or more computer programs that can be executed by the at least one processor 701, and the one or more computer programs are executed by the at least one processor 701 to enable the at least one processor 701 to perform the viewport transformation method described above.

[0147] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the above-described method. The computer-readable storage medium may be volatile or non-volatile.

[0148] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the above-described method.

[0149] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0150] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0151] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0152] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0153] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0154] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0155] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0156] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0157] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0158] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A viewport transformation method, characterized in that, The method includes: For the target vertex to be transformed, obtain the vertex identifier of the target vertex and the viewport identifier corresponding to this transformation; Based on the first matching result between the vertex identifier and the vertex information in the vertex transformation record stored in the cache space, the first vertex transformation record matching the vertex identifier is obtained from the cache space; Based on the second matching result between the viewport identifier and the viewport information in the first vertex transformation record, obtain the associated transformation data corresponding to this transformation from the first vertex transformation record; Based on the associated transformation data, the target vertex is transformed to the viewport corresponding to the viewport identifier.

2. The method according to claim 1, characterized in that, The vertex transformation records stored in the cache space are used to store the vertex transformation data of transformed vertices in the historical transformation process; The vertex transformation data includes: a first type of transformation data and a second type of transformation data; wherein, the first type of transformation data is used to characterize the screen position coordinates of the transformed vertex in the historical transformation process, and the second type of transformation data is used to characterize the intermediate calculation results of the transformed vertex in the historical transformation process; and, the viewport information in the vertex transformation record is used to characterize the viewport identifier corresponding to the historical transformation process.

3. The method according to claim 2, characterized in that, The step of obtaining the associated transformation data corresponding to the current transformation from the first vertex transformation record based on the second matching result between the viewport identifier and the viewport information in the first vertex transformation record includes: if the second matching result is a first type of hit result, obtaining the associated transformation data corresponding to the current transformation based on the second type of transformation data in the first vertex transformation record; wherein, the first type of hit result is used to characterize that the viewport identifier does not match the viewport information in the first vertex transformation record; The step of transforming the target vertex to the viewport to be transformed according to the associated transformation data includes: calculating the screen position coordinates of the target vertex in the current transformation process according to the second type of transformation data in the first vertex transformation record; and transforming the target vertex to the viewport corresponding to the viewport identifier according to the screen position coordinates of the target vertex in the current transformation process.

4. The method according to claim 3, characterized in that, The second type of transformation data includes: perspective parameters used for perspective division, calculated based on the homogeneous coordinates of the transformed vertices; Wherein, when the homogeneous coordinates include: a first component, a second component, a third component, and a fourth component, the transmission parameter is used to characterize the reciprocal of the fourth component; Furthermore, the first type of transformation data includes: the first component, the second component, and the third component; wherein the first component, the second component, and the third component correspond to the three dimensions in the three-dimensional coordinate system, respectively.

5. The method according to claim 4, characterized in that, The step of obtaining the associated transformation data corresponding to this transformation based on the second type of transformation data in the first vertex transformation record includes: If, based on the state value of the pre-configured state register and / or the received configuration command, it is determined that the third component of the same vertex is the same in multiple different viewports, the associated transformation data corresponding to this transformation is obtained based on the second type of transformation data in the first vertex transformation record and the third component in the first type of transformation data.

6. The method according to any one of claims 3-5, characterized in that, After calculating the screen space position coordinates of the target vertex during this transformation process, the method further includes: The vertex transformation record stored in the cache space is updated based on the screen position coordinates of the target vertex during this transformation process.

7. The method according to claim 6, characterized in that, The updating of the vertex transformation records stored in the cache space includes: Update the first type of transformation data in the first vertex transformation record based on the screen space position coordinates of the target vertex during this transformation process; or... A vertex transformation record corresponding to the current transformation is added to the cache space; wherein the vertex transformation record corresponding to the current transformation has the same vertex information as the first vertex transformation record.

8. The method according to claim 2, characterized in that, The step of obtaining the associated transformation data corresponding to this transformation from the first vertex transformation record based on the second matching result between the viewport identifier and the viewport information in the first vertex transformation record includes: If the second matching result is a second type of hit result, the associated transformation data corresponding to this transformation is obtained according to the first type of transformation data in the first vertex transformation record; wherein, the second type of hit result is used to characterize the match between the viewport identifier and the viewport information in the first vertex transformation record; Furthermore, transforming the target vertex to the viewport to be transformed based on the associated transformation data includes: The first type of transformation data in the first vertex transformation record is determined as the screen position coordinates of the target vertex in this transformation process; based on the screen position coordinates of the target vertex in this transformation process, the target vertex is transformed to the viewport corresponding to the viewport identifier.

9. The method according to any one of claims 1-5, characterized in that, The step of retrieving a first vertex transformation record matching the vertex identifier from the cache space based on a first matching result between the vertex identifier and the vertex information in the vertex transformation record stored in the cache space includes: If the first matching result is used to characterize that the vertex identifier matches the vertex information in the vertex transformation record stored in the cache space, the first vertex transformation record that matches the vertex identifier is obtained from the cache space.

10. The method according to any one of claims 1-5, characterized in that, The target vertex is any vertex in the current primitive to be transformed among multiple primitives; wherein, the multiple primitives can reuse the same vertex; and, the viewport identifier corresponding to this transformation is used to identify one of the multiple viewports, and the same vertex can be transformed to different viewports in different primitives.

11. A viewport switching device, characterized in that, The device includes: The acquisition module is adapted to acquire, for the target vertex to be transformed, the vertex identifier of the target vertex and the viewport identifier corresponding to the current transformation; The vertex matching module is adapted to obtain a first vertex transformation record that matches the vertex identifier from the cache space based on a first matching result between the vertex identifier and the vertex information in the vertex transformation record stored in the cache space; The viewport matching module is adapted to obtain the associated transformation data corresponding to the current transformation from the first vertex transformation record based on the second matching result between the viewport identifier and the viewport information in the first vertex transformation record; The transformation module is adapted to transform the target vertex to the viewport corresponding to the viewport identifier based on the associated transformation data.

12. An electronic device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; in, The processor is configured to perform the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-10.

14. A computer program product comprising computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, characterized in that, When the computer-readable code is run in an electronic device, the processor in the electronic device performs the method of any one of claims 1-10.

Images