Geometric processing system, graphics processor and computing device

Abstract

The present disclosure relates to a geometry processing system, comprising: a vertex cache module configured to: for each vertex index in a vertex stream, perform a hit test based on a cache, and store missed vertex indexes into the cache; sending the vertex index in the cache to a vertex processing pipeline; the vertex processing pipeline is configured to process the vertex represented by the received vertex index and store the obtained vertex processing data into a vertex memory; the primitive assembly line is configured to obtain a mapping relation between a vertex index and a vertex processing index in the vertex flow; determining a plurality of primitives based on the vertex stream; sending the plurality of primitives to a primitive processing pipeline; the primitive processing pipeline is configured to execute primitive processing based on the vertex processing data corresponding to each primitive, and the vertex processing data corresponding to each primitive is obtained from the vertex memory based on the vertex processing index corresponding to the vertex index corresponding to the primitive determined according to the mapping relation.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular, to a geometry processing system, a graphics processor, and a computing device. Background Art

[0002] In the field of computer technology, various graphics data can be processed by a graphics processing unit (GPU). In a graphics processor, graphics data can be processed and converted for rendering through a rendering pipeline. The rendering pipeline can generally be divided into two parts: a geometry processing part (also called a geometry pipeline) and a pixel processing part (also called a fragment pipeline). The former focuses on the processing and transformation of geometric data, generally including vertex input, vertex shading, primitive assembly, collection shading, clipping, screen mapping and other parts; the latter focuses on pixel-level processing, generally including rasterization, fragment shading, pixel operations and other parts. The geometry pipeline and the fragment pipeline are consecutive stages in the rendering pipeline, which are interdependent and work closely together to ultimately generate a visual image. Through parallel processing and specialized hardware support, the GPU can efficiently execute these pipeline stages to achieve real-time graphics rendering.

[0003] The development direction of GPU is to improve rendering speed and realize real-time high-quality and high-resolution rendering. This poses a great challenge to the processing speed of GPU. In the face of this challenge, one design idea is to make full use of the parallel characteristics of rendering data and give play to the parallel computing advantages of hardware. Therefore, how to make fuller use of the characteristics and advantages of parallel processing to improve the processing speed of GPU has become a highly concerned issue in this field. Summary of the invention

[0004] In view of this, the present disclosure provides a geometry processing system, a graphics processor, and a computing device, which are helpful to solve or at least alleviate the above-mentioned problems.

[0005] According to one aspect of the present disclosure, a geometry processing system is provided, including: a vertex cache module, configured to: receive a vertex stream, wherein the vertex stream includes a plurality of vertex indexes, each vertex index representing a vertex; for each vertex index, perform a hit test based on the cache, and store the missed vertex indexes in the cache; send the vertex indexes in the cache to a vertex processing pipeline; the vertex processing pipeline, configured to: for each vertex index received, process the vertex represented by the vertex index, and store the obtained vertex processing data in a vertex memory; a primitive assembly pipeline, configured to: receive the vertex stream; obtain the vertex index in the vertex stream and the vertex processing index; A mapping relationship is provided, wherein each vertex processing index corresponds to vertex processing data obtained based on the corresponding vertex index in the vertex memory; based on the vertex stream, multiple primitives are determined, wherein each primitive corresponds to a specified number of vertex indices; multiple primitives are sent to the primitive processing pipeline; the primitive processing pipeline is configured to: for each primitive received, perform primitive processing based on the vertex processing data corresponding to the primitive, wherein the vertex processing data corresponding to each primitive is obtained from the vertex memory based on the vertex processing index corresponding to the primitive, wherein the vertex processing index corresponding to the primitive is determined based on the vertex index corresponding to the primitive according to the mapping relationship.

[0006] In some embodiments, sending vertex indices in a cache to a vertex processing pipeline includes: sending vertices in the cache to the vertex processing pipeline according to the order in which the vertices are stored in the cache, wherein, for each vertex index received, processing the vertex represented by the vertex index includes: processing the vertices represented by each vertex index in turn according to the order in which the vertex indices are received.

[0007] In some embodiments, the vertex cache module includes a first hit test control module and a task assembly module, wherein the first hit test control module is configured to: for each vertex index in the vertex stream, in response to the vertex index not hitting the cache and the cache is not full, store the vertex index in the cache, or, in response to the vertex index not hitting the cache and the cache is full, send at least a portion of the vertex indexes in the cache to the task assembly module, clear the sent vertex indexes in the cache, and store the vertex index in the cache after performing the clearing operation; wherein the task assembly module is configured to: assemble tasks based on the vertex indexes received from the first hit test control module, wherein each task includes a preset number of vertex indexes and corresponds to a task index.

[0008] In some embodiments, the vertex processing index includes a task index corresponding to the vertex index and a position index in the corresponding task, wherein the first hit test control module is further configured to: initialize the current task index before starting to process the vertex stream; update the current task index each time after sending the vertex index to the task assembly module, wherein the sent vertex index corresponds to the current task index before the update.

[0009] In some embodiments, the first hit test control module is further configured to: in response to completion of processing of the vertex stream, send all vertex indexes in the cache to the task assembly module.

[0010] In some embodiments, the primitive assembly pipeline includes: a second hit test control module, configured to: perform a hit test based on a shadow cache for each vertex index in the vertex stream, and store the missed vertex indexes into the shadow cache; and determine the vertex processing index corresponding to each vertex index according to the order in which the vertex indexes are stored in the shadow cache to determine the mapping relationship.

[0011] In some embodiments, for each vertex index in the vertex stream, a hit test is performed based on the shadow cache, and the missed vertex index is stored in the shadow cache, including: performing the following processing for each vertex index in the vertex stream: in response to the vertex index missing the shadow cache and the shadow cache is not full, storing the vertex index in the shadow cache; in response to the vertex index missing the shadow cache and the shadow cache is full, clearing at least a portion of the vertex indexes in the shadow cache, and storing the vertex index in the shadow cache after the clearing operation is performed.

[0012] In some embodiments, the vertex processing index includes the task index corresponding to the vertex index and the position index in the corresponding task, wherein the second hit test control module is further configured to: initialize the current task index and the current position index before starting to process the vertex stream; determine the task index and the position index of the vertex index based on the current task index and the current position index each time the vertex index is stored in the shadow cache, and update the current position index; update the current task index and reset the current position index each time the vertex index in the shadow cache is cleared.

[0013] In some embodiments, a primitive assembly pipeline includes: a primitive assembly module, configured to: receive an initial state of primitive splitting, wherein the initial state of primitive splitting indicates a rule for determining primitives based on a vertex stream; for each vertex index in the vertex stream, determine the primitive corresponding to the vertex index according to the initial state of primitive splitting, and, based on a mapping relationship, determine the vertex processing index corresponding to the vertex index; send the vertex processing index corresponding to each primitive to the primitive processing pipeline; wherein the primitive processing pipeline is configured to: for each received primitive, based on the vertex processing index corresponding to the primitive, obtain the vertex processing data corresponding to the primitive from the vertex memory, and perform primitive processing.

[0014] In some embodiments, the initial state of primitive splitting includes starting vertex information, which indicates the starting vertex information in the vertex stream for assembling the primitive, wherein, based on the initial state of primitive splitting, determining that the primitive corresponding to the vertex index includes at least one of the following two items: in response to the vertex index being before the starting vertex, skipping the vertex index; in response to the number of vertex indices from the vertex index to the end of the vertex stream being less than a specified number, discarding the vertex index and the vertex index after the vertex index.

[0015] In some embodiments, the vertex cache module is further configured to: in response to one or more clipping points existing in the vertex stream, skip the one or more clipping points.

[0016] According to another aspect of the present disclosure, a graphics processor is provided, comprising at least one geometry processing pipeline, wherein each geometry processing pipeline in the at least one geometry processing pipeline comprises the geometry processing system described in any one of the embodiments of the aforementioned aspects.

[0017] According to yet another aspect of the present disclosure, a computing device is provided, including the graphics processor described according to the aforementioned aspect.

[0018] In the geometry processing system provided by the present disclosure, the vertex cache module can perform a hit test on the vertices in the vertex stream without obtaining primitive assembly information, store the missed vertices in the cache, and then send them to the vertex processing pipeline to perform vertex processing operations. Later or at least partially in parallel with this, the primitive assembly pipeline can obtain the correspondence between each vertex and the vertex processing index, split the vertex stream into multiple primitives based on the correspondence, and hand over the obtained primitives to the primitive processing pipeline to perform primitive processing operations. Therefore, through the cooperation of various modules, vertex hit tests can be performed in the case of delayed primitive assembly. On the one hand, this helps to reduce the processing operations for repeated vertices in the vertex stream, improve vertex processing performance, and reduce system power consumption. On the other hand, since the vertex hit test and vertex processing process do not need to rely on the primitive assembly results, it also helps to achieve a higher degree of parallelism and improve the overall processing efficiency of the system.

