Geometry processing systems, graphics processors, computing devices

Abstract

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

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). Within 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: the geometry processing part (also known as the geometry pipeline) and the pixel processing part (also known as the fragment pipeline). The former focuses on the processing and transformation of geometric data, generally including vertex input, vertex shading, primitive assembly, set shading, clipping, screen mapping, etc.; the latter focuses on pixel-level processing, generally including rasterization, fragment shading, pixel operations, etc. The geometry pipeline and 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 GPUs is to increase rendering speed and achieve real-time, high-quality, and high-resolution rendering. This poses a significant challenge to GPU processing speed. To meet this challenge, one design approach is to fully utilize the parallel nature of rendering data and the advantages of hardware parallel computing. Therefore, how to fully utilize the characteristics and advantages of parallel processing to improve GPU processing speed has become a highly sought-after 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 help 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, comprising: a vertex cache module, 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 the cache, and store the vertex indexes that miss in the cache; send the vertex index 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, a plurality of primitives are determined, wherein each primitive corresponds to a specified number of vertex indices; the plurality of 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 the 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 sequence 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 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: 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 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.

[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; each time the vertex index is stored in the shadow cache, 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 the vertex index in the shadow cache is cleared, update the current task index and reset the current position index.

[0013] In some embodiments, the 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, obtain the vertex processing data corresponding to the primitive from the vertex memory based on the vertex processing index corresponding to the primitive, 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 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 clip points existing in the vertex stream, skip the one or more clip 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, and 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. Thus, through the cooperation of various modules, vertex hit tests can be performed when primitives are delayed in 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 hit testing performed in a primitive assembly pipeline according to some embodiments of the present disclosure;

[0027] Figure 7 Schematically illustrates an example flow chart of a primitive assembly process according to some embodiments of the present disclosure;

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

[0029] Figure 9A 、 9B 9C schematically illustrates a process of processing an example vertex stream according to some embodiments of the present disclosure;

[0030] Figure 10A 、 10B Schematically illustrates an example block diagram of a graphics processor according to some embodiments of the present disclosure;

[0031] Figure 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 many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided solely to enable those skilled in the art to clearly and fully understand the present disclosure. In the drawings, identical reference numerals denote identical or similar parts, and thus repeated description thereof will be omitted.

[0033] In addition, the described features, structures or characteristics may be combined in any suitable manner in one or more embodiments. 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 may be implemented in software, 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 illustrative and do not necessarily include all contents, operations, or steps. The steps therein are not necessarily executed in the order described. For example, some operations or steps may be broken down into sub-operations or sub-steps, 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 the operations or steps may vary depending on 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. Therefore, the first element mentioned below can 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 all combinations of any one, multiple, and all of the associated listed items.

[0037] Those skilled in the art will understand 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 scope of protection of the present disclosure.

[0038] As mentioned earlier, the GPU rendering pipeline is a key concept in computer graphics. It is the stage within the graphics processing unit (GPU) responsible for processing and converting graphics data for rendering. The rendering pipeline's primary task is to convert input geometric primitives (such as points, lines, triangles, etc.) into visible pixels on the screen. The goal of the rendering pipeline is to efficiently process the graphics and generate the final image. Through parallel processing and specialized hardware support, the GPU is able to perform these calculations quickly, enabling real-time graphics rendering.

[0039] In related technologies, a rendering pipeline generally consists of multiple stages, each of which is used to perform specific geometric calculations and transformations. Generally speaking, a rendering pipeline can be divided into two parts: the geometry processing part (also called the geometry pipeline) and the pixel processing part (also called the 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 and changing the shape, size, position, etc. of the primitives.

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

[0042] Specifically, the vertex input stage passes vertex data from the application to the geometry pipeline. Vertex data includes attributes such as position, color, and normals. In the vertex shading stage, the vertex shader performs calculations on each input vertex and can perform various transformations and operations, such as model transformation, view transformation, and projection transformation. It can also calculate lighting and texture coordinates for the vertex. In the primitive assembly stage, the primitive assembler converts vertices into complete geometric primitives, such as points, line segments, and triangles. In the geometry shading stage, the geometry shader operates on and generates geometric primitives. It can create new primitives and change their shape, size, and position. In the clipping stage, the clipper compares primitives against the screen bounds and discards those outside the viewing volume. The screen mapping stage maps the clipped primitives to pixel coordinates in screen space. The rasterization stage converts the transformed geometric processing results into pixels on the screen and determines attributes such as the position and color of each pixel. In the fragment shading stage, the fragment shader performs calculations on each rasterized pixel, performing pixel-level lighting calculations, 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 fragment pipeline are sequential stages in the rendering pipeline, interdependent and working closely together to ultimately produce a visual image. The geometry pipeline converts geometric data into geometric processing results corresponding to pixel coordinates, while the fragment pipeline performs the final processing and calculations on the geometric processing results and the corresponding per-pixel data. Through parallel processing and specialized hardware support, the GPU is able to efficiently execute these pipeline stages, enabling real-time graphics rendering.

[0044] Vertex caches can be used in GPU geometry processing to reduce the number of vertices the GPU needs to process. A vertex cache is a cache used in a graphics processing unit (GPU) to store processed vertex data. In graphics rendering, vertices are the basic components of a three-dimensional model. Each vertex contains information such as position, normal, and texture coordinates. During the rendering process, the vertices of a model need to be used multiple times, and the vertex cache is used to temporarily store this vertex data.

[0045] Vertex caching helps reduce repeated computation of vertex data during the rendering process. After a vertex is processed, the result is stored in the vertex cache. The next time the vertex is needed, it can be read directly from the cache without having to recalculate it. This improves rendering efficiency, especially when processing large 3D models, significantly reducing the amount of computation required for rendering and improving 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 instead 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 this vertex into the vertex cache for subsequent vertex hit testing.

[0047] In related art, vertex hit testing is generally not performed on a single vertex, but on a complete primitive as the basic unit. That is, it is necessary to perform hit testing on all vertices in the same primitive simultaneously to ensure that the vertex shading results of the same primitive can be output simultaneously by the GPU. 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 the primitive basis. 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 this part of the vertex stream is split into primitives depends 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 improving 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, this 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 can be configured to: receive a vertex stream, wherein the vertex stream includes multiple vertex indices, each vertex index representing a vertex; perform a hit test based on a cache for each vertex index, and store missed vertex indices in the cache; send the vertex indices in the cache to the vertex processing pipeline; perform a hit test based on the cache for each vertex in the vertex stream, and store missed vertices in the cache; and 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. In various embodiments of the present disclosure, a vertex stream can be understood as a data stream including multiple vertex indices, wherein each vertex index can be used to represent a vertex, and the vertex index can take any data form as required, as long as it can be used to represent and distinguish different vertices. Depending on the requirements of the actual application scenario, the vertex stream can contain any number of vertex indices, some of which can have the same index value, i.e., correspond to the same vertex. For example, the vertex stream can contain eight vertex indices, such as "ABCDEABF", where the first vertex index and the sixth vertex index have the same index value, and the second vertex index and the seventh vertex index have the same index value. The vertex stream can come from a processing module outside the geometry processing system. For example, the GPU can receive drawing instructions from the application and obtain a vertex stream based on the drawing instructions, such as obtaining a vertex stream from memory or generating a vertex stream itself. The vertex stream can be provided to the geometry processing system inside the GPU for geometry processing. Alternatively, for example, for a GPU with multiple graphics processing cores, each core can obtain a portion of the total vertex stream, which can be provided to the geometry processing system inside the core for geometry processing. Further for example, 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 determining, for a certain vertex index in a vertex stream, 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 vertex indices, can be sent. Through the above-mentioned cache and hit test mechanism, the cache can record the vertex indices 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 does not need to be sent again. 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 for vertex processing, and it can be added to the cache. This can significantly reduce the number of times the vertex processing program (such as the vertex shading program) is run, improve vertex processing efficiency, and reduce system power consumption.

[0051] The vertex processing pipeline 120 can be configured to: for each received vertex index, process the vertex represented by the vertex index and store the obtained vertex processing data in the vertex memory. For example, 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, corresponding vertex data can be obtained, such as various attribute data such as the position, color, and normal of the vertex represented by the vertex index. Subsequently, a vertex shader can be started to process the obtained vertex data, wherein the vertex shader can be a user-defined vertex shading program. The vertex processing pipeline 120 can always operate in a mode of inputting one vertex index and outputting one 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 the multiple primitives to the primitive processing pipeline. Exemplarily, the vertex processing index can be a single index, or a combination of two or more indices 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, when performing a hit test or sending a vertex index to the vertex processing pipeline 120, the vertex cache module 110 may record the mapping relationship between each vertex and the vertex processing index, and send the recorded mapping relationship to the primitive assembly pipeline 130; or, when processing a vertex represented by a vertex index or storing vertex processing data, the vertex processing pipeline 120 may record the mapping relationship between each vertex index and the vertex processing index, and send the recorded mapping relationship to the primitive assembly pipeline 130; or, the primitive assembly pipeline 130 may independently 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 by performing the same operation as the hit test process in the vertex cache module 110 to determine the mapping relationship; etc. Optionally, this mapping relationship may be represented, stored, and / or sent via a mapping table or other optional method for query use. Optionally, the vertex stream can be split into multiple primitives based on information about primitive splitting that is acquired in advance and / or in real time, such as information related to the topological structure of the primitive (such as a point, line, triangle, etc.), the starting primitive number, the starting vertex for primitive splitting, etc. Exemplarily, in the case of triangle primitives, each primitive can include three vertices. Exemplarily, sending multiple primitives to the primitive processing pipeline can include: sending primitive information of the multiple primitives to the primitive processing pipeline, wherein the primitive information can include one or more of the following: a vertex index corresponding to each primitive, a vertex processing index corresponding to each primitive, and vertex processing data corresponding to each primitive. Exemplarily, for each vertex index in each primitive, a corresponding vertex processing index can be searched in a data storage structure such as a mapping table based on the vertex index of the vertex. As described above, the vertex processing index can correspond to the vertex processing data obtained based on the corresponding vertex index in the vertex memory. Therefore, 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 can 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 can 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 can be determined based on the vertex index corresponding to the primitive according to a mapping relationship. 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 the primitives sent by the primitive assembly pipeline 130 to the primitive processing pipeline 140 can include the vertex processing index corresponding to each primitive. Accordingly, the primitive processing pipeline 140 can 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 by the primitive assembly pipeline 130 to the primitive processing pipeline 140 can include the vertex index corresponding to each primitive and the above-mentioned mapping relationship. 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 based on the vertex processing index corresponding to each primitive; or, alternatively, 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 based on primitives, such as one or more of geometry shading, rasterization, and tessellation.

[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 operations of the vertex processing pipeline (such as the vertex hit test therein) can be independent of the primitive assembly results, but can be executed in advance on a vertex basis. This can omit the time for vertex processing operations to wait for primitive assembly, and help further improve the parallelism of vertex processing, thereby helping to improve geometry processing efficiency, and further help improve the processing efficiency of the overall graphics processing system. At the same time, through vertex hit testing, it is also possible to effectively reduce vertex processing operations for vertices that appear repeatedly in the vertex stream, improve vertex processing performance, and reduce system power consumption.

[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 were stored in the cache, and the vertex processing pipeline 120 may process the vertices represented by each vertex index in sequence according to the order in which the vertex indexes were received. In such embodiments, the order in which the vertex indices are sent to the vertex processing pipeline 120 may be consistent with the order in which they were added to the cache, and the vertex processing pipeline 120 does not change the order of the input vertex indices, but instead outputs the resulting vertex processing data to the vertex memory in the order in which they were input. In this case, the order in which the vertex indices are processed by the vertex processing pipeline 120 is consistent with the order in which the vertex processing data corresponding to the vertex indices are stored in the vertex memory, the order in which the vertex indices are sent to the vertex processing pipeline 120, and the order in which the vertex indices are cached 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 facilitates 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 Schematically shows an example block diagram of the vertex cache module 110 according to some embodiments of the present disclosure. 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 for each vertex index in the vertex stream based on the cache, and store 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 were 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. For example, while sending the vertex indexes, the first hit test control module 111 may also send control information to force the start of downstream task assembly and execution of the vertex processing task.

[0058] More specifically, the first hit test control module 111 can 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 clear operation is performed. Optionally, the cache 113 can be a cache device within the vertex cache module 110, or 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, the number of times the vertex processing program is executed can be further reduced, thereby improving vertex processing efficiency. For example, when cache 113 is full, one or more subsequent new vertex indices may still hit cache 113 and do not need to be added repeatedly. In this case, if some or all of the vertices in cache 113 are sent and cleared immediately when cache 113 becomes full, the new vertex indices 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, vertex cache module 110 can receive input vertex stream data and send it to first hit test control module 111. Exemplarily, first hit test control module 111 can sequentially perform a vertex hit test on each vertex index in the input vertex stream. For example, for each vertex index, it can be compared with the vertex index cached in cache 113. If there is a hit, for example, if the vertex index currently cached in 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 cache 113. Exemplarily, if there is a miss and a new vertex index needs to be added to cache 113, it can be determined whether cache 113 is full. If not, the new vertex index can be directly added to cache 113. If it is full, all or at least a portion of the vertex indices in cache 113 must first be sent to task assembly module 112, and the sent vertex indices must be cleared before the new vertex index is added to cache 113.

[0060] In some embodiments, the first hit test control module 111 may be further configured to: in response to completion of 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. For example, the task assembly module 112 may receive and store the vertex indices sent by the first hit test control module 111, and when the number of stored vertex indices reaches a preset number, assemble a task based on the stored vertex indices and send the task to the downstream vertex processing pipeline 120 to initiate 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 (where the vertices can be represented by vertex indices), a vertex processing program, such as a vertex shading program, can be started for these vertices, rather than immediately starting the vertex processing program once 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, where 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 consecutive threads in the execution process of a processing program, such as a shader program, which can execute the same instructions together. The number of threads contained in a wave / warp can vary depending on different GPU architectures. For example, GPU architectures can use execution models such as SIMD (Single Instruction, Multiple Data) and SIMT (Single Instruction, Multiple Threads), where threads within a wave / warp can execute the same instruction but operate on different data. By assembling tasks and launching vertex processing programs for vertices within a task, the parallel execution capabilities of the wave / warp can be maximized, helping to improve program execution efficiency.

[0063] For example, to facilitate further understanding, a vertex processing module (such as a vertex shader) with 8 threads is taken 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 indices 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 indices included in each task can be determined according to the actual number of threads.

[0064] For example, the number of vertex indices 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 indices included in each task, i.e., the aforementioned preset number. In this case, one task may be assembled for each vertex indices sent. Alternatively, the number of vertex indices sent by the first hit test control module 111 to the task assembly module 112 each time may be greater than or less than the preset number. If the number of vertex indices sent is greater than the preset number, the task assembly module 112 may assemble more than one task based on each vertex indices sent. For example, assuming the number of vertices sent each time is 128 and the number of vertex indices included in each task is 32, then each vertex indices sent each time may correspond to four tasks. If the number of vertex indices sent is less than the preset number, the task assembly module 112 may assemble one task based on the vertex indices sent multiple times. For example, assuming the number of vertex indices sent each time is 32 and the number of vertex indices included in each task is 128, then every four vertex indices sent may correspond to one 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. A larger capacity of the cache 113, such as greater than the number of vertex indexes included in each task, such as twice or four times the number of vertex indexes included in each task, allows for searching for duplicate vertex indexes in a wider range, thereby helping to reduce the number of executions of the vertex processing program and improving geometry processing efficiency.

[0065] In some embodiments, the vertex processing index may include the task index corresponding to the vertex index and the ranking index in the corresponding task. The first hit test control module 111 may also be configured to: initialize the current task index before starting to process the vertex stream, such as initializing it to 0 or other preset values; update the current task index each time after sending the vertex index to the task assembly module 112, wherein the sent vertex index is sent in the order in which it is stored in the cache and corresponds to the current task index before the update. The task index can represent the task to which the vertex index or the corresponding vertex belongs, and the ranking index can 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 can 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 contained 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 contained 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 indices sent by the first hit test control module 111 to the task assembly module 112 each time is less than the number of vertex indices contained 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, multiple task indexes can correspond to one task, wherein the multiple task indexes can be regarded as multiple sub-indices 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 will understand that in the above-mentioned various cases, according to the quantitative relationship between the number of vertex indices sent each time and the preset number of vertex indices contained in each task, the conversion of the task index, 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 in the figure, 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 vertex input is tested for a hit, where each vertex is represented by a vertex index. If a hit is found, this means that the vertex index already exists in the cache, meaning that the vertex already exists in the pending / sent task, so there is no need to resend the task for this vertex. At this point, processing can begin on the next input vertex. If a miss is found, this means that the vertex index does not exist in the pending / sent task. (In reality, the vertex represented by the vertex index may have already been processed, but the limited cache capacity prevents the ability to cache more vertex index information simultaneously, resulting in a miss.) Therefore, the missed vertex needs to be processed. Before adding the missed vertex to the cache, the cache must check whether there is sufficient free space to store the vertex index. If the cache does not have sufficient free space, meaning it is full, control information is sent to the downstream task assembly pipeline to assemble tasks based on the previously accumulated vertices and initiate vertex processing tasks for these vertices. For example, the cache contents, i.e., vertex indices in the cache, can be sent to the task assembly pipeline, along with control information instructing the task to be assembled and / or the task processing program to be initiated. Simultaneously, task ID values ​​can be accumulated to prepare data for the next vertex. Since the vertex indices in the cache have already been sent, the cached information for these vertex indices can be safely cleared, and all cache contents can be marked invalid. Subsequently, the vertex indices of the missed vertices can be added to the cache. If the cache has sufficient free space, i.e., the cache is not full, the vertex indices of the missed vertices can be directly added to the cache. Processing can then proceed to the next vertex. If there are no more vertices to be processed, the vertex processing task can be forcibly initiated for the vertex represented by the unfilled vertex indices in the cache, following the same process as for processing a full cache. Specifically, the cache contents, i.e., vertex indices in the cache, can be sent to the task assembly pipeline, along with control information instructing the task to be assembled and / or the task processing program to be initiated. Simultaneously, task ID values ​​can be accumulated, and all cache contents can be marked 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 implement similar functions to 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 considered 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 caching and changes of the vertex indices in the shadow cache 131 can be consistent with those in 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 indices or 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 may 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 indexes in the shadow cache 133, and store the vertex index in the shadow cache 133 after the clear operation. Unlike 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 vertex index clearing operation according to the same logic as the first hit test control module 111 in sending and clearing 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 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 a vertex index is stored in the shadow cache 133, and update the current position index; and update the current task index and reset the current position index each time a vertex index in the shadow cache 133 is cleared. 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 further described here. The current position index in the second hit test control module 131 may be initialized to 0, and the current position index may be updated by accumulating 1 each time a vertex index is stored in the shadow cache 133. Moreover, the current position index may be reset to 0 each time a vertex index in the shadow cache 133 is cleared. This ensures that the ranking index determined for each vertex index correctly reflects its ranking order in the corresponding task, as well as the order in which it is processed and stored. It is understood that when the number of vertex indices sent each time differs from the preset number of vertex indices contained in each task, the ranking index determined by the above logic can also be converted into a ranking index in the subtask or the overall 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, for each vertex input, a hit test is performed, where each vertex is represented by a vertex index. If a hit occurs, this means that the vertex index for that vertex already exists in the shadow cache and does not need to be added to the shadow cache. At this point, processing of the next input vertex can begin. If a miss occurs, this means that the vertex index for that vertex does not exist in the shadow cache, so it needs to be added to the shadow cache. Before adding the vertex index of the missed vertex to the shadow cache, it is necessary to check whether the shadow cache has sufficient free space to store the vertex index. If the shadow cache does not have sufficient free space (i.e., the shadow cache is full), the task ID value is incremented, the internal index value is reset to 0, and the cached vertex index information in the shadow cache is cleared, for example, by marking all contents in the shadow cache as invalid. Subsequently, the vertex index of the missed vertex is added to the shadow cache, and the vertex index, along with the current task ID and current internal index, is entered into the reconstruction mapping table. The current task ID and current internal index can be considered the vertex processing index corresponding to the vertex index. If the cache has sufficient free space (i.e., it is not full), the vertex index of the missed vertex can be directly added to the cache. The vertex index, the current task ID, and the current internal index can be added to the reconstruction mapping table. Next, the next vertex can be processed. If there are no more vertices to process, 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 additionally perform the 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 further includes a primitive assembly module 132. The primitive assembly module 132 may be configured to: receive a primitive splitting initial state, wherein the primitive splitting initial state may indicate a rule for determining primitives based on a vertex stream; for each vertex index in the vertex stream, the primitive corresponding to the vertex index may be determined based on the primitive splitting initial state, and, based on the aforementioned mapping relationship, the vertex processing index corresponding to the vertex index may be determined; and the vertex processing index corresponding to each primitive may be sent to the primitive processing pipeline. The primitive processing pipeline 140 may be configured to: for each received primitive, based on the vertex processing index corresponding to the primitive, obtain 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 primitive's topological type, the starting vertex number, the valid state of the starting vertex, the starting primitive number, the offset of the starting vertex, the winding order of the starting primitive, etc., wherein the primitive's topological type 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 to start assembling the primitive; the winding order of the starting primitive indicates the order in which the vertices of the starting primitive are connected 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 centrally split graphics processing core. After receiving the initial state of primitive splitting, the primitive assembly module 132 can split the input vertex stream into primitives. 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 after all vertex processing data corresponding to a primitive have been obtained from the vertex memory, perform primitive processing for the primitive based on the obtained vertex processing data. 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, which 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 in the vertex stream from which the primitive is to be assembled. In such embodiments, when determining the primitive corresponding to the vertex index based on 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 based on the initial state of primitive splitting, 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, the vertex index and the vertex indices 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 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 primitive splitting initial state, it can begin assembling primitives based on the vertex stream. Specifically, a vertex index from the vertex stream can be input, and then, based on the primitive splitting initial state, it can be determined whether this vertex index is a vertex index that needs to be skipped. If so, this vertex index is skipped and the next vertex index is processed. If not, primitive assembly can begin. At this point, the assembled primitives are derived from the vertex indices in the input vertex stream data. When assembling primitives, the reconstruction mapping table 134 can be searched based on the vertex index to find the vertex processing index corresponding to the vertex index, such as the task index and the position index. Then, the vertex processing data for the corresponding vertex, such as the vertex shading result data, can be located in the vertex memory. Once the vertex processing data for all vertices constituting the primitive has been retrieved from 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 tessellation 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 can also be configured to: in response to the existence 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 can also be configured to: in response to the existence of one or more clipping points in the vertex stream, skip the one or more clipping points. Exemplarily, the clipping point can 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, if Figure 8As shown, the geometry processing pipeline 800 can receive vertex stream data transmitted by external modules. On the one hand, the vertex stream data is transmitted to the vertex cache module 810 and the subsequent vertex processing pipeline 820. After the vertex processing tasks such as vertex shading tasks are initiated, the vertex processing results (i.e., vertex processing data) are 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, it can begin primitive assembly and transmit primitive assembly information (such as assembled primitives or other related information) to the primitive processing pipeline 840. Based on the primitive assembly information transmitted by the primitive assembly pipeline, the primitive processing pipeline 840 can access the vertex memory 850, obtain the corresponding vertex processing data, and perform further primitive processing, such as one or more of rasterization, geometry shading, and tessellation. Furthermore, 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, and will not be further elaborated herein.

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

[0083] like Figure 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. For example, it is assumed 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 Figure 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 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, and 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, and vertex J is mapped to 1-1, which corresponds to the 1st vertex of Task 1, and so on. In some embodiments, Figure 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, Figure 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 a similar Figure 9A The mapping table shown.

[0084] Depend on Figure 9A As can be seen, the original input vertex stream provides a total of 21 vertex indices. However, after passing through the vertex cache module, only two tasks were run, processing a total of 8 + 6 = 14 vertices. 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, because the last A, B, and C vertices in the vertex stream are separated from the previous A, B, and C vertices by a large number of other vertex indices, the last A, B, and C vertices need to be processed again in Task 1.

[0085] Task 1 and Task 2 can be sent to the vertex processing pipeline. After processing, the resulting vertex processing data can be output and stored in the vertex processor. After receiving the primitive splitting initial state, the primitive assembly pipeline can 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: Figure 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 look up 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. This 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 (ie, skip the first vertex A), then the primitive assembly result can be as follows: Figure 9C As shown in Figure 2. In this example, the primitives assembled are triangles BCD, BCA, EFC, GBC, HCI, and JKA. Similarly, the primitive assembly pipeline can still use the reconstruction mapping table to look up the vertex processing index of each vertex, such as the task index and the position index, to locate the processing result of the corresponding vertex in the vertex memory for further primitive processing.

[0088] Figure 10A Schematically shows an example block diagram of a graphics processor 1000 according to some embodiments of the present disclosure. Figure 10A As shown, 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 geometry processing system 100 described according to various embodiments.

[0089] In some embodiments, the graphics processor 1000 may have Figure 10B The structure shown. Figure 10BAs shown, 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. Each graphics processing core may include a geometry processing pipeline. For example, geometry processing pipelines 1010-1 to 1010-N shown in the figure may be included in corresponding graphics processing cores 1100-1 to 1100-N, respectively. As shown in the figure, all graphics processing cores may be homogeneous. Therefore, the performance of graphics processor 1000 can be adjusted by simply increasing or decreasing the number of graphics processing cores to meet the throughput, performance, and power consumption requirements of graphics processor 1000 in different application scenarios, reducing the complexity of design and verification. 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. For example, the system configuration module 1200 can be used to configure the state of the entire graphics processing system, such as the total number of enabled graphics processing cores, the number of vertices in a primitive packet (the number of vertices in each vertex stream after the original vertex stream drawn by the drawing instructions is split), the central graphics processing core number, and the mapping sequence number of each graphics processing core. 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 graphics processing core 1100-1 through 1100-N primarily includes a vertex splitting module, a geometry processing pipeline, a pixel processing pipeline, and a memory access arbiter. The structure and function of the geometry processing pipeline have been described in various embodiments above and will not be elaborated upon here. The vertex splitting module can obtain the portion of the total vertex stream that should be processed by that core based on instructions from the application and system configuration. The pixel processing pipeline processes the results of the geometry processing pipeline to generate visual graphics. It is primarily used to perform pixel-level processing, such as the various processes in the pixel processing portion of the rendering pipeline described above. The memory access arbiter can manage access to the memory 1400 shared by multiple graphics processing cores via bus 1200. For example, it can store processing results from the geometry processing pipeline into memory 1400, retrieve results from the geometry processing pipeline from memory 1400 for use by the pixel processing pipeline, and store processing results from the pixel processing pipeline into memory 1400.

[0091] Furthermore, 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 here.

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

[0093] In some embodiments, the computing device 1100 may have Figure 11B The structure shown. Figure 11B As shown, computing device 1100 may include a processing system 1101, a storage system 1102, an I / O interface 1103, and an application 1104. Processing system 1101 may represent functionality that performs one or more operations through hardware, and may include a graphics processor 1000 and other processors, processing elements, or processing circuits, such as a central processing unit (CPU). 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 disks, magnetic disks, etc.). Furthermore, the storage system may include various fixed media (e.g., RAM, ROM, fixed hard drives, etc.) and removable media (e.g., flash memory, removable hard drives, optical disks, etc.). One or more I / O interfaces 1103 may represent components or devices that allow a user to interact with computing device 1100. Examples of input interfaces may include a keyboard, mouse, microphone, scanner, touch input device, camera, receiver, etc. Examples of output interfaces may include a display, projector, speaker, printer, transmitter, etc. The application 1104 may be stored as computer program instructions in 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 have been 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 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 the appropriate 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 on 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; perform a hit test based on a cache for each vertex index, and store only missed vertex indices into the cache; and send the vertex indices in the cache to the 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: perform primitive processing on each received primitive 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 assembling module is configured to assemble tasks based on vertex indices received from the first hit test control module, wherein each task includes a preset number of vertex indices 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. The first hit test control module is further configured to: Before starting to process the vertex stream, initializing the current task index; Each time a vertex index is sent 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 graphic element assembly line includes: 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 only 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 on each vertex index in the vertex stream based on the shadow cache and storing only missed vertex indexes in the shadow cache comprises: performing the following processing on each vertex index in the vertex stream: In response to the vertex index not hitting the shadow cache and the shadow cache being 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 according to claim 7, wherein: The vertex processing index includes the task index corresponding to the vertex index and the position index in the corresponding task. The second hit test control module is further configured to: Before starting to process the vertex stream, initialize the current task index and the current position index; Each time after storing a vertex index into the shadow cache, determining a task index and a 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 the vertex index in the shadow cache is cleared, the current task index is updated and the current position index is reset.

9. The geometry processing system according to claim 1, wherein: The graphic element assembly line includes: The primitive assembly module is configured to: receive a primitive splitting initial state, wherein the primitive splitting initial state indicates a rule for determining primitives 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 a 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, obtain vertex processing data corresponding to the primitive from the vertex memory based on a vertex processing index corresponding to the primitive, and perform primitive processing.

10. The geometry processing system according to claim 9, wherein: The primitive splitting initial state includes starting vertex information, and the starting vertex information indicates a starting vertex for assembling a primitive in the vertex stream. The step of 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 according to 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