[0019] These and other aspects of the application will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Further details, features and advantages of the present application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which:

[0021] Figure 1 Schematically illustrates an example block diagram of a geometry processing system according to some embodiments of the present disclosure;

[0022] Figure 2 Schematically illustrates an example block diagram of a vertex cache module according to some embodiments of the present disclosure;

[0023] Figure 3 Schematically illustrates task examples according to some embodiments of the present disclosure;

[0024] Figure 4 Schematically illustrates an example flow chart of a hit test performed in a vertex cache module according to some embodiments of the present disclosure;

[0025] Figure 5 Schematically illustrates an example block diagram of a primitive assembly pipeline according to some embodiments of the present disclosure;

[0026] Figure 6 Schematically illustrates an example flow chart of a hit test performed in a primitive assembly pipeline according to some embodiments of the present disclosure;

[0027] Figure 7 An example flowchart of a primitive assembly process according to some embodiments of the present disclosure is schematically shown;

[0028] Figure 8 Schematically illustrates an example block diagram of a geometry processing pipeline according to some embodiments of the present disclosure;

[0029] Fig.9A , 9B 9C schematically illustrates a processing procedure for an example vertex stream performed according to some embodiments of the present disclosure;

[0030] Fig. 10A , 10B An example block diagram of a graphics processor according to some embodiments of the present disclosure is schematically shown;

[0031] Fig.11A , 11B An example block diagram of a computing device according to some embodiments of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0032] Hereinafter, example embodiments will be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in various forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided only to enable those skilled in the art to clearly and fully understand the present disclosure. In the accompanying drawings, the same reference numerals represent the same or similar parts, and thus their repeated description will be omitted.

[0033] In addition, the described features, structures or characteristics may be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided so that those skilled in the art can fully understand the embodiments of the present disclosure. However, those skilled in the art will appreciate that the technical solutions of the present disclosure may be practiced without including one or more specific details, or other methods, components, devices, steps, etc. may be used to practice the technical solutions of the present disclosure.

[0034] The block diagrams shown in the accompanying drawings correspond only to functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the accompanying drawings are merely exemplary and do not necessarily include all contents, operations or steps, and the steps therein are not necessarily executed in the order described. For example, some operations or steps may be decomposed into sub-operations or sub-steps, while some operations or steps may be combined or partially combined, and some operations or steps may be executed in parallel or in reverse order. Therefore, the actual execution order of each operation or step may change according to the actual situation.

[0036] It should be understood that although the terms first, second, third, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. Therefore, the first element mentioned below may also be referred to as the second element, which does not deviate from the concept of the present disclosure. As used herein, the term "and / or" and similar terms include any, multiple and all combinations of the associated listed items.

[0037] Those skilled in the art will appreciate that the drawings are merely schematic diagrams of example embodiments, and the modules or processes in the drawings are not necessarily necessary for implementing the present disclosure, and therefore cannot be used to limit the protection scope of the present disclosure.

[0038] As mentioned earlier, the GPU's rendering pipeline is a key concept in computer graphics. It is a stage in the graphics processing unit (GPU) that is responsible for processing and converting 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. The goal of the rendering pipeline is to process graphics in an efficient manner and generate the final image. Through parallel processing and specialized hardware support, the GPU is able to perform these calculations quickly to achieve real-time graphics rendering.

[0039] In the related art, the rendering pipeline generally consists of multiple stages, each stage is used to perform specific geometric calculations and transformations. Generally speaking, the rendering pipeline can be divided into two parts: a geometry processing part (also called a geometry pipeline) and a pixel processing part (also called a fragment pipeline).

[0040] The geometry processing part can include the vertex input stage, vertex shading stage, primitive assembly stage, geometry shading stage, clipping stage and screen mapping stage. The geometry pipeline mainly focuses on the processing and transformation of geometric data. It receives input geometric primitives (such as points, lines, triangles, etc.) and converts them into geometric processing results mapped to pixel coordinates in screen space after a series of stages. The geometry processing part is responsible for performing geometric calculations such as model transformation, view transformation, projection transformation, as well as generating new geometric primitives, changing the shape, size, position, etc. of the primitives.

[0041] The pixel processing part generally includes the rasterization stage, the fragment shading stage, and the pixel operation stage. The fragment pipeline focuses on pixel-level processing. It receives the pixels on the screen generated by the rasterization stage and processes each pixel through a series of stages. The pixel processing part is responsible for performing pixel-level lighting calculations, texture sampling, depth testing, and other operations to determine the final color and attributes of each pixel.

[0042] Specifically, the vertex input stage is used to pass vertex data from the application to the geometry pipeline. Vertex data includes attributes such as position, color, and normal. In the vertex shading stage, the vertex shader calculates each input vertex and can perform various transformations and operations, such as model transformation, view transformation, projection transformation, etc., and can also calculate the illumination and texture coordinates of the vertex. In the primitive assembly stage, the primitive assembler converts the vertex into a complete geometric primitive, such as a point, line segment, triangle, etc. In the geometry shading stage, the geometry shader can operate and generate geometric primitives. It can create new primitives, change the shape, size, position, etc. of the primitives. In the clipping stage, the clipper compares the primitives with the screen boundary and discards the parts outside the viewing volume. The screen mapping stage is used to map the clipped primitives to pixel coordinates in the screen space. The rasterization stage is used to convert the converted geometric processing results into pixels on the screen and determine the position, color, and other attributes of each pixel. In the fragment shading stage, the fragment shader calculates each rasterized pixel, which can perform operations such as pixel-level illumination calculation, texture sampling, and depth testing. Pixel operations are used to perform final pixel processing such as blending, dithering, anti-aliasing, etc.

[0043] The geometry pipeline and the fragment pipeline are consecutive stages in the rendering pipeline. They are interdependent and work closely together to ultimately generate a visual image. The geometry pipeline converts geometric graphics data into geometric processing results corresponding to pixel coordinates, while the fragment pipeline performs final processing and calculations on the geometric processing results and the corresponding pixel data. Through parallel processing and specialized hardware support, the GPU can efficiently execute these pipeline stages to achieve real-time graphics rendering.

[0044] In the geometry processing of GPU, vertex cache can be used to reduce the number of vertices that the GPU needs to process. Vertex cache is a cache used in the graphics processing unit (GPU) to store processed vertex data. In graphics rendering, vertices are the basic components of 3D models, and each vertex contains information such as position, normal, texture coordinates, etc. During the rendering process, the vertices of the model need to be used multiple times, and the vertex cache is used to temporarily store these vertex data.

[0045] Vertex caching helps reduce repeated calculations of vertex data during the rendering process. When a vertex is processed, its result will be stored in the vertex cache. The next time the vertex is needed, it can be read directly from the cache without recalculating. This can improve rendering efficiency, especially when processing large 3D models, which can significantly reduce the amount of calculation required for rendering and improve rendering performance.

[0046] Vertex caching can be implemented by the GPU's internal hardware. After the vertex is input and before vertex shading begins, the GPU can perform a hit-test on the input vertex. If the input vertex hits a vertex in the cache, the GPU does not need to start the vertex shading program for the newly input vertex, but uses the processing result of the previously existing vertex. If the input vertex does not hit any vertex in the cache, the GPU needs to start the vertex shading program for the newly input vertex, and the GPU also inserts the vertex into the vertex cache for subsequent vertices to perform hit tests.

[0047] In the related art, vertex hit testing is generally not performed on a single vertex, but on a complete primitive as a basic unit, that is, it is necessary to perform hit testing on all vertices in the same primitive at the same time, so as to ensure that the vertex shading results of the same primitive can be output by the GPU at the same time. In this case, before performing the vertex hit test, it is necessary to obtain the primitive information. In other words, it is necessary to first split the vertex stream into primitives, and then perform vertex hit testing on primitives. However, there is a strong dependency between the primitive splitting operations performed on different cores of the GPU. For example, each core can be used to process a part of the vertex stream, but the way in which the part of the vertex stream is split into primitives needs to depend on the primitive splitting of the previous part of the vertex stream. Therefore, large-scale parallel execution of primitive splitting is difficult to achieve. This in turn affects the parallelism of the vertex processing operation and reduces the overall vertex stream processing speed. This is obviously not conducive to the improvement of the processing efficiency of the GPU.

[0048] Based on the above analysis, in order to make full use of the advantages of parallel processing and improve the processing efficiency of vertex streams, the present disclosure proposes the following Figure 1 The geometry processing system 100 is shown. Figure 1 As shown, the geometry processing system includes a vertex cache module 110 , a vertex processing pipeline 120 , a primitive assembly pipeline 130 , and a primitive processing pipeline 140 .

[0049] The vertex cache module 110 may be configured to: receive a vertex stream, wherein the vertex stream includes a plurality of vertex indices, each vertex index representing a vertex; for each vertex index, perform a hit test based on a cache, and store a missed vertex index in the cache; send the vertex index received in the cache to the vertex processing pipeline; for each vertex in the vertex stream, perform a hit test based on the cache, and store a missed vertex in the cache; and, according to the order in which each vertex is stored in the cache, send the vertices in the cache to the vertex processing pipeline 120. In various embodiments of the present disclosure, the vertex stream may be understood as a data stream including a plurality of vertex indices, wherein each vertex index may be used to represent a vertex, and the vertex index may take any data form as required, as long as it can be used to represent and distinguish different vertices. According to the actual application scenario requirements, the vertex stream can contain any number of vertex indexes, some of which can be the same index value, that is, corresponding to the same vertex. For example, the vertex stream can contain eight vertex indexes, such as "ABCDEABF", where the first vertex index and the sixth vertex index are the same index value, and the second vertex index and the seventh vertex index are the same index value. The vertex stream can come from a processing module outside the geometry processing system. Exemplarily, the GPU can receive a drawing instruction from an application and obtain a vertex stream according to the drawing instruction, such as obtaining a vertex stream from a memory or generating a vertex stream by itself, and the vertex stream can be provided to the geometry processing system inside the GPU to perform geometry processing. Or, exemplarily, for a GPU with multiple graphics processing cores, each core can obtain a portion of the vertex stream in the total vertex stream, and the portion of the vertex stream can be provided to the geometry processing system inside the core to perform geometry processing. Further exemplarily, each core can include a vertex splitting module, which can obtain the portion of the vertex stream that should be processed by the core in the total vertex stream based on instructions from the application and system configuration.

[0050] In various embodiments of the present disclosure, a hit test can be understood as, for a vertex index in a vertex stream, determining whether the same vertex index already exists in the corresponding cache. If so, it is considered a hit, and if not, it is considered a miss. For a missed vertex index, it can be added to the cache. Optionally, the vertex index added to the cache can be sent to the vertex processing pipeline 120 in real time, or the vertex index in the cache can be sent to the vertex processing pipeline 120 when a preset condition is met, for example, the vertex index can be sent when it is found that the cache is full or the number of vertex indices in the cache reaches a preset threshold condition. Optionally, when sending the vertex index in the cache to the vertex processing pipeline 120, all the vertex indices in the cache can be sent at one time, or a portion of the vertex indices, such as one or more of the vertex indices, can be sent. Through the above-mentioned cache and hit test mechanism, the cache can record the vertex indexes received by the vertex cache module 110 within a period of time. If it is found that the newly received vertex index already exists in the cache, it means that the vertex index has been or will be sent to the vertex processing pipeline 120, and there is no need to send it repeatedly; if it is found that the newly received vertex index does not exist in the cache, it means that the vertex index needs to be sent to the vertex processing pipeline 120 to perform vertex processing, and it can be added to the cache. In this way, the number of times the vertex processing program (such as the vertex shading program) is run can be significantly reduced, the vertex processing efficiency can be improved, and the system power consumption can be reduced.

[0051] The vertex processing pipeline 120 can be configured to: for each vertex index received, process the vertex represented by the vertex index, and store the obtained vertex processing data in the vertex memory. Exemplarily, the vertex processing pipeline 120 can process the received vertex indexes one by one to obtain vertex processing data corresponding to each received vertex index. For example, based on the received vertex index, the corresponding vertex data, such as the position, color, normal and other attribute data of the vertex represented by the vertex index, can be obtained. Subsequently, the vertex shader can be started to process the obtained vertex data, wherein the vertex shader can be a user-defined vertex shader program. For the vertex processing pipeline 120, it can always work in a mode of inputting a vertex index and outputting a vertex processing data. That is, the vertex processing pipeline 120 will not increase or decrease the number of vertices. The vertex processing data stored in the vertex memory can be read and used by subsequent pipelines or other modules.

[0052] The primitive assembly pipeline 130 can be configured to: receive a vertex stream; obtain a mapping relationship between vertex indices in the vertex stream and vertex processing indices, wherein each vertex processing index corresponds to vertex processing data obtained based on the corresponding vertex index in the vertex memory; determine multiple primitives based on the vertex stream, wherein each primitive corresponds to a specified number of vertex indices; and send multiple primitives to the primitive processing pipeline. Exemplarily, the vertex processing index can be a single index, or a combination of two or more indexes at different levels, as long as it can be used to distinguish vertex processing data obtained based on different vertex indices in the vertex memory. Optionally, the primitive assembly pipeline 130 can obtain the mapping relationship between vertex indices in the vertex stream and vertex processing indices in any manner. For example, the vertex cache module 110 can record the mapping relationship between each vertex and the vertex processing index in the process of performing a hit test or sending a vertex index to the vertex processing pipeline 120, and send the recorded mapping relationship to the primitive assembly pipeline 130; or, the vertex processing pipeline 120 can record the mapping relationship between each vertex index and the vertex processing index in the process of processing the vertex represented by the vertex index or storing vertex processing data, and send the recorded mapping relationship to the primitive assembly pipeline 130; or, the primitive assembly pipeline 130 can construct the mapping relationship between each vertex index and the vertex processing index according to the hit test and vertex index sending logic in the vertex cache module 110, such as determining the mapping relationship by performing the same operation as the hit test process in the vertex cache module 110; etc. Optionally, this mapping relationship can be represented, stored and / or sent through a mapping table or other optional methods for query use. Optionally, the vertex stream can be split into multiple primitives based on information about primitive splitting acquired in advance and / or in real time, such as information about the topological structure of the primitive (such as point, line, triangle, etc.), the starting primitive number, the starting vertex of the primitive splitting, etc. Exemplarily, in the case of using a triangle primitive, each primitive can include three vertices. Exemplarily, sending multiple primitives to the primitive processing pipeline can include: sending primitive information of multiple primitives to the primitive processing pipeline, wherein the primitive information can include one or more of the following items: the vertex index corresponding to each primitive, the vertex processing index corresponding to each primitive, and the vertex processing data corresponding to each primitive. Exemplarily, for each vertex index in each primitive, the corresponding vertex processing index can be found in a data storage structure such as a mapping table according to the vertex index of the vertex. As mentioned above, the vertex processing index can correspond to the vertex processing data obtained based on the corresponding vertex index in the vertex memory, so the vertex processing data corresponding to the vertex can be located in the vertex memory based on the vertex processing index of the vertex.

[0053] The primitive processing pipeline 140 may be configured to: perform primitive processing for each primitive received based on the vertex processing data corresponding to the primitive. The vertex processing data corresponding to each primitive may be obtained from the vertex memory based on the vertex processing index corresponding to the primitive, wherein the vertex processing index corresponding to the primitive may be determined based on the vertex index corresponding to the primitive according to a mapping relationship. Optionally, the primitive assembly pipeline 130 may determine the vertex processing index corresponding to each primitive based on the vertex index corresponding to each primitive according to the mapping relationship, and the primitives sent from the primitive assembly pipeline 130 to the primitive processing pipeline 140 may include the vertex processing index corresponding to each primitive, and accordingly, the primitive processing pipeline 140 may locate and obtain the corresponding vertex processing data in the vertex memory according to the vertex processing index corresponding to each primitive; or, optionally, the primitives sent from the primitive assembly pipeline 130 to the primitive processing pipeline 140 may include the vertex index corresponding to each primitive and the above-mentioned mapping relationship, and accordingly, The primitive processing pipeline 140 can determine the vertex processing index corresponding to each primitive based on the vertex index corresponding to each primitive according to the mapping relationship, and locate and obtain the corresponding vertex processing data in the vertex memory according to the vertex processing index corresponding to each primitive; or, optionally, the primitive assembly pipeline 130 can determine the vertex processing index corresponding to each primitive based on the vertex index corresponding to each primitive according to the mapping relationship, and then obtain the vertex processing data from the vertex memory based on the vertex processing index, and the primitives sent from the primitive assembly pipeline 130 to the primitive processing pipeline 140 can directly include the vertex processing data corresponding to each primitive. Exemplarily, primitive processing can include various processing operations in units of primitives, such as one or more of geometric shading, rasterization, tessellation, etc.

[0054] In the above-mentioned geometry processing system 100, the mapping relationship between vertex index and vertex processing index is used as a medium to achieve decoupling between the vertex processing pipeline and the primitive assembly pipeline, so that the operation of the vertex processing pipeline (such as the vertex hit test therein) does not depend on the primitive assembly result, but is executed in advance on a vertex basis. This can omit the time for vertex processing operations to wait for primitive assembly, and help to further improve the parallelism of vertex processing, thereby helping to improve the geometry processing efficiency, and then help to improve the processing efficiency of the overall graphics processing system. At the same time, through the vertex hit test, it is also possible to effectively reduce the vertex processing operations for vertices that appear repeatedly in the vertex stream, improve the performance of vertex processing, and reduce the power consumption of the system.

[0055] In some embodiments, the vertex cache module 110 may send the vertices in the cache to the vertex processing pipeline 120 according to the order in which the vertices are stored in the cache, and the vertex processing pipeline 120 may process the vertices represented by each vertex index in turn according to the order in which the vertex index is received. In such embodiments, the order in which the vertex indexes are sent to the vertex processing pipeline 120 may be consistent with the order in which they are added to the cache, and the vertex processing pipeline 120 will not change the order of the input vertex indexes, but will output the obtained vertex processing data to the vertex memory in the order in which they are input. In this case, the order in which the vertex indexes are processed by the vertex processing pipeline 120 is consistent with the order in which the vertex processing data corresponding to the vertex indexes are stored in the vertex memory, the order in which the vertex indexes are sent to the vertex processing pipeline 120, and the order in which the vertex indexes are stored in the cache in the vertex cache module 110. This helps to more conveniently obtain the mapping relationship between vertex indices and vertex processing indices, for example, it is convenient for the primitive assembly pipeline 130 to independently construct the mapping relationship between each vertex index and vertex processing index according to the hit test and vertex index sending logic in the vertex cache module 110 .

[0056] Figure 2 An example block diagram of a vertex cache module 110 according to some embodiments of the present disclosure is schematically shown. Figure 2 As shown, the vertex cache module 110 may include a first hit test control module 111 and a task assembly module 112 .

[0057] The first hit test control module 111 may be configured to: perform a hit test based on the cache for each vertex index in the vertex stream, and store the missed vertex indexes in the cache 113; and send the cached vertex indexes to the task assembly module 112 according to the order in which the vertex indexes are stored in the cache 113, so that the task assembly module 112 assembles tasks based on the received vertex indexes and starts the vertex processing task. Exemplarily, while sending the vertex index, the first hit test control module 111 may also send control information to force the start of downstream task assembly and the execution of the vertex processing task.

[0058] More specifically, the first hit test control module 111 may be configured to: for each vertex index in the vertex stream, in response to the vertex index not hitting the cache 113 and the cache 113 is not full, store the vertex index in the cache 113, or, in response to the vertex index not hitting the cache 113 and the cache 113 is full, send at least a portion of the vertex indexes in the cache 113 to the task assembly module 112, clear the sent vertex indexes in the cache 113, and store the vertex index in the cache 113 after the clearing operation is performed. Optionally, the cache 113 may be a cache device inside the vertex cache module 110, or may be an external cache device accessible to the vertex cache module 110. By checking whether the cache 113 is full only when a missed vertex index occurs, it helps to further reduce the number of times the vertex processing program is run and improve the vertex processing efficiency. For example, when cache 113 is full, one or more subsequent new vertex indexes may still hit cache 113 and do not need to be added repeatedly. In this case, assuming that some or all of the vertices in cache 113 are sent and cleared immediately when cache 113 becomes full, the new vertex indexes that were originally hit may become unhittable, thereby increasing the number of vertices that need to be processed repeatedly.

[0059] like Figure 2 As shown, the vertex cache module 110 can receive the input vertex stream data and send it to the first hit test control module 111. Exemplarily, the first hit test control module 111 can perform a vertex hit test on each vertex index in the input vertex stream in turn, for example, for each vertex index, it can be compared with the vertex index cached in the cache 113. If there is a hit, for example, the vertex index cached in the current cache 113 includes an index value equal to the vertex index to be tested, then the next vertex is tested. Otherwise, if there is a miss, then the vertex index is added to the cache 113. Exemplarily, when there is a miss and a new vertex index needs to be added to the cache 113, it can be determined whether the cache 113 is full. If not full, the new vertex index can be directly added to the cache 113; if full, all or at least part of the vertex indexes in the cache 113 need to be sent to the task assembly module 112 first, and the sent vertex indexes are cleared, and then the new vertex index is added to the cache 113.

[0060] In some embodiments, the first hit test control module 111 may also be configured to: in response to completion of the vertex stream processing, send all vertex indexes in the cache 113 to the task assembly module 112 .

[0061] The task assembly module 112 may be configured to assemble tasks based on vertex indices received from the first hit test control module 111, wherein each task includes a preset number of vertex indices and corresponds to a task index. Exemplarily, the task assembly module 112 may receive and store vertex indices sent by the first hit test control module 111, and when the number of stored vertex indices reaches a preset number, a task may be assembled based on the stored vertex indices and sent to the downstream vertex processing pipeline 120 to start the corresponding vertex processing program.

[0062] For the vertex processing pipeline 120, in order to improve hardware performance and efficiency, after collecting a preset number of vertices (wherein the vertices can be represented by vertex indices), a vertex processing program, such as a vertex shader, can be started for these vertices, rather than starting the vertex processing program immediately when each new vertex appears. Exemplarily, the preset number can correspond to the number of threads possessed by a vertex processing module such as a vertex shader. For example, assuming that a vertex processing module such as a vertex shader in the vertex processing pipeline 120 has n threads, the task assembly module 112 can assemble every n vertices into a task and send it to the vertex processing pipeline 120, so that the vertex processing pipeline 120 starts a vertex processing program for the n vertices under the task, wherein n is an integer greater than 0, such as 8, 16, 32, 64, etc. In the GPU architecture, a wave / warp can represent a group of continuous threads in the execution process of a processing program such as a shader, and these threads can execute the same instructions together. The number of threads contained in a wave / warp can vary according to different GPU architectures. For example, the GPU architecture can use execution models such as SIMD (Single Instruction, Multiple Data) and SIMT (Single Instruction, Multiple Threads), where threads in a wave / warp can execute the same instruction, but the data they operate on can be different. By assembling the above tasks and starting the vertex processing program for the vertices under a task, the parallel execution capability of the wave / warp can be maximized, thereby helping to improve program execution efficiency.

[0063] For further convenience of understanding, a vertex processing module (such as a vertex shader) with 8 threads is used as an example. Figure 3Two tasks based on vertex stream assembly are shown, where task 0 contains vertices A, B, C, D, E, F, G, H, and task 1 contains vertices I, J, K, A, L, G, H, M, where each letter is a vertex index and represents a corresponding vertex. Since the first hit test control module 111 will send part or all of the cached vertex indexes to the task assembly module 112 when the cache 113 is full or the number of vertex indexes reaches a threshold, a vertex index may appear in multiple tasks. For example, in Figure 3 In the example, A, G, and H appear in both Task 0 and Task 1. It should be understood that Figure 3 The case of 8 threads shown is only for the convenience of explanation and demonstration. When the solution proposed in the present disclosure is actually implemented, the number of vertex indexes included in each task can be determined according to the actual number of threads.

[0064] Exemplarily, the number of vertex indexes sent by the first hit test control module 111 to the task assembly module 112 each time may be equal to the number of vertex indexes included in each task, that is, the aforementioned preset number. At this time, one task may be assembled for each vertex index sent. Alternatively, the number of vertex indexes sent by the first hit test control module 111 to the task assembly module 112 each time may also be greater than or less than the preset number. If the number of vertex indexes sent is greater than the preset number, the task assembly module 112 may assemble more than one task based on the vertex indexes sent each time. For example, assuming that the number of vertices sent each time is 128, and the number of vertex indexes included in each task is 32, then the vertex index sent each time may correspond to 4 tasks. If the number of vertex indexes sent is less than the preset number, the task assembly module 112 may assemble one task based on the vertex indexes sent multiple times. For example, assuming that the number of vertex indexes sent each time is 32, and the number of vertex indexes included in each task is 128, then every 4 vertex indexes sent may correspond to 1 task. In the example where the first hit test control module 111 sends all vertex indexes in the cache 113 to the task assembly module 112 when the cache 113 is full, the number of vertex indexes sent each time is equal to the capacity of the cache 113. The larger the capacity of the cache 113, such as being larger than the number of vertex indexes included in each task, such as 2 times, 4 times, etc., the larger the capacity of the cache 113, the larger the search for duplicate vertex indexes can be, thereby helping to reduce the number of executions of the vertex processing program and helping to improve the efficiency of geometry processing.

[0065] In some embodiments, the vertex processing index may include a task index corresponding to the vertex index and a ranking index in the corresponding task. The first hit test control module 111 may also be configured to: initialize the current task index, such as to 0 or other preset values, before starting to process the vertex stream; update the current task index each time after sending the vertex index to the task assembly module 112, wherein the sent vertex indexes are sent in the order in which they are stored in the cache and correspond to the current task index before the update. The task index may represent the task to which the vertex index or the corresponding vertex belongs, and the ranking index may represent the ranking of the vertex index or the corresponding vertex in the corresponding task. Through the task index and the ranking index, each vertex index and its corresponding vertex processing data may be located more clearly and quickly. Exemplarily, when the number of vertex indices sent by the first hit test control module 111 to the task assembly module 112 each time is equal to the number of vertex indices included in each task, the first hit test control module 111 can update the current task index by accumulating 1 each time after sending the vertex index to the task assembly module 112. At this time, each task index can correspond to one task; when the number of vertex indices sent by the first hit test control module 111 to the task assembly module 112 each time is greater than the number of vertex indices included in each task, the first hit test control module 111 can update the current task index by accumulating 1 each time after sending the vertex index to the task assembly module 112. At this time, each task index can correspond to two or more tasks, wherein each task can correspond to Different subtask indexes under the task index, or, the current task index can be directly updated by accumulating a value greater than 1, so that each task index still corresponds to a task; when the number of vertex indexes sent by the first hit test control module 111 to the task assembly module 112 each time is less than the number of vertex indexes contained in each task, the first hit test control module 111 can update the current task index by accumulating 1 after sending the vertex index to the task assembly module 112 each time. At this time, multiple task indexes can correspond to one task, wherein the multiple task indexes can be regarded as multiple sub-indexes under the total task index of the task, or, the current task index can be directly updated by accumulating 1 after sending the vertex index multiple times, so that each task index still corresponds to a task. Those skilled in the art can understand that in the above-mentioned various cases, according to the quantitative relationship between the number of vertex indexes sent each time and the preset number of vertex indexes contained in each task, the conversion of the task index, the subtask index and the position index in the corresponding task can be determined by multiplication and division operations, which will not be elaborated here.

[0066] To further facilitate understanding, Figure 4Schematically illustrates an example flow chart of a hit test performed in a vertex cache module (eg, in a first hit test control module) according to some embodiments of the present disclosure. Figure 4 As shown, after starting, you first need to initialize the data, such as initializing the task ID to 0. Figure 4 In the example shown, the task ID corresponds to the task index described above. Next, each time a vertex is input, a hit test needs to be performed for the input vertex, where each vertex is represented by a vertex index. If it hits, it means that the vertex index of the vertex already exists in the cache, that is, the vertex already exists in the task to be sent / sent, so there is no need to send the task again for the vertex. At this point, the next input vertex can be processed. If it misses, it means that the vertex index of the vertex does not exist in the task to be sent / sent (in fact, the vertex represented by the vertex index may have been processed, but due to the limited cache capacity, more vertex index information cannot be cached at the same time, resulting in a miss), so the missed vertex needs to be processed at this time. Before adding the missed vertex to the cache, it is necessary to check whether the cache has enough remaining space to store the vertex index of the missed vertex. If the cache does not have enough remaining space, that is, the cache is full, then control information needs to be sent to drive the downstream task assembly pipeline to assemble tasks based on the previously accumulated vertices and start vertex processing tasks for these vertices. For example, the cache content, i.e., the vertex index in the cache, and the control information indicating the assembly task and / or the start of the task processing program can be sent to the task assembly pipeline. At the same time, the task ID value can be accumulated to prepare data for the next vertex. Since the vertex index in the cache has been sent at this time, the cache information of these vertex indexes can be safely cleared, and the contents in the cache can all be marked as invalid. Subsequently, the vertex index of the missed vertex can be added to the cache. If the cache has enough remaining space, i.e., the cache is not full, then the vertex index of the missed vertex can be directly added to the cache. Next, the next vertex can be processed. If there are no more vertices to be processed, then the vertex processing task represented by the vertex index that is not full in the cache can be forced to start according to the process when the processing cache is full. That is, the cache content, i.e., the vertex index in the cache, and the control information indicating the assembly task and / or the start of the task processing program can be sent to the task assembly pipeline. At the same time, the task ID value can be accumulated, and the contents in the cache can all be marked as invalid.

[0067] Figure 5 An example block diagram of a primitive assembly pipeline 130 according to some embodiments of the present disclosure is schematically shown.

[0068] In some embodiments, the primitive assembly pipeline 130 may include a second hit test control module 131, which may be configured to: perform a hit test based on the shadow cache 133 for each vertex index in the vertex stream, and store the missed vertex indexes into the shadow cache 133; and determine the vertex processing index corresponding to each vertex index according to the order in which the vertex indexes are stored in the shadow cache 133 to determine the aforementioned mapping relationship.

[0069] The second hit test control module 131 can achieve similar functions as the first hit test control module 111 in the vertex cache module 110. The second hit test control module 131 can perform hit tests on each vertex index in the vertex stream and cache missed vertices based on the shadow cache 133. The shadow cache 131 can be regarded as the shadow of the cache 111 in the vertex cache module 110. Since the hit test logic executed by the second hit test control module 131 can be consistent with that of the first hit test control module 111, and both process the same vertex stream, the cache and change of the vertex index in the shadow cache 131 can be consistent with that of the cache 111. Therefore, with the help of the second hit test control module 131 and the shadow cache 133, the mapping relationship between each vertex index and the vertex processing index in the vertex cache module 110 and the vertex processing pipeline 120 can be reconstructed. For example, the correspondence between each vertex index and the task index and the position index can be reconstructed, that is, the mapping relationship between each vertex index and the task in the vertex cache module 110 and the vertex processing pipeline 120 can be reconstructed. This mapping relationship can be filled into the reconstruction mapping table 134, for example, and can be used by other modules to obtain the vertex processing index corresponding to each vertex index, and then locate the corresponding vertex processing data in the vertex memory. It should be noted that although the execution logic of the hit test in the second hit test control module 131 is similar to that of the hit test in the first hit test control module 111, and the results generated are also the same, the two are executed independently of each other, and the two can be executed synchronously or asynchronously.

[0070] Different from the first hit test control module 111 , the second hit test control module 131 does not need to perform operations such as sending vertex indexes, and does not need to perform operations such as sending control information to start downstream task assembly and execution of vertex processing tasks.

[0071] In some embodiments, similar to the first hit test control module 111, the second hit test control module 131 can be configured to: perform the following processing for each vertex index in the vertex stream, in response to the vertex index not hitting the shadow cache 133 and the shadow cache 133 is not full, store the vertex index in the shadow cache 133; in response to the vertex index not hitting the shadow cache 133 and the shadow cache 133 is full, clear at least a portion of the vertex index in the shadow cache 133, and store the vertex index in the shadow cache 133 after the clearing operation. Different from the first hit test control module 111, the second hit test control module 131 does not need to send the vertex index, but only needs to perform the clearing operation of the vertex index according to the same logic as the first hit test control module 111 to send and clear the vertex index.

[0072] In some embodiments, as mentioned above, the vertex processing index may include the task index corresponding to the vertex index and the position index in the corresponding task. In such embodiments, the second hit test control module 131 may also be configured as follows: before starting to process the vertex stream, initialize the current task index and the current position index; each time after storing the vertex index in the shadow cache 133, determine the task index and the position index of the vertex index based on the current task index and the current position index, and update the current position index; each time after clearing the vertex index in the shadow cache 133, update the current task index and reset the current position index. The initialization and update logic of the current task index in the second hit test control module 131 may be consistent with that of the first hit test control module 111, and will not be elaborated here. The current position index in the second hit test control module 131 may be initialized to 0, and after storing the vertex index in the shadow cache 133 each time, the current position index may be updated by accumulating 1, and, after clearing the vertex index in the shadow cache 133 each time, the current position index may be reset to 0. Thus, it can be ensured that the ranking index determined for each vertex index can correctly reflect its ranking order in the corresponding task, as well as the order in which it is processed and stored. It can be understood that when the number of vertex indices sent each time is different from the preset number of vertex indices contained in each task, the ranking index determined by the above logic can also be converted into the ranking index in the subtask or the total task through multiplication and division operations.

[0073] To further facilitate understanding, Figure 6 Schematically illustrates an example flow chart of a hit test performed in a primitive assembly pipeline (eg, in a second hit test control module) according to some embodiments of the present disclosure. Figure 6 As shown, after starting, you first need to initialize the data, such as initializing the task ID to 0 and the internal index to 0. Figure 6In the example shown, the task ID corresponds to the task index described above, and the internal index corresponds to the position index described above. Next, each time a vertex is input, a hit test needs to be performed for the input vertex, where each vertex is represented by a vertex index. If it is a hit, it means that the vertex index of the vertex already exists in the shadow cache and does not need to be added to the shadow cache. At this point, the next input vertex can be processed. If it is a miss, it means that the vertex index of the vertex does not exist in the shadow cache, so it needs to be added to the shadow cache at this time. Before adding the vertex index of the missed vertex to the shadow cache, it is necessary to check whether the shadow cache has enough remaining space to store the vertex index. If the shadow cache does not have enough remaining space, that is, the shadow cache is full, then it is necessary to accumulate the task ID value, reset the internal index value to 0, and clear the cache information of the vertex index in the shadow cache, such as marking all the contents in the shadow cache as invalid. Subsequently, the vertex index of the missed vertex can be added to the shadow cache, and the vertex index, the current task ID, and the current internal index are filled into the reconstruction mapping table, where the filled current task ID and the current internal index can be regarded as the vertex processing index corresponding to the vertex index. If the cache has enough remaining space, that is, the cache is not full, then the vertex index of the missed vertex can be directly added to the cache, and the vertex index, current task ID, and current internal index can be filled into the reconstruction mapping table. Next, the next vertex can be processed. If there are no more vertices to be processed, then the operation can be terminated.

[0074] With reference Figure 4 Compared with the process described in reference Figure 6 In the described process, since there is no need to actually start any vertex processing program in the primitive assembly pipeline, there is no need to send cache contents or control information. However, it is necessary to perform an additional operation of filling and reconstructing the mapping table to record the mapping relationship between the obtained vertex index and the vertex processing index (such as the vertex processing index composed of the task index and the position index) for subsequent reading.

[0075] In some embodiments, the primitive assembly pipeline 130 also includes a primitive assembly module 132. The primitive assembly module 132 can be configured to: receive a primitive splitting initial state, wherein the primitive splitting initial state can indicate a rule for determining a primitive based on a vertex stream; for each vertex index in the vertex stream, the primitive corresponding to the vertex index can be determined according to the primitive splitting initial state, and, based on the aforementioned mapping relationship, the vertex processing index corresponding to the vertex index can be determined; and the vertex processing index corresponding to each primitive is sent to the primitive processing pipeline. The primitive processing pipeline 140 can be configured to: for each received primitive, based on the vertex processing index corresponding to the primitive, obtain the vertex processing data corresponding to the primitive from the vertex memory, and perform primitive processing. Exemplarily, the primitive splitting initial state may include one or more of the following items: the topological type of the primitive, the starting vertex number, the valid state of the starting vertex, the number of the starting primitive, the offset of the starting vertex, the winding order of the starting primitive, etc., wherein the topological type of the primitive may include, for example, a point, a line, a line strip, a loop line, a triangle, a triangle strip, a triangle fan, etc., which may specify the number of vertices contained in each primitive; one or more of the starting vertex number, the valid state of the starting vertex, and the offset of the starting vertex may indicate or be used to determine the vertex for starting to assemble the primitive; the winding order of the starting primitive indicates the connection order of the vertices of the starting primitive when forming the starting primitive, such as clockwise or counterclockwise. Optionally, in a GPU with multiple graphics processing cores, the primitive splitting initial state in one graphics processing core may come from the previous graphics processing core, or the primitive splitting initial state of each graphics processing core may come from a unified central split graphics processing core. After receiving the initial state of primitive splitting, the primitive assembly module 132 can perform primitive splitting on the input vertex stream. At the same time, for the split primitives, it can refer to the aforementioned mapping relationship, such as referring to the content in the reconstruction mapping table 134, to find the vertex processing index corresponding to the vertex index that constitutes the primitive, such as the task index and the position index, so as to find the location of the vertex processing data of the vertex represented by the vertex index in the vertex memory for use by the downstream primitive processing pipeline 140.

[0076] Exemplarily, before sending the vertex processing index corresponding to each primitive to the primitive processing pipeline 140, the primitive assembly pipeline 130 can determine whether the corresponding vertex has been processed, that is, whether the corresponding vertex processing data already exists in the vertex memory, based on the vertex processing index corresponding to the primitive. In response to all vertex processing data corresponding to a primitive having been stored in the vertex memory, the primitive can be sent to the primitive processing pipeline 140. Alternatively, exemplarily, the primitive assembly pipeline can directly send the vertex processing index corresponding to each primitive to the primitive processing pipeline 140, and the primitive processing pipeline 140 can determine whether the corresponding vertex processing data has been stored in the vertex memory based on the vertex processing index, and can perform primitive processing for the primitive based on the acquired vertex processing data after all vertex processing data corresponding to a primitive can be obtained from the vertex memory. Whether the vertex processing data has been stored in the vertex memory can be determined by querying the vertex memory based on the vertex processing index, or it can be determined based on information from the vertex processing pipeline 120 about whether the vertex has been processed. For example, assuming that the vertex processing index corresponding to a vertex index is 0-2, where 0 is the task index and 2 is the position index, then when task 0 has been executed by the vertex processing pipeline 120, it can be determined that the vertex index or the vertex corresponding to the vertex processing index has been processed and its vertex processing data can be obtained from the vertex memory.

[0077] In some embodiments, the initial state of primitive splitting may include starting vertex information, and the starting vertex information may indicate the starting vertex in the vertex stream for assembling the primitive. For example, the starting vertex information may be characterized by one or more of the aforementioned starting vertex number, the valid state of the starting vertex, the offset of the starting vertex, etc. The starting vertex may indicate the vertex index from which the primitive is to be assembled in the vertex stream. In such embodiments, when determining the primitive corresponding to the vertex index according to the initial state of primitive splitting, in response to the vertex index being before the starting vertex, the vertex index may be directly skipped. In addition, when determining the primitive corresponding to the vertex index according to the initial state of primitive splitting, in response to the number of vertex indexes from the vertex index to the end of the vertex stream being less than a specified number, the vertex index and the vertex index after the vertex index may be directly discarded. This helps to reduce the number of invalid operations and improve overall processing efficiency.

[0078] Further exemplary, the primitive assembly module 132 may be configured according to Figure 7 The flowchart shown in the figure is used to perform the primitive assembly operation. Figure 7As shown, after the primitive assembly module 132 receives the initial state of primitive splitting, it can start to assemble primitives based on vertex streams. Specifically, a vertex index in the vertex stream can be input, and then it is determined whether this vertex index is a vertex index that needs to be skipped according to the initial state of primitive splitting. If yes, then skip this vertex index and process the next vertex index. If not, then start assembling primitives. At this time, the assembled primitives come from the vertex index in the input vertex stream data. When assembling primitives, the reconstruction mapping table 134 can be searched according to the vertex index to find the vertex processing index corresponding to the vertex index, such as the task index and the position index, and then the vertex processing data of the corresponding vertex can be located in the vertex memory, such as the shading result data of the vertex. When the vertex processing data of all vertices constituting the primitive have been queried in the vertex memory, the primitive can be sent to the downstream primitive processing pipeline 140 for further primitive processing, including but not limited to starting the primitive shader, starting the surface subdivision pipeline or performing rasterization operations.

[0079] In addition, the existence of special points such as clipping points will not affect the implementation of the solution proposed in the present disclosure. In some embodiments, the vertex cache module 110 or the first hit test control module 111 therein may also be configured to: in response to the presence of one or more clipping points in the vertex stream, skip the one or more clipping points. Correspondingly, the second hit test control module 131 in the primitive assembly pipeline 130 may also be configured to: in response to the presence of one or more clipping points in the vertex stream, skip the one or more clipping points. Exemplarily, the clipping point may have a special value to distinguish it from a normal vertex index. In such embodiments, the determined mapping relationship is independent of the clipping point. However, the clipping point can still provide more information for assembling primitives in the primitive assembly stage, such as in the primitive assembly module 132.

[0080] Further illustratively, Figure 8 A schematic block diagram of a geometry processing pipeline 800 according to some embodiments of the present disclosure is shown, wherein the geometry processing pipeline 800 may include Figure 1 A system similar to the geometry processing system 100 shown in FIG. Figure 8 As shown, the geometry processing pipeline 800 may include a vertex cache module 810 , a vertex processing pipeline 820 , a primitive assembly pipeline 830 , a primitive processing pipeline 840 , and a vertex memory 850 .

[0081] Specifically, Figure 8As shown, the geometry processing pipeline 800 can receive vertex stream data transmitted by an external module. On the one hand, the vertex stream data is transmitted to the vertex cache module 810 and the subsequent vertex processing pipeline 820. After starting the vertex processing task such as the vertex shading task, the result of the vertex processing (i.e., the vertex processing data) is stored in the vertex memory 850. On the other hand, the vertex stream data is transmitted to the primitive assembly pipeline 830 to perform primitive assembly and subsequent primitive processing. For example, after the primitive assembly pipeline 830 receives the split initial state data, the primitive assembly can be started, and the primitive assembly information (such as the assembled primitive or other related information) is transmitted to the primitive processing pipeline 840. The primitive processing pipeline 840 can access the vertex memory 850 according to the primitive assembly information transmitted by the primitive assembly pipeline, obtain the corresponding vertex processing data, and perform further primitive processing, such as performing one or more of the processes such as rasterization, geometry shading, and tessellation. In addition, each module in the geometry processing pipeline 800 may have the same or similar features and advantages as the various embodiments of the geometry processing system 100 described above, which will not be described in detail here.

[0082] Below, reference Fig.9A , 9B , 9C describes an example processing process of a specific vertex stream.

[0083] like Fig.9A As shown, the input vertex stream data is "A, B, C, D, B, C, A, E, F, C, G, B, C, H, C, I, J, K, A, B, C", where each letter represents the vertex index of a vertex. Exemplarily, assume that the vertex processing in the vertex processing pipeline is performed by a vertex shader, and the vertex shader performs vertex processing at a granularity of 8 vertices, and the cache capacity is also 8. In this example, after hit testing each vertex index in the vertex stream according to the logic described in the previous embodiment, a total of two shader tasks, Task 0 and Task 1, are assembled and started. Task 0 processes vertices A, B, C, D, E, F, G, H, while Task 1 processes I, J, K, A, B, C. By Fig.9AIt can be seen that for Task 1, since the vertex stream data has ended, the shader task has to be forced to start, so Task 1 does not have all 8 vertices. When forming shader task 0, the mapping relationship can be as shown in the table on the right. For example, vertex A in the table is mapped to 0-0, which corresponds to the 0th vertex of Task 0, vertex B is mapped to 0-1, which corresponds to the 1st vertex of Task 0, and so on. When forming Task 1, the mapping relationship can also be as shown in the table on the right. For example, vertex I in the table is mapped to 1-0, which corresponds to the 0th vertex of Task 1, vertex J is mapped to 1-1, which corresponds to the 1st vertex of Task 1, and so on. In some embodiments, Fig.9A The two mapping tables shown may be a unified mapping table, or may be other forms of mapping relationship data, which may be transmitted from the vertex cache module to the primitive assembly pipeline so that the primitive assembly pipeline may obtain the mapping relationship between the vertex index and the vertex processing index; or, in some embodiments, Fig.9A The two mapping tables shown may not exist in the vertex cache module (but the mapping relationship reflected in the table is objectively present). The primitive assembly pipeline can reconstruct this mapping relationship based on the vertex hit test logic similar to that of the vertex cache module, such as reconstructing Fig.9A The mapping table shown.

[0084] Depend on Fig.9A It can be seen that the original input vertex stream provides a total of 21 vertex indices. However, after passing through the vertex cache module, only 2 tasks are run, and a total of 8+6=14 vertices are processed. Obviously, the hit test in the vertex cache module significantly reduces the number of duplicate vertices and the number of vertices required for vertex processing. However, since the last A, B, C vertices in the vertex stream are separated from the previous A, B, C vertices by more other vertex indices, the last A, B, C need to be processed again in Task 1.

[0085] Task 1 and Task 2 may be sent to the vertex processing pipeline, and after processing, the resulting vertex processing data may be output and stored in the vertex processor. After receiving the primitive splitting initial state, the primitive assembly pipeline may start splitting the vertex stream to assemble primitives.

[0086] For example, assuming that the primitive topology is a triangle list, and the initial split state sent indicates that the primitive needs to be assembled from the third vertex (i.e., skipping the first two vertices A and B), the primitive assembly result can be as follows: Fig. 9BAs shown. After skipping the first two vertices A and B, according to the rules of the triangle list, the assembled primitives are triangles CDB, CAE, FCG, BCH, CIJ, and KAB. The last single vertex C cannot constitute a complete primitive, so it can be discarded directly. During the primitive assembly process, the primitive assembly pipeline can find the vertex processing index of the vertex in each triangle according to the reconstruction mapping table, such as the task index and the position index. The relevant index can be further used to locate the vertex processing data of the vertex in the vertex memory. For example, for triangle CDB, vertex C is mapped to 0-2, D is mapped to 0-3, and B is mapped to 0-1, which means that for this triangle, it is necessary to obtain the relevant vertex processing data from the second, third, and first positions of the processing result of task 0 in the vertex memory.

[0087] For example, assuming that the primitive topology is a triangle list, and the initial split state sent indicates that the primitive needs to be assembled from the second vertex (i.e., skipping the first vertex A), the primitive assembly result can be as follows: Fig. 9C As shown in FIG. 1 , the assembled primitives are triangles BCD, BCA, EFC, GBC, HCI, and JKA. Similarly, the primitive assembly pipeline can still look up the vertex processing index of each vertex, such as the task index and the position index, according to the reconstruction mapping table, so as to find the processing result of the corresponding vertex in the vertex memory for further primitive processing.

[0088] Fig. 10A Schematically shows an example block diagram of a graphics processor 1000 according to some embodiments of the present disclosure. Fig. 10A As shown, the graphics processor 1000 may include at least one geometry processing pipeline 1010 - 1 to 1010 -N, where N is an integer greater than 0. Each of the at least one geometry processing pipeline 1010 - 1 to 1010 -N may include the geometry processing system 100 described according to various embodiments.

[0089] In some embodiments, the graphics processor 1000 may have Fig. 10B The structure shown. Fig. 10BAs shown, the graphics processor 1000 may include at least one graphics processing core 1100-1 to 1100-N (where N is an integer greater than 0), a system configuration module 1200, a system bus 1300, and a memory 1400, wherein each graphics processing core may include a geometry processing pipeline, for example, the geometry processing pipelines 1010-1 to 1010-N shown in the figure may be included in the corresponding graphics processing cores 1100-1 to 1100-N, respectively. As shown in the figure, all graphics processing cores may be homogeneous, so the performance of the graphics processor 1000 may be adjusted by simply increasing or decreasing the number of graphics processing cores to meet the requirements of throughput, performance, and power consumption of the graphics processor 1000 in different application scenarios, thereby reducing the complexity of design and verification. The system configuration module 1200 may be connected to the vertex splitting module of each graphics processing core to provide corresponding configuration information for each graphics processing core. Exemplarily, the system configuration module 1200 can be used to configure the state of the entire graphics processing system, such as the total number of graphics processing cores enabled, the number of vertices in a primitive packet (the number of vertices in each split vertex stream after the original vertex stream drawn by the drawing instruction is split), the central graphics processing core number, the mapping sequence number of each graphics processing core, etc. The bus 1300 can be an intra-chip bus or an on-chip bus. The memory 1400 can be SRAM, DRAM, or NVME, etc.

[0090] Each of the graphics processing cores 1100-1 to 1100-N mainly includes a vertex splitting module, a geometry processing pipeline, a pixel processing pipeline and a storage access arbitrator. The structure and function of the geometry processing pipeline have been described in various embodiments above, and will not be repeated here. The vertex splitting module can obtain the vertex stream portion that should be processed by the core in the total vertex stream based on instructions from the application and system configuration. The pixel processing pipeline can process the results of the geometry processing pipeline to obtain a visual graphic, which is mainly used to perform pixel-level processing, such as the various processes of the pixel processing part of the rendering pipeline described above. The storage access arbitrator can be used to manage access to the memory 1400 shared by multiple graphics processing cores via the bus 1200, such as storing the processing results of the geometry processing pipeline in the memory 1400, obtaining the results of the geometry processing pipeline from the memory 1400 for use by the pixel processing pipeline, and storing the processing results of the pixel processing pipeline in the memory 1400.

[0091] In addition, the graphics processor 1000 may have the same or similar features and advantages as the geometry processing systems described in the various embodiments above, which will not be described in detail herein.

[0092] Fig.11ASchematically shows an example block diagram of a computing device 1100 according to some embodiments of the present disclosure. Fig.11A As shown, the computing device 1100 may include Fig. 10A Or the graphics processor 1000 shown in FIG. 10B.

[0093] In some embodiments, the computing device 1100 may have Fig. 11B The structure shown. Fig. 11B As shown, the computing device 1100 may include a processing system 1101, a storage system 1102, an I / O interface 1103, and an application 1104. The processing system 1101 may represent a function of performing one or more operations through hardware, which may include a graphics processor 1000 and other processors, processing elements or processing circuits, such as a central processing unit (CPU). The storage system 1102 may include various volatile storage media (such as random access memory (RAM)) and / or non-volatile storage media (such as read-only memory (ROM), flash memory, optical disk, disk, etc.). In addition, the storage system may include various fixed media (e.g., RAM, ROM, fixed hard disk drive, etc.) and removable media (e.g., flash memory, removable hard disk drive, optical disk, etc.). One or more I / O interfaces 1103 may represent components or devices that allow a user to interact with the computing device 1100. Examples of input interfaces may include a keyboard, a mouse, a microphone, a scanner, a touch input device, a camera, a receiver, etc. Examples of output interfaces may include a display, a projector, a speaker, a printer, a transmitter, etc. The application 1104 may be stored as computer program instructions in a memory in the storage system 1102 so as to be executed by the processing system 1101 to perform various desired operations and functions.

[0094] It should be understood that, for the sake of clarity, embodiments of the present disclosure are described with reference to different functional units. However, it will be apparent that, without departing from the present disclosure, the functionality of each functional unit can be implemented in a single unit, in multiple units, or as a part of other functional units. For example, the functionality that is described as being performed by a single unit can be performed by multiple different units. Therefore, reference to a specific functional unit is only considered as a reference to a suitable unit for providing the described functionality, rather than indicating a strict logical or physical structure or organization. Therefore, the present disclosure can be implemented in a single unit, or can be physically and functionally distributed between different units and circuits.

[0095] Variations to the disclosed embodiments will be understood and effected by those skilled in the art in practicing the claimed subject matter by studying the drawings, the disclosure and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A geometry processing system, comprising: The vertex cache module is configured to: receive a vertex stream, wherein the vertex stream includes a plurality of vertex indices, each vertex index representing a vertex; for each vertex index, perform a hit test based on a cache, and store a missed vertex index into the cache; and send the vertex index in the cache to a vertex processing pipeline; The vertex processing pipeline is configured to: for each vertex index received, process the vertex represented by the vertex index, and store the obtained vertex processing data in the vertex memory; The primitive assembly pipeline is configured to: receive the vertex stream; obtain a mapping relationship between vertex indices in the vertex stream and vertex processing indices, wherein each vertex processing index corresponds to vertex processing data obtained based on the corresponding vertex index in the vertex memory; determine a plurality of primitives based on the vertex stream, wherein each primitive corresponds to a specified number of vertex indices; and send the plurality of primitives to the primitive processing pipeline; The primitive processing pipeline is configured to: for each received primitive, perform primitive processing based on vertex processing data corresponding to the primitive, The vertex processing data corresponding to each primitive is obtained from the vertex memory based on the vertex processing index corresponding to the primitive, wherein the vertex processing index corresponding to the primitive is determined based on the vertex index corresponding to the primitive according to the mapping relationship.

2. The geometry processing system according to claim 1, wherein: The sending of the vertex indexes in the cache to the vertex processing pipeline comprises: sending the vertices in the cache to the vertex processing pipeline according to the order in which the vertices are stored in the cache, The step of processing the vertex represented by each vertex index received includes: processing the vertex represented by each vertex index in sequence according to the order in which the vertex index is received.

3. The geometry processing system according to claim 1, wherein: The vertex cache module includes a first hit test control module and a task assembly module. The first hit test control module is configured to: for each vertex index in the vertex stream, in response to the vertex index not hitting the cache and the cache is not full, store the vertex index in the cache, or, in response to the vertex index not hitting the cache and the cache is full, send at least a portion of the vertex indexes in the cache to the task assembly module, clear the sent vertex indexes in the cache, and store the vertex index in the cache after the clearing operation is performed; The task assembly module is configured to assemble tasks based on vertex indexes received from the first hit test control module, wherein each task includes a preset number of vertex indexes and corresponds to a task index.

4. The geometry processing system according to claim 3, wherein: The vertex processing index includes the task index corresponding to the vertex index and the position index in the corresponding task. Wherein, the first hit test control module is further configured to: Before starting to process the vertex stream, initializing the current task index; Each time after sending a vertex index to the task assembly module, the current task index is updated, wherein the sent vertex index corresponds to the current task index before the update.

5. The geometry processing system according to claim 3 or 4, wherein: The first hit test control module is further configured to: in response to completion of processing of the vertex stream, send all vertex indexes in the cache to the task assembly module.

6. The geometry processing system according to any one of claims 1 to 4, wherein: The primitive assembly line comprises: The second hit test control module is configured to: perform a hit test based on the shadow cache for each vertex index in the vertex stream, and store the missed vertex indexes into the shadow cache; and determine the vertex processing index corresponding to each vertex index according to the order in which the vertex indexes are stored in the shadow cache to determine the mapping relationship.

7. The geometry processing system according to claim 6, wherein: The step of performing a hit test based on a shadow cache for each vertex index in the vertex stream and storing a missed vertex index in the shadow cache comprises: performing the following processing for each vertex index in the vertex stream: In response to the vertex index not hitting the shadow cache and the shadow cache is not full, storing the vertex index in the shadow cache; In response to the vertex index not hitting the shadow cache and the shadow cache being full, at least a portion of the vertex indexes in the shadow cache are cleared, and the vertex indexes are stored in the shadow cache after the clearing operation is performed.

8. The geometry processing system of claim 7, wherein: The vertex processing index includes the task index corresponding to the vertex index and the position index in the corresponding task. Wherein, the second hit test control module is further configured to: Before starting to process the vertex stream, initializing a current task index and a current position index; Each time after storing the vertex index into the shadow cache, determining the task index and the rank index of the vertex index based on the current task index and the current rank index, and updating the current rank index; Each time after the vertex index in the shadow cache is cleared, the current task index is updated and the current ranking index is reset.

9. The geometry processing system of claim 1, wherein: The primitive assembly line comprises: The primitive assembly module is configured to: receive a primitive splitting initial state, wherein the primitive splitting initial state indicates a rule for determining a primitive based on the vertex stream; for each vertex index in the vertex stream, determine the primitive corresponding to the vertex index according to the primitive splitting initial state, and determine the vertex processing index corresponding to the vertex index based on the mapping relationship; and send the vertex processing index corresponding to each primitive to the primitive processing pipeline; The primitive processing pipeline is configured to: for each received primitive, based on a vertex processing index corresponding to the primitive, obtain vertex processing data corresponding to the primitive from the vertex memory, and perform primitive processing.

10. The geometry processing system of claim 9, wherein: The primitive splitting initial state includes starting vertex information, and the starting vertex information indicates a starting vertex in the vertex stream for assembling a primitive. Wherein, determining the primitive corresponding to the vertex index according to the primitive splitting initial state includes at least one of the following two items: In response to the vertex index being before the start vertex, skipping the vertex index; In response to the number of vertex indices from the vertex index to the end of the vertex stream being less than the specified number, the vertex index and vertex indices subsequent to the vertex index are discarded.

11. The geometry processing system of claim 1 , wherein: The vertex cache module is further configured to: in response to one or more clipping points existing in the vertex stream, skip the one or more clipping points.

12. A graphics processor comprising at least one geometry processing pipeline, wherein: Each geometry processing pipeline of the at least one geometry processing pipeline comprises a geometry processing system according to any one of claims 1 to 11.

13. A computing device comprising the graphics processor according to claim 12.

Images