Data processing methods, graphics processors, and electronic devices

Abstract

This application provides a data processing method, a graphics processor, and an electronic device; the graphics processor includes a geometry processing pipeline, which includes a task building unit and a task execution unit. The task building unit is used to allocate at least two shader tasks; in response to receiving a task building request, it determines a first shader task from the at least two shader tasks, the first shader task being used to build a shader instance in the task building request; the task execution unit is used to execute the first shader task after it has been built.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of computer technology, and in particular to a data processing method, a graphics processor, and an electronic device. Background Technology

[0002] In related technologies, the Graphics Processing Unit (GPU) primarily undertakes complex geometric calculations and rendering tasks. During rendering, the GPU typically employs a pipelined architecture to organize task execution, such as geometry processing pipelines and pixel processing pipelines. In the geometry processing pipeline, upon receiving a task assembly request, the necessary resources are first allocated to the shader instances in the request. After resource allocation is complete, multiple shader instances are packed into a single shader task. This processing mechanism not only reduces the efficiency of upstream shader instance sending and lowers throughput but also slows down the assembly speed of shader tasks, thus limiting GPU performance. Summary of the Invention

[0003] This application provides a data processing method, a graphics processor, and an electronic device.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a graphics processor (GPU) including a geometry processing pipeline. The geometry processing pipeline includes a task building unit and a task execution unit, wherein: A task building unit is used to allocate at least two shader tasks; in response to receiving a task building request, a first shader task is determined from the at least two shader tasks, and the first shader task is used to build the shader instance in the task building request. The task execution unit is used to execute the first shader task that has been assembled.

[0005] This application provides a data processing method applied in a graphics processor, the graphics processor including a geometry processing pipeline, the data processing method including: Assign at least two shader tasks; In response to receiving a task assembly request, a first shader task is determined from at least two shader tasks. The first shader task is used to assemble the shader instance in the task assembly request. Execute the first shader task after it has been assembled.

[0006] This application provides an electronic device including the aforementioned graphics processor.

[0007] The embodiments of this application have the following beneficial effects: First, the task building unit pre-allocates multiple shader tasks, avoiding resource allocation upon receiving shader instances and thus reducing waiting time. Second, upon receiving a task assembly request, the task building unit directly selects suitable shader tasks for assembly without needing to allocate resources again upon receiving shader instances. This effectively decouples the resource allocation from shader instance reception, allowing upstream shader instance senders to continue sending without waiting for resource allocation to complete, fully utilizing upstream bandwidth and improving efficiency. It also reduces blocking during task assembly, significantly shortening the assembly time and thus dramatically improving the speed of shader task assembly. Finally, the task execution unit begins execution immediately upon receiving a complete shader task. Compared to the serial processing methods in related technologies, this solution, by parallelizing shader task resource allocation and shader instance reception, efficiently completes task assembly and execution, significantly improving the overall performance and throughput of the image processor. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the first component structure of a graphics processor provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the implementation flow of a data processing method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the second component structure of a graphics processor provided in an embodiment of this application; Figure 4 This is a schematic diagram of the composition structure of a task construction unit provided in an embodiment of this application; Figure 5 This is a schematic diagram of the workflow of a task assembly unit provided in an embodiment of this application; Figure 6 This is a schematic diagram of the workflow of an idle task maintenance unit provided in an embodiment of this application.

[0009] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

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

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

[0012] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0014] The technical solutions in the embodiments of this application will now be clearly and completely described with reference to the accompanying drawings.

[0015] Figure 1 This is a schematic diagram of the first component structure of a graphics processor provided in an embodiment of this application, as shown below. Figure 1 As shown, the graphics processor 100 includes a geometry processing pipeline 10, which includes a task building unit 11 and a task execution unit 12, wherein: The task building unit 11 is used to allocate at least two shader tasks; in response to receiving a task building request, it determines a first shader task from the at least two shader tasks, the first shader task being used to build the shader instance in the task building request. Task execution unit 12 is used to execute the first shader task that has been assembled.

[0016] Here, the graphics processor includes at least a geometry processing pipeline (or geometry processing stage). The geometry processing pipeline is mainly used to process the geometric data of the graphics, with the goal of converting vertices, primitives, etc., into two-dimensional graphics in screen space, in preparation for subsequent rasterization or primitive rendering.

[0017] The task building unit can be any suitable hardware or hardware / software combination unit capable of implementing this function; it is at least a core component in the GPU used to manage shader tasks. In the geometry pipeline, the task building unit is at least responsible for receiving task building requests from upstream and selecting specific shader tasks based on these requests.

[0018] A shader task is a task consisting of multiple shader instances, which can be sent by at least one shader. In a geometry processing pipeline, this shader can include, but is not limited to, vertex shaders (VS), shell shaders (HS), domain shaders (DS), geometry shaders (GS), amplifier shaders (AS), and mesh shaders (MS). Each shader task requires certain resources (such as identifiers, input resources, output resources, and local storage) to complete its execution. The identifier is used to identify the shader task; it's understood that the identifier of the shader task will not change until it is destroyed. Input resources are mainly used to store resources related to input data or information. Output resources are mainly used to store output results or computation results. Local storage resources mainly refer to resources for storing temporary information (such as data to be read or written).

[0019] In some implementations, the task building unit can pre-allocate at least two shader tasks. It is understood that these shader tasks are in a first state (i.e., the shader task's state is the first state). The first state can refer to an idle or unused state, meaning these shader tasks have not yet been populated with shader instances and have not been used to perform any operations; they are in a standby state. In other words, the first state can refer to a shader task being in a state where it has not yet been executed but has the conditions for execution. In some implementations, the shader task in the first state has at least been assigned an identifier, but other resources required by the shader task (e.g., input resources, output resources, local storage resources, etc.) may be unallocated, partially allocated, or fully allocated. For example, before initialization or rendering, the shader task in the first state may have all the required resources allocated. By pre-allocating these resources, it is ensured that when the actual shader instance arrives, the actual shader instance can be directly packaged into the shader task in the first state without waiting for the resource allocation process, thereby significantly improving the task building efficiency. For example, during the rendering process, a shader task in the first state may have allocated some of the required resources (e.g., only the identifier, identifier, and input resources) or it may have allocated all the required resources.

[0020] In some implementations, the task building unit can pre-allocate a specified number of shader tasks. This specified number can be fixed or allocated based on received configuration information, such as using a second number included in the configuration information as the specified number. In practice, upon receiving the configuration information, the task building unit can immediately allocate the specified number of shader tasks in the first state.

[0021] In some implementations, the task building unit can also allocate shader tasks based on all available resource information. For example, all available resources can be allocated as shader tasks, or a large portion (e.g., 75%, 80%, etc.) of all available resources can be allocated as shader tasks, which effectively reduces the allocation time and fragmentation problem of related resources.

[0022] In some implementations, at least two shader tasks can be pre-allocated during initialization or shader mode switching. Shader modes can include, but are not limited to, single-engine mode, dual-engine mode, and multi-engine mode. Single-engine mode includes only one shader engine, dual-engine mode includes two shader engines, and multi-engine mode includes multiple shader engines. It is understood that the GPU can include at least one shader engine, which is the core computational unit in the geometry processing pipeline used to handle different types of shader tasks; it can be implemented in hardware. In implementation, different shader engines can be instantiated from the same hardware to save hardware development costs, or they can be instantiated from different hardware to improve GPU performance and compatibility.

[0023] In some implementations, when a shader mode switch occurs, the previously allocated shader tasks can be destroyed first, and then new shader tasks can be reassigned. Alternatively, modifications can be made to the original shader tasks. For example, when switching from a single-engine mode to a dual-engine mode, if the target shader in the single-engine mode is different from the target shader in the dual-engine mode, the previously allocated shader tasks can be destroyed first, and then new shader tasks can be reassigned. If the target shader in the single-engine mode is the same as the target shader in the dual-engine mode, the original shader tasks can be modified to achieve task reuse and reduce the time required for resource allocation. Alternatively, the previously allocated shader tasks can be destroyed first, and then new shader tasks can be reassigned to ensure the accurate execution of subsequent tasks.

[0024] A task assembly request is a signal from upstream indicating that a new shader instance needs to be assembled. In some implementations, this task assembly request may be triggered by a user-issued drawing command. The task assembly request may include at least one shader instance. In practice, different shaders may distribute shader instances in the same or different ways. For example, for VS and DS, one shader instance may be sent per vertex, i.e., one task assembly request per vertex. For HS, one shader instance may be sent per patch (i.e., control point set), i.e., one task assembly request per patch. For AS and MS, one shader instance may be sent per thread, i.e., one task assembly request per thread. In some implementations, the task assembly request may also include resource information required by the target shader corresponding to the shader instance. This resource information may include, but is not limited to, input resources, output resources, and local storage resources. In practice, the resource information required by the target shader can be used to select a shader task. In some implementations, a single shader task can assemble instances of different shaders, and different shader tasks can assemble instances of the same or different shaders. For example, all shader tasks are used to assemble instances of VS. Or, for another example, when the shader mode switches, some shader tasks are used to assemble instances of AS+MS, and some shader tasks are used to assemble instances of MS.

[0025] The first shader task is a shader task that is capable of assembling the shader instance in the task assembly request. The first shader task can be determined in any suitable way.

[0026] In some implementations, a first shader task can be determined based on the state of at least one shader task. The state of this shader task may include, but is not limited to, a first state, a second state, a third state, etc. The second state refers to an assembly state or a usage state, meaning the shader task has been partially populated with shader instances. The third state may refer to an execution state, meaning the shader task has been populated with enough instances and cannot assemble any more shader instances. In implementation, when all allocated shaders are all in the first state, all in the third state, or partially in the first state and the remainder in the third state, it indicates that all shader tasks are not in the second state. It is understood that only shader tasks in the first or second state can assemble shader instances. The first shader task can be a shader task in the first state, a shader task in the second state, or a shader task in the third state.

[0027] In some implementations, the first shader task can be determined based on the allocation information of at least one shader task. The configuration information of the shader task includes the allocation result of at least one resource required by the shader task, where the resource allocation result indicates whether the resource has been allocated. For example, a shader task in which all resources have been allocated may be preferentially selected as the first shader task.

[0028] Understandably, in the process of selecting the first shader task, it is necessary to ensure that the first shader task can construct the shader instance in the task construction request in order to improve the efficiency of shader task selection.

[0029] In some implementations, the task building unit may include, but is not limited to, a task assembly unit and a task management unit. These internal units manage and optimize the allocation and assembly of shader tasks. The task management unit can be any suitable hardware or hardware / software combination unit capable of implementing this function. It is responsible for managing and scheduling shader tasks in the GPU, improving GPU resource utilization while reducing shader task waiting time. The task assembly unit can be any suitable hardware or hardware / software combination unit capable of implementing this function; it primarily assembles shader instances. In implementation, the task management unit is used to allocate at least two shader tasks, and the task assembly unit is used to determine a first shader task from at least two shader tasks in response to receiving a task assembly request.

[0030] After selecting a specific first shader task, the shader instance from the task assembly request needs to be assembled into the first shader task. It is understood that the assembly of the shader instance can be performed by the task assembly unit or by other units in the geometry processor pipeline. These other units are at least used to assemble the shader instance from the task assembly request into the first shader task.

[0031] In some implementations, after determining the first shader task, the task building unit builds the shader instance from the task building request into the first shader task. For example, the task management unit is also configured to build the shader instance from the task building request into the first shader task.

[0032] In some implementations, after determining the first shader task, the task building unit synchronizes the first shader task to other units so that the other units can build the shader instance in the task building request into the first shader task.

[0033] A task execution unit is a hardware module in a GPU responsible for executing shader tasks. This unit may include at least one shader core, depending on the GPU's architecture. It receives shader tasks assembled by a task building unit (or other units) and executes them in a predetermined order. For example, the task execution unit can execute the first assembled shader task and other assembled shader tasks mentioned later. In implementation, after assembling the first shader task, the task building unit (or other units) can pass the first shader task to the task execution unit through any suitable method, such as direct transmission, indirect transmission, broadcasting, or shared memory.

[0034] During implementation, after receiving the completed shader task, the task execution unit starts the corresponding computing resources and processes each shader instance in the completed shader task in parallel. For example, the task execution unit processes the data of each vertex in the completed shader task one by one. Alternatively, the task execution unit may generate new geometric data based on the completed shader task. After the completed shader task is executed, the task execution unit transmits the processing results to subsequent target pipelines (such as rasterization pipelines, pixel processing pipelines) or subsequent stages. These subsequent stages may include, but are not limited to, the rasterization stage and the pixel processing stage (or pixel processing pipeline). The rasterization stage (i.e., the rasterization pipeline) is a core link in the GPU rendering pipeline, mainly converting geometrically processed primitives into pixels (or fragments) for subsequent pixel processing pipeline shading. It is the bridge between geometric data and screen pixels. The pixel processing pipeline is responsible for coloring 2D graphics into the final pixel image.

[0035] In this embodiment, firstly, the task building unit pre-allocates multiple shader tasks to avoid resource allocation upon receiving shader instances, thereby reducing waiting time. Secondly, upon receiving a task assembly request, the task building unit directly selects a suitable shader task for assembly without needing to allocate resources again upon receiving shader instances. This effectively decouples the resource allocation from shader instance reception, allowing upstream shader instance senders to continue sending without waiting for resource allocation to complete, fully utilizing upstream bandwidth and improving efficiency. It also reduces blocking during task assembly, significantly shortening the assembly time and thus significantly improving the assembly speed of shader tasks. Finally, the task execution unit begins execution immediately upon receiving a complete shader task. Compared to the serial processing method in related technologies, this solution, by parallelizing shader task resource allocation and shader instance reception, efficiently completes task assembly and execution, significantly improving the overall performance and throughput of the image processor.

[0036] In some implementations, the task building unit 11 (or task management unit) is also used to allocate at least two shader tasks based on all resource information.

[0037] Here, "all resource information" refers to the set of information on all available resources related to a shader task within the geometry processing pipeline. These resources may include, but are not limited to, task identifiers, input resources, output resources, and local storage resources. In implementation, by pre-allocating these resources and storing them as idle tasks (i.e., shader tasks in their first state), when a shader instance is received, it can be quickly packaged into a prepared idle task, significantly improving task assembly speed. In some implementations, at least two shader tasks can be allocated based on all available resource information during initialization or shader mode switching.

[0038] In some implementations, all available resources can be allocated to multiple shader tasks. This completely decouples the resource allocation process for shader tasks from the process of receiving shader instances, reducing performance bottlenecks caused by resource allocation delays in related technologies' serial processing or subsequent dynamic allocation. Furthermore, it reduces fragmentation issues, thereby improving overall resource utilization and throughput. In some implementations, all available resources can be allocated to multiple shader tasks according to received configuration information. This configuration information may include, but is not limited to, the status of each shader and the resource requirements of the target shader. The shader's status indicates whether the shader is enabled, i.e., whether it is designated as the target shader. The target shader's resource requirements may include, but are not limited to, input resources, output resources, and local storage resources. In some implementations, the configuration information also includes a second quantity, indicating the number of configured idle tasks.

[0039] In some implementations, a large portion (e.g., 80%, 90%) of all available resources can be allocated to multiple shader tasks. In some implementations, multiple shader tasks are allocated based on the complexity of the drawing task. For example, complexity is positively correlated with the allocation ratio; that is, the higher the complexity of the drawing task, the higher the allocation ratio. In some implementations, multiple shader tasks are allocated based on all available resource information and the resource requirements of the target shader. In practice, since the sizes of available resources vary, the available resources can first be divided according to the resource requirements of the target shader to obtain the number of partitions for each available resource. Then, the final number of shader tasks allocated is determined based on the number of partitions for each available resource. For example, if there are 5 types of available resources, and each type can be partitioned into 5, 8, 6, and 9 partitions respectively, then the smallest number can be determined as the final number of shader tasks allocated, or the largest number can be determined as the final number of shader tasks allocated, or the number corresponding to the task identifier can be used as the final number of shader tasks allocated.

[0040] In practice, when an idle task is needed, one of the at least two idle tasks can be selected directly for use without waiting for the resource allocation process, thus enabling the rapid assembly of shader tasks.

[0041] In the embodiments of this application, by analyzing global resource information and rationally allocating shader tasks, the limited hardware resources can be utilized to the maximum extent, while also reducing fragmentation problems and greatly improving task execution efficiency, throughput and resource utilization.

[0042] In some implementations, the task construction unit 11 (or task management unit) is further configured to receive configuration information, which includes a second number of shader tasks and resource requirement information of the target shader; and to allocate the second number of shader tasks based on the available resource information and the resource requirement information of the target shader.

[0043] Here, the configuration information can be received during initialization or when the shader mode is switched; this application does not limit the timing of receiving the configuration information. This configuration information can be configured statically or dynamically adjusted at runtime. It is understood that the purpose of this task management unit is to improve GPU resource utilization and reduce shader task waiting time, thereby improving overall rendering performance.

[0044] This configuration information can be a set of parameters provided by the driver or other control unit to guide the task building unit (or task management unit) on how to allocate shader tasks. This configuration information may include, but is not limited to, a second number of shader tasks, resource requirements of the target shader, and the status of each shader. The second number is the total number of shader tasks to be allocated. Resource requirements may include, but are not limited to, the input resource size required by the target shader, the output resource size required by the target shader, and the local storage resource size required by the target shader. The shader status indicates whether the shader is enabled; it is understood that when a shader is enabled, that shader is designated as the target shader.

[0045] Available resource information is crucial for determining whether shader task allocation can be completed. This available resource information may include, but is not limited to, the number of identifiers, the remaining amount of input resources, the remaining amount of output resources, and the remaining amount of local storage resources. In implementation, this available resource information can be used to determine whether there are sufficient resources available for allocation. By checking this available resource information, it is decided whether to allocate a new shader task immediately or whether to wait for some resources to be released before allocation. In some implementations, allocated idle tasks may only be allocated a portion of their resources, with the remaining resources being allocated after some shader tasks release their corresponding resources. It is understood that allocated idle tasks must at least have an identifier.

[0046] For example, the configuration information indicates that 5 idle tasks need to be allocated, and each idle task requires a specific resource quota. By querying the available resource information, it can be confirmed whether there is enough space to meet the resource requirements of these 5 idle tasks. If resources are sufficient, the 5 idle tasks are allocated immediately; if resources are insufficient, some idle tasks can be fully allocated first, and the remaining idle tasks can be partially allocated.

[0047] In this embodiment, by introducing a configuration information and resource requirement matching mechanism, the task allocation strategy can be flexibly adjusted to achieve more efficient shader task allocation, reduce the resource waste and inefficiency caused by serial allocation, and thus better adapt to different workloads and application scenarios, improving adaptability and scalability.

[0048] In some implementations, the task building unit 11 includes a task building unit, a configuration unit, and a task management unit; the task building unit is used to send configuration information to the configuration unit; the configuration unit is used to send configuration information to the task management unit so that the task management unit allocates a second number of shader tasks.

[0049] Here, the configuration unit is a submodule within the task building unit, responsible for processing configuration information related to the shader task. This configuration unit can be hardware or a combination of hardware and software. Its role is to plan and allocate the necessary resources in advance based on the configuration information before actually receiving the shader instance, thereby reducing waiting time during the task building process.

[0050] There is a data transfer relationship between the configuration unit and the task assembly unit. After receiving the configuration information sent from upstream, the task assembly unit forwards the configuration information to the configuration unit for further processing. This separate design helps decouple the task allocation logic from the instance assembly logic, improving overall processing efficiency.

[0051] For example, when the GPU starts up or the shader mode switches, the task assembly unit receives a series of new configuration information. At this time, the task assembly unit sends a series of new configuration information to the configuration unit. After parsing or preliminarily processing the series of new configuration information, the configuration unit sends the relevant information to the task management unit.

[0052] The task management unit determines how to allocate shader tasks based on configuration information and current available resources, ensuring the rationality and efficiency of resource allocation. The specific allocation process can be found in the aforementioned embodiments. The communication mechanism between the configuration unit and the task management unit can employ various implementation methods, such as shared memory, message queues, or dedicated channels for data transmission. Regardless of the method used, it is essential to ensure that configuration information is transmitted quickly and accurately so that the task management unit can make timely scheduling decisions.

[0053] In this embodiment, a configuration unit is introduced as an intermediate bridge to transmit configuration information to the task management unit, thereby enabling the task management unit to accurately control and dynamically adjust task resources, enhancing overall coordination and consistency. Simultaneously, by moving the configuration information processing flow forward to before receiving shader instances, latency during task assembly can be significantly reduced.

[0054] In some implementations, the task building unit (or task management unit) is used to determine a first shader task based on the state of at least one shader task.

[0055] Here, when the task building unit (or task management unit) receives a task building request, it will first obtain the status of each assigned shader task and then perform subsequent processing based on the status of each assigned shader task.

[0056] In some implementations, a task list can be pre-established, which mainly maintains the assigned shader tasks. During implementation, the status of each assigned shader task can be quickly determined based on this task list.

[0057] In some implementations, a multi-bit identifier can be pre-established to indicate the status of each assigned shader task. For example, each shader task can be assigned a one-bit identifier, which can then be used to determine the status of that shader task.

[0058] The first shader task can be a shader task in the first state, a shader task in the third state, or a shader task in the second state.

[0059] The first shader task can be determined in any suitable way. In implementation, the state of each shader task is obtained to indicate whether each shader task is in the second state.

[0060] In some implementations, when all shader tasks are not in the second state, a new shader task (i.e., a first shader task) needs to be determined to assemble the shader instance in the task assembly request. It is understood that this new shader task is used to assemble the new shader instance; in this case, the new shader task can be a shader task in the first state or a shader task in the third state. In some implementations, when there are at least one shader task in the first state, the task assembly unit can determine the first shader task from among at least one shader task in the first state. In some implementations, when all shader tasks are in the third state, the task assembly unit can determine the first shader task from among all shader tasks in the third state. For example, when all shader tasks are in the third state, the task assembly unit can determine the first shader task based on waiting time, randomness, usage order, etc. For example, the shader task with the shortest waiting time can be selected as the first shader task. Or, the shader task assigned first can be selected as the first shader task.

[0061] In some implementations, when at least one shader task is in a second state, a first shader task is determined from the at least one shader task in the second state.

[0062] During implementation, after selecting the first shader task, if the first shader task was originally in the first or third state, its state needs to be switched to the second state. Subsequently, the selected first shader task will be used to receive shader instances and gradually fill the entire structure.

[0063] In this embodiment, appropriate shader tasks are selected for instance assembly based on the state of each shader task, thereby improving the efficiency and accuracy of task selection.

[0064] In some implementations, the task construction unit 11 (or task assembly unit) is used to determine the first shader task from at least one second shader task when the state of each shader task is not the second state and at least one second shader task in the first state exists among at least two shader tasks.

[0065] Here, the second shader task refers to a shader task that is currently in the first state.

[0066] The first shader task can be determined in any suitable way.

[0067] In some implementations, the first shader task can be determined based on the allocation information of each second shader task, randomness, or sequence. For example, a second shader task with all resources fully allocated can be selected as the first shader task. Another example is selecting the second shader task that was allocated first, to ensure task order and efficiency. Yet another example is randomly selecting a second shader task as the first shader task.

[0068] In this embodiment, when there is no shader task in the second state and there is a shader task in the first state, a shader task in the first state is directly selected to form an instance, thereby improving the efficiency of task selection.

[0069] In some implementations, the task construction unit 11 (or task assembly unit) is used to determine the first shader task based on the allocation information of each second shader task. The allocation information of the second shader task includes the allocation result of at least one resource required by the second shader task, and the resource allocation result indicates whether the resource has been allocated.

[0070] Here, the second shader task may have already been allocated some or all of its resources. Understandably, a second shader task allocated some resources still has the ability to assemble shader instances.

[0071] Allocation information records the allocation status of resources required by the second shader task. Resources required by a shader task may include, but are not limited to, identifiers, input resources, output resources, and local storage resources. It is understandable that the required resources are the fundamental conditions necessary to construct a complete shader task. For example, if a specific second shader task has allocated input resources but not output resources, then the allocation information for that second shader task will reflect the state that input resources have been allocated but output resources have not.

[0072] The resource allocation result describes whether a specific resource has been successfully allocated. In some implementations, this can be represented by bit flags, markers, or other forms. For example, 1 indicates allocation, and 0 indicates unallocated. The resource allocation result directly determines whether the second shader task can meet the requirements of task composition.

[0073] In implementation, there is a clear logical relationship between the second shader task and the first shader task: the second shader task is a candidate task, and the first shader task is selected from these candidate tasks based on allocation information. It is understandable that when only one second shader task exists, that second shader task can be used as the first shader task. When at least two second shader tasks exist, the first shader task can be determined based on the allocation information of each second shader task.

[0074] In some implementations, when there are at least two second shader tasks, the allocation information of each second shader task can be obtained first. If the allocation information of at least one second shader task indicates that all resources have been allocated, the first shader task can be selected from these at least one second shader task in a random, sequential, or other manner. If the allocation information of all second shader tasks indicates that only some resources have been allocated, the first shader task can be selected based on the allocation result of a specific resource, the number of allocated resources, or other methods. For example, the second shader task with the largest number of allocated resources can be selected as the first shader task. In practice, by introducing a mechanism for judging the resource allocation status of second shader tasks, the optimal and most suitable task can be selected from multiple shader tasks for subsequent assembly, improving the level of intelligence, reducing the number of resource reallocations, effectively ensuring the stability and efficiency of task execution, and also reducing some problems caused by blindly selecting the first available task.

[0075] In the embodiments of this application, when there are multiple shader tasks in the first state, the task assembly unit can further filter out the most suitable shader task according to its resource allocation, thereby reducing the problem of subsequent processing delays caused by the unallocated resources, and thus improving the continuity, stability and efficiency of task execution.

[0076] In some implementations, the task construction unit 11 (or task assembly unit) is used to determine a first shader task based on at least one shader task in the second state when at least one shader task is in the second state.

[0077] Here, the second state refers to a shader task that has not yet been fully assembled or is in an intermediate state of use. For example, when a shader task has been partially filled with shader instances but has not yet reached the preset number (such as 16 or 32), the shader task is in the second state. Shader tasks in this state can still continue to receive new shader instances.

[0078] The first shader task is a shader task in the second state, used to receive shader instances from the task assembly request. Specifically, when there is a shader task in the second state, that shader task is designated as the first shader task. When there are at least two shader tasks in the second state, one can be selected as the first shader task based on a priority strategy (such as creation time, resource usage, remaining capacity, and the number of instances that can still be packed). This not only improves resource utilization and task processing efficiency but also effectively reduces latency when the GPU processes shader tasks, thereby improving the real-time performance and smoothness of graphics rendering.

[0079] Understandably, by intelligently selecting and utilizing shader tasks in the second state, effective integration of shader instances is achieved, and the management mechanism of shader tasks is optimized.

[0080] In actual implementation, the specific processing flow when a new shader instance is received is as follows: First, obtain the status of all available shader tasks; If all other states are not the second state, then select one of the shader tasks from the other states as the first shader task. If there is at least one shader task in the second state, the best one is selected from the shader tasks in the second state as the first shader task so that the best one can be used for the integrated use of shader instances.

[0081] Understandably, once the first shader task has assembled enough shader instances, the task execution unit can send the first shader task to the task execution unit for execution.

[0082] In this embodiment, when there is a shader task in the second state, the shader task is directly used to continue assembling new instances, reducing unnecessary task creation and resource allocation, thereby reducing overhead and improving overall performance.

[0083] In some embodiments, the task construction unit 11 (or task management unit) is further configured to: switch the state of the first shader task to a second state and send the first shader task to the task execution unit; after sending the first shader task to the task execution unit, switch the state of the first shader task to a third state; or, if it is determined that the first shader task has been completed, switch the state of the first shader task to a first state.

[0084] Here, after determining the first shader task, it is necessary to use the first shader task to assemble the shader instance in the task assembly request. Therefore, it is necessary to switch the first shader task from other states to the second state, that is, the second state indicates that the first shader task has not yet been assembled.

[0085] The third state refers to the state in which the task is being executed, also known as the execution state. After the first shader task assembles enough shader instances, it can be sent to the task execution unit for execution. Therefore, the first shader task needs to be switched from the second state to the third state. For example, when the first shader task is successfully submitted to the execution unit and begins processing vertices, textures, or other graphics data, it enters the execution state. In practical applications, the definition of the execution state may vary slightly depending on the hardware architecture, but the core meaning of the execution state is that the first shader task has started execution but has not yet completed. In implementation, after the first shader task is sent, it needs to switch to the new third state immediately to promptly identify whether the first shader task can still assemble new shader instances. This improves the transparency of the task processing process and the controllability of task execution, thereby facilitating subsequent resource management and scheduling optimization.

[0086] "Execution complete" can mean that the execution result of the shader task has been confirmed and the output data has been written to the specified storage location. The determination of execution completion can be made in any suitable way. In some implementations, the execution status of the shader task can be read from the task execution unit. In some implementations, after the task execution unit completes the shader task, feedback can be provided through any suitable method such as broadcasting, direct transmission, or shared memory. For example, after the task execution unit completes the shader task, it can send the shader task's identifier back to the task construction unit (or task management unit) so that the task construction unit (or task management unit) can determine that the shader task has been completed.

[0087] During implementation, the state of the first shader task is reset to the first state, indicating that the first shader task can be reused or its resources released. This mechanism supports the cyclical use of the first shader task, reducing the time overhead required for each task creation.

[0088] In this way, by introducing a task state switching mechanism and setting different state flags before and after task sending and after execution, the efficiency and accuracy of task scheduling can be effectively improved.

[0089] In actual implementation, the entire task state switching process is as follows: First, the first shader task is in the first state, indicating that the first shader task has not yet assembled a shader instance; then, the first shader task is selected and switched to the second state before being sent to the task execution unit, indicating that the first shader task can assemble a shader instance; once the first shader task is sent, the state of the first shader task immediately switches to the third state, indicating that the first shader task is being executed; finally, after the first shader task is completed, the state of the first shader task is restored to the first state for subsequent reuse or cleanup.

[0090] In this embodiment, by dynamically updating the state of shader tasks, effective management of the task lifecycle can be achieved. Timely release of resources after a task is used or completed helps improve resource utilization, ensures the flexibility, accuracy, and efficiency of task scheduling, thereby reducing task waiting time and significantly improving the overall performance of the graphics processor.

[0091] In some implementations, the task construction unit 11 (or task management unit) is further configured to allocate at least one shader task based on available resource information when the first number of shader tasks in the first state is less than a preset number, so that the number of shader tasks in the first state is greater than or equal to the preset number.

[0092] Here, throughout the rendering process, it's necessary to monitor the number of shader tasks in the first state in real-time or periodically. Shader tasks in the first state can be assembled immediately without waiting for additional resource allocation. The first state typically means that the shader task has completed at least partial resource allocation (such as identifiers, input resources, output resources, local storage, etc.) and is waiting to be populated by receiving shader instances.

[0093] The first quantity refers to the total number of shader tasks currently in the first state. This first quantity reflects the number of shader tasks that are immediately available and directly impacts the processing efficiency and overall throughput of upstream shader instances. In implementation, by counting the number of shader tasks in the first state, the current resource readiness can be dynamically assessed, and based on this number, a decision can be made as to whether to allocate further new shader tasks, thereby optimizing resource utilization and task composition efficiency.

[0094] The preset number represents the minimum number of available shader tasks that you want to maintain. The preset number can be adjusted based on different hardware platforms, application scenarios, etc. For example, a higher preset number can be set for high-performance graphics rendering scenarios, while a lower preset number can be set for resource-constrained devices. This preset number can be the same as or different from the second number in the configuration information. For example, this preset number can be the same as the second number. Or, for example, this preset number can be less than the second number.

[0095] Available resource information refers to the total amount of resources currently available for allocation, including but not limited to task identifiers, input resources, output resources, and local storage resources. During implementation, by managing and recording task identifiers, input resources, output resources, and local storage resources, it is possible to quickly determine whether there are sufficient resources available for allocation.

[0096] For example, an available resource list can be used to manage and record all resources. An available resource list is a data structure used to record the status of all currently available and assignable resources. The available resource list can include, but is not limited to, each available resource (or all resources), its usage status, etc. By accessing the available resource list, we can understand which resources are idle, thus providing the foundation for allocating new shader tasks. It is understandable that there is a close relationship between available resource information and the available resource list. Available resource information is a crucial basis for deciding whether to allocate new tasks, and the specific content of the available resource information is organized and stored by the available resource list.

[0097] When the number of shader tasks in the first state is detected to be lower than a preset number, new shader tasks can be dynamically allocated based on available resource information. The newly allocated shader tasks are in the first state, i.e., ready to receive shader instances, thus ensuring continuous and efficient processing of shader instances from upstream. This significantly reduces the waiting time for task assembly and improves the parallel processing capability of the GPU.

[0098] For example, if the available resource information meets the resource requirements of a new shader task, all resources can be allocated based on the resource requirements of the shader task without waiting for other shader tasks to complete and release resources.

[0099] For example, if the available resource information does not meet the resource requirements of a new shader task, partial resource allocation can be performed based on the resource requirements of the shader task (e.g., allocating task identifiers, task identifiers + input resources, etc.). Unallocated resources can wait for other shader tasks to complete and release resources before being allocated.

[0100] In this embodiment, by monitoring and replenishing the number of idle shader tasks, a certain number of immediately available task resources are always maintained to ensure efficient processing of shader instances from upstream, reducing the possibility of performance bottlenecks due to insufficient resources. Simultaneously, this dynamic task allocation design enables parallel allocation of shader instances and resources, eliminating the need for the task management unit to wait for other shaders to complete and release resources. This significantly reduces the waiting time for task assembly, ensuring rapid response to task assembly requests even under high-load scenarios, further enhancing graphics rendering performance.

[0101] In some embodiments, the task construction unit 11 (or task management unit) is further configured to: update the association information of the shader task based on the allocation information of the shader task when the shader task allocation is successful; update the association information of the target shader task when it is determined that the first shader task has been completed, wherein the target shader task includes the first shader task or other shader tasks, and the allocation result of at least one resource in the allocation information of other shader tasks indicates that the corresponding resource has not been allocated.

[0102] Here, the associated information of the shader task may include, but is not limited to, at least one of the following: the shader task identifier, the shader task status, and the shader task allocation information.

[0103] In some implementations, a pre-defined task list can be used to manage the association information of each shader task. The task list is a data structure that stores information related to multiple shader tasks, and its contents can be dynamically updated. Each entry in the task list corresponds to a shader task, and each entry records key attribute information of the shader task it corresponds to, such as task identifier, current state (e.g., first state, second state, third state, etc.), and allocation information. During implementation, by maintaining this task list, the status and resource usage of each shader task can be monitored in real time, thereby optimizing task scheduling and resource management. The task list can be implemented as a table, array, or linked list, depending on performance requirements and data access frequency.

[0104] The update mechanism for this task list can be triggered based on the allocation results of shader tasks. When a shader task is successfully allocated the required resources (such as input resources, output resources, local storage, etc.), the corresponding entry in the task list will be updated according to the allocation information to ensure that the shader task status is consistent with the actual execution status. This helps to improve transparency and controllability, and makes task scheduling more efficient.

[0105] There is a close data interaction between the task list and the task management unit. The task management unit is responsible for generating and managing each shader task and feeding back the information of each shader task to the task list. The task list then integrates the information of each shader task and provides it to the task assembly unit for reference. Based on the integrated information, the task assembly unit decides whether to select a new idle task (i.e., the first shader task), directly use a task that is being assembled (i.e., the third shader task), or continue to wait for a new task to complete.

[0106] In practice, the task list is not only used to record the basic information of shader tasks, but also serves as a centralized reflection point for changes in task status, providing data support for subsequent task scheduling, resource recycling and task reuse.

[0107] In some implementations, other structures such as arrays, trees, and tables can also be used to manage the association information of each shader task.

[0108] Once the first shader task completes execution, it triggers an update operation on the associated information of the target shader task. It's understandable that the target object of the update may include the first shader task itself, but it may also involve other shader tasks that haven't yet fully allocated resources. For example, it might switch the state of the first shader task to the first state and potentially release some resources for use by other shader tasks.

[0109] For other shader tasks, if their allocation information includes some unallocated resources, these unallocated resources can be allocated first, and then their allocation information updated to reflect that resource allocation is now complete. The pre-defined task list update mechanism based on unallocated resources helps the system promptly identify and categorize some shader tasks as ready to execute, while others still need to wait for resource allocation to complete.

[0110] The process of updating a target shader task may include, but is not limited to, updating its state and updating its allocation information. Updating the state refers to switching the shader task's state from the third state to the first state or another state. Updating the allocation information may involve releasing the resources occupied by a completed shader task and marking the resources as released in the task list; or, if unallocated resources for other shader tasks are allocated, marking the resources as fully allocated in the task list.

[0111] Once a shader task is complete, it is determined whether it needs to be recycled for later reuse. This recycling operation helps reduce the overhead of repeatedly creating shader tasks and improves runtime efficiency.

[0112] Update operations are not limited to single shader tasks; they can also process state changes of multiple shader tasks in batches. For example, during a single rendering process, dozens of shader tasks may complete simultaneously. When these shader tasks are completed, multiple entries in the task list can be updated at once, thereby reducing the impact on overall performance caused by frequent update operations.

[0113] In this embodiment, by maintaining and recording the associated information of each task (such as status, resource allocation, etc.), fine-grained management of the entire task pool is achieved. This not only enables the task building unit to respond more quickly to the shader instance sent from the upstream, but also provides data support for subsequent task scheduling, resource reclamation and task reuse. This not only helps to improve the accuracy of task scheduling decisions, but also allows for timely adjustment of task status after task completion or failure, thereby improving stability and reliability.

[0114] In some implementations, the geometry processing pipeline further includes a task generation unit, a shader engine, and a task control unit; the task generation unit is used to split the received drawing instructions into at least one task package and send each task package to the shader engine; the shader engine is used to generate at least one task component request based on each received task package and send each task component request to the task building unit; the task building unit is also used to generate task information for a first shader task and send the task information for the first shader task to the task control unit; the task control unit is used to obtain the shading result of the first shader task based on the received task information of the first shader task and output the shading result of the first shader task to the target pipeline after the geometry processing pipeline.

[0115] Here, the task generation unit is a core component of the geometry processing pipeline, responsible for receiving drawing instructions and splitting them into task packages based on different drawing instructions. Drawing instructions are the basic commands in the GPU used to trigger graphics rendering operations, typically issued by the application or driver. Drawing instructions can include, but are not limited to, draw instructions (used to draw vertex primitives) and dispatchmesh instructions (used for the mesh shader pipeline). Draw instructions are for the traditional rasterization rendering pipeline, while dispatchmesh instructions are for the mesh shading rendering pipeline. The task generation unit's role is to parse and split the drawing instructions, converting them into task packages suitable for the shader engine to process. Each task package should contain sufficient information so that the shader engine can correctly generate the shader instance request corresponding to that task package.

[0116] The method of splitting task packages depends on the specific instruction type. For example, for the `draw` instruction, the task generation unit can be split into a fixed number (e.g., 50, 200, 600, etc.) of vertex primitives. For the `dispatchmesh` instruction, it can be split into thread groups. By splitting drawing instructions into multiple task packages, large blocks of graphics data can be effectively decomposed into smaller blocks, thereby improving the parallelism and throughput of graphics processing.

[0117] The shader engine is the core computational unit in the geometry processing pipeline used to handle different types of shader tasks. Its main function is to receive task packages from the task generation unit and, based on these packages, generate task assembly requests containing at least one shader instance, which are then sent to the task building unit. There can be at least one shader engine. This task assembly request may include, but is not limited to, information such as shader type, input resources, and output resources, guiding the task building unit on how to assemble the shader task. Shader types may include, but are not limited to, vertex shaders, shell shaders, domain shaders, geometry shaders, magnification shaders, and mesh shaders. This transforms the original drawing instructions into specific shader task requests, providing fundamental support for subsequent task construction and execution.

[0118] In practice, there is a clear relationship between task packages and task component requests. Each task package will generate one or more task component requests, the specific number depending on the shader complexity and graphics processor configuration corresponding to the task package.

[0119] The Task Building Unit (TBU) is a core component in the GPU used for assembling and managing shader tasks. Its main function is to receive task assembly requests from the shader engine and generate specific shader tasks based on these requests. Task information is a key data structure describing a shader task, which may include, but is not limited to, task identifiers, input resources, output resources, and local storage resources. After generating the task information, the TBU sends it to the Task Control Unit, enabling the Task Control Unit to schedule and manage the shader tasks based on this information.

[0120] The task control unit, acting as the scheduling center of the entire geometry processing pipeline, is responsible for receiving task information from the task building units and determining how to output the shading results to subsequent pipeline stages based on this information. For example, in single-engine mode, the task control unit directly sends the task to the rasterization stage; while in dual-engine mode, the task control unit sends the task to the subdivision unit or rasterization stage respectively, depending on the task's origin (first shader engine or second shader engine). This scheduling method enables more efficient resource scheduling and task allocation, improving overall rendering efficiency.

[0121] After receiving task information, the task control unit obtains the shading results based on relevant information in the task information (such as task identifier, input / output resources, etc.) and outputs the shading results to the target pipeline (such as the rasterization pipeline or pixel processing pipeline) after the geometry processing pipeline. In implementation, through the collaborative work of the task building unit and the task control unit, the GPU can efficiently manage and schedule the execution of shader tasks, thereby improving the overall performance and efficiency of graphics processing.

[0122] By introducing task generation units, shader engines, and task control units into the geometry processing pipeline, not only is the flexibility and scalability of graphics processing improved, but the performance bottleneck caused by the original serial processing method of GPUs can also be effectively reduced.

[0123] In practice, the various units mentioned above collaborate closely. The task generation unit first parses and breaks down the drawing instructions to generate task packages; the shader engine generates task component requests based on the task packages and sends them to the task construction unit; the task construction unit is responsible for generating complete task information and passing it to the task control unit; finally, the task control unit obtains the shading results based on the task information and outputs the shading results to subsequent pipelines, thus forming a closed-loop graphics processing pipeline, which improves the processing efficiency and flexibility of the GPU.

[0124] In this embodiment, by introducing a task generation unit, a shader engine, and a task control unit into the geometry processing pipeline, the task generation unit breaks down the received drawing instructions, and the shader engine generates corresponding task component requests, thus achieving automated generation and scheduling of the task flow. The task control unit then transmits the execution results to subsequent pipelines. Through the collaborative work of the task component unit and the task control unit, the coherence and efficiency of the entire processing flow are ensured, thereby achieving rapid componentization and efficient scheduling of shader tasks. This significantly improves the parallel processing capability and task processing efficiency of the graphics processor, meeting the needs of high-load graphics applications.

[0125] In some implementations, the shader engine includes a first shader engine and a second shader engine, and the first shader task includes a first subtask, or a first subtask and a second subtask; the first shader engine is used to generate the first subtask in a single-engine mode or a dual-engine mode; wherein, the single-engine mode is the mode in which the first shader engine works, and the dual-engine mode is the mode in which the first shader engine and the second shader engine work together; the second shader engine is used to generate the second subtask in the dual-engine mode.

[0126] Here, integrating two independent shader engines into the GPU facilitates parallel processing and improves task execution efficiency. The first and second shader engines are physically independent, each with its own instruction stream, register resources, and execution pipeline, allowing them to run different shader tasks simultaneously. For example, when handling tessellation and mesh shader tasks, the first shader engine handles the execution of the shell and domain shaders, while the second shader engine handles the mesh shader. This allocation of complex tasks to different hardware units significantly improves overall throughput and responsiveness. Furthermore, it effectively separates different types of shader tasks, preventing resource contention between multiple tasks and enabling more efficient parallel computing, further enabling the GPU to adapt to high-load graphics processing scenarios.

[0127] The first shader task refers to the set of tasks processed by the shader engine. This first shader task can contain only a first subtask, or it can contain both a first subtask and a second subtask. The first subtask typically corresponds to basic shading operations, such as vertex shader or shell shader operations. The second subtask may involve more complex geometric processing, such as domain shader operations. This task design allows for flexible handling of different types and complexities of graphics tasks, improving the system's task processing capabilities.

[0128] Single-engine mode refers to a runtime mode that uses only the first shader engine to handle graphics tasks. In single-engine mode, all subtasks are completed by the first shader engine, which is suitable for relatively simple graphics processing needs.

[0129] Dual-engine mode refers to the operation mode that simultaneously utilizes the first and second shader engines. It is suitable for handling more complex graphics tasks, such as those involving both surface tessellation and mesh shading. In dual-engine mode, the first shader engine is primarily responsible for generating the first subtask, while the second shader engine is responsible for generating the second subtask. For example, when executing a mesh shader task, the first shader engine is responsible for initializing the mesh data, while the second shader engine is responsible for subsequent geometry generation operations.

[0130] In this embodiment, by introducing both single-engine and dual-engine operating modes, different types of shader task requirements can be flexibly addressed, achieving efficient parallel scheduling of tasks. Furthermore, enabling dual-engine mode when higher parallel processing capabilities are needed can significantly improve task processing efficiency and meet the demands of complex graphics rendering.

[0131] In some implementations, the task control unit is further configured to obtain the shading result of the first subtask based on the received task information of the first subtask; in single-engine mode, output the shading result of the first subtask to the target pipeline; or, in dual-engine mode, output the shading result of the first subtask to the second shader engine, and obtain the shading result of the second subtask based on the received task information of the second subtask, and output the shading result of the second subtask to the target pipeline.

[0132] Here, single-engine mode refers to the situation where the GPU uses only the first shader engine to handle the entire shading process.

[0133] The first subtask refers to an independent shading task generated and executed in single-engine mode. The task construction unit packages the shader instance sent by the first shader engine into a complete first subtask, and sends the packaged first subtask to the task execution unit for computation, generating the task information for the first subtask. After the first subtask completes shading, the shading result of the first subtask is directly passed to other pipelines after the geometry processing pipeline (such as rasterization, pixel processing pipelines, etc.), without needing to be processed by the second shader engine.

[0134] Dual-engine mode refers to the GPU simultaneously enabling two shader engines (the first shader engine and the second shader engine) to collaboratively handle different shading tasks. This mode is typically used in complex graphics rendering scenarios, such as tessellation and mesh shading. The first shader engine is responsible for handling tasks such as the shell shader and domain shader, while the second shader engine handles the mesh shader or other tasks.

[0135] In dual-engine mode, the shading result of the first subtask is not directly output to subsequent pipelines, but is transmitted to the second shader engine as input data. The second shader engine generates a corresponding task component request based on the received result of the first subtask. The task component unit packages the shader instance sent by the second shader engine into a complete second subtask, and sends the packaged second subtask to the task execution unit for computation, generating the task information for the second subtask. Once the second subtask completes shading, its result is output to subsequent pipelines. This collaborative approach in dual-engine mode enables more efficient processing of complex graphics tasks and improves the overall processing capacity of shader tasks.

[0136] Understandably, the second subtask often depends on the output data of the first subtask. For example, in surface tessellation, the second subtask might correspond to the domain shader task, whose computation results are used to further generate geometric primitives for subsequent rasterization and pixel processing stages.

[0137] In this embodiment, the task control unit processes the output paths of subtasks according to different engine modes, realizing the division of labor and cooperation between the two engine modes, ensuring the correct transmission and efficient processing of data streams. Furthermore, in dual-engine mode, by feeding back the results of the first subtask to the second shader engine, the task processing flow can be further optimized, improving the overall collaborative efficiency of the two shader engines, ensuring the correct routing of shading results, and thus enhancing the multitasking capabilities of the graphics processor to adapt to more complex and diverse graphics rendering needs.

[0138] In some implementations, the geometry processing pipeline further includes a subdivision unit; the subdivision unit is configured to perform surface subdivision or derivation operations on the shading results of the first subtask sent by the task control unit to obtain operation results, and send the operation results to the second shader engine; the second shader engine is further configured to generate at least one task component request for the second subtask and task information of the second subtask based on the operation results.

[0139] Here, a subdivision unit can be a hardware module used to perform surface subdivision or mesh derivation operations. Typically located in the later stages of the geometry processing pipeline, the subdivision unit receives shading result data (such as the output of HS) from the task control unit and further processes it. The subdivision unit can dynamically subdivide the original surface model, generating more vertices to achieve finer surface detail. The subdivision unit can also generate new geometries based on input parameters, such as creating multiple thread groups for subsequent processing through mesh derivation operations.

[0140] Surface tessellation refers to the dynamic segmentation of the original surface in surface modeling based on given parameters, generating more vertices and triangles to enhance the model's detail. Surface tessellation can be performed by setting control points and tessellation factors in the Surface Hashing (HS) module, followed by the Surface Derivation (DS) module calculating the position of each tessellation point. Derivation operations, on the other hand, directly generate new geometric primitives, such as triangles or line segments, based on the input topology and control parameters. These primitives are used for subsequent processing. Both tessellation and derivation operations significantly improve the flexibility and efficiency of graphics processing. After the tessellation unit completes its operation, it sends the processed data as the result to the second shader engine. The second shader engine then generates corresponding shader instances based on this data for the task building unit to continue processing. This approach enables a more efficient geometry processing pipeline, significantly improving graphics rendering performance when handling complex scenes. Furthermore, it effectively separates the different stages of task building and geometry processing, enhancing overall parallel processing capabilities.

[0141] In practice, all units in the geometry processing pipeline work together. The task building unit is responsible for task organization and scheduling, the task execution unit is responsible for specific data processing, and the subdivision unit performs fine-grained processing of geometric data and passes the processing results to the subsequent shader engine to support more complex graphics rendering needs. This staged and parallel processing approach enables GPUs to have higher efficiency and greater adaptability when processing large-scale graphics data.

[0142] In this embodiment, by introducing a subdivision unit into the geometry processing pipeline, the subdivision unit performs surface subdivision or derivation processing on the shading results of subtasks, which can generate more refined geometric data, providing high-quality input for the execution of subsequent shader tasks, helping to improve the quality and detail of graphics rendering, and thus supporting more complex graphics rendering needs.

[0143] In some implementations, the task generation unit is also used to determine the target engine mode based on configuration information, the target engine mode including a single engine mode or a dual engine mode; if the target engine mode is different from the previous target engine mode, a corresponding synchronization mark is generated, the synchronization mark is used to indicate the transmission of the coloring result of the first subtask after the synchronization mark.

[0144] Here, the configuration information indicates which shader the GPU should use. Based on this configuration information, the target engine mode can be determined. In some implementations, a correspondence between various configuration information and various engine modes can be pre-established, and based on this correspondence, the target engine mode adapted to the configuration information can be obtained. In some implementations, a correspondence between various shaders and various engine modes can be pre-established, and based on this correspondence, the target engine mode adapted to the shader used in the configuration information can be obtained.

[0145] The target engine mode determines whether the GPU uses a single shader engine or two shader engines to execute tasks. Single-engine mode is suitable for simple shading processes, such as those requiring only a single shader engine (VS), only a single shader engine (MS), or VS+GS. Dual-engine mode is suitable for complex shading combinations, such as VS+HS+DS, AS+MS, etc. The task generation unit determines the allocation of subsequent shader engines based on configuration information, thereby improving overall rendering efficiency. This achieves a more flexible task scheduling mechanism, better adapting to different types of graphics workloads, improving GPU utilization, and enhancing task execution efficiency.

[0146] A synchronization flag is a control signal or identifier used to ensure the correctness and consistency of data flow when engine modes switch. A synchronization flag can be a specific control byte, a timestamp, or a special task structure, allowing downstream processing modules such as the task building unit and task control unit to identify and make corresponding adjustments. A synchronization flag indicates that all tasks following it will be executed in the new engine mode, and the coloring result of the first subtask after the synchronization flag needs special handling to avoid data dependency errors or pipeline conflicts caused by mode switching.

[0147] In implementation, when the task generation unit detects that the current target engine mode is different from the previously used engine mode (e.g., switching from single-engine mode to dual-engine mode, or from dual-engine mode to single-engine mode), the task generation unit generates a synchronization flag. This effectively prevents rendering anomalies or data loss due to context switching, improves the stability and accuracy of multi-engine collaborative work, and reduces conflicts and delays during task execution. In some implementations, the same synchronization flag can be generated when switching engine modes, or different synchronization flags can be generated. For example, if a switch from single-engine mode to dual-engine mode or from dual-engine mode to single-engine mode is detected, the synchronization flag is set to a preset value (e.g., 1, TRUE, etc.). Alternatively, if a switch from single-engine mode to dual-engine mode is detected, the synchronization flag is set to a first value (e.g., 1, etc.). If a switch from dual-engine mode to single-engine mode is detected, the synchronization flag is set to a second value (e.g., 2).

[0148] In this embodiment, by inserting a synchronization flag when switching engine modes, the order and dependencies of task execution can be effectively managed, achieving an efficient and stable task scheduling mechanism, preventing data chaos or error transmission caused by mode switching, thereby ensuring the stability and correctness of the graphics processor operation.

[0149] In some implementations, the task generation unit is further configured to use a single-engine mode as the target engine mode when the configuration information indicates that the first shader is enabled; and to use a dual-engine mode as the target engine mode when the configuration information indicates that the second shader is enabled; wherein the first shader includes one of the following: a vertex shader, a vertex shader and a geometry shader, and a mesh shader; the second shader includes one of the following: an amplification shader and a mesh shader, a vertex shader, a shell shader and a domain shader, or a vertex shader, a shell shader, a domain shader and a geometry shader; in the dual-engine mode, the first shader engine includes an amplification shader, or a vertex shader and a shell shader, and the first shader engine includes a mesh shader, or a domain shader, or a domain shader and a geometry shader.

[0150] Here, the first shader refers to a user-configurable combination of shaders in the geometry processing pipeline, which determines whether a single-engine mode is used. For example, when the user only enables VS, only enables VS+GS, or only enables MS, it is usually processed independently by a single shader engine, thus entering single-engine mode.

[0151] Secondary shaders refer to shader combinations that require two shader engines to work together. For example, when a user enables AS+MS, VS+HS+DS, or VS+HS+DS+GS, it switches to dual-engine mode. Dual-engine mode speeds up overall rendering efficiency by distributing different shader combination tasks to different shader engines.

[0152] In dual-engine mode, the first shader engine handles VS, HS, AS, etc., while the second shader engine handles DS, MS, GS, etc. By assigning different shader combinations to the two shader engines for processing, the system achieves parallel execution of different types of shader combinations, thereby avoiding performance bottlenecks caused by serial processing.

[0153] In practice, the system first reads the configuration information to determine the currently enabled shader composition type. Then, based on the shader composition type, it decides whether to use a single-engine or dual-engine mode. Next, the corresponding shaders are assigned to appropriate shader engines for parallel processing. In this way, the system intelligently selects the appropriate engine mode for the current shader composition based on the configuration information and rationally distributes shader composition tasks to different shader engines for processing. This ensures that shader composition tasks are efficiently allocated and executed, thereby improving throughput and overall performance while reducing task processing latency.

[0154] In this embodiment, by dynamically selecting the engine mode suitable for the current task requirements based on configuration information, the potential of hardware resources can be fully utilized, improving the flexibility and efficiency of task processing. Especially in application scenarios involving complex shader combinations, the dual-engine mode can significantly enhance processing power and accelerate overall rendering efficiency.

[0155] In some implementations, the task control unit is further configured to: output the shading result of the first subtask after synchronization marking to the second shader engine when the synchronization marking representation switches from single-engine mode to dual-engine mode; block the first subtask after synchronization marking when the synchronization marking representation switches from dual-engine mode to single-engine mode; and output the first subtask after synchronization marking to other pipelines when task information of the second subtask before synchronization marking is received.

[0156] Here, the task generation unit is also responsible for generating corresponding synchronization markers when switching between different shader modes, which can ensure that downstream modules correctly identify the shader configuration currently in use.

[0157] A synchronization flag is a control signal or identifier generated by the task generation unit in the geometry processing pipeline when the shader engine mode changes (e.g., switching from single-engine mode to dual-engine mode). The synchronization flag notifies downstream modules that the current shader mode has changed, ensuring that downstream modules can correctly schedule tasks according to the current shader mode. The synchronization flag can be a specific bit field, a flag bit, or a field in a data packet.

[0158] Single-engine mode uses only one shader engine, where all shader instances are processed by the first shader engine. Single-engine mode is suitable for relatively simple graphics rendering scenarios. Dual-engine mode uses two shader engines simultaneously, working collaboratively to handle different shader types or stages. For example, in a tessellation pipeline, the first shader engine handles Action Screen (AS), while the second shader engine handles Subtlety Screen (MS). Dual-engine mode enhances parallel processing capabilities and is particularly suitable for complex geometry processing tasks.

[0159] The first subtask refers to the task consisting of shader instances generated by the first shader engine and sent to the task construction unit during the shader task construction process. In single-engine mode, the shading result of the first subtask is directly sent to the rasterization stage; while in dual-engine mode, the shading result of the first subtask needs to be further passed to the second shader engine for subsequent processing.

[0160] When a synchronization marker is detected, indicating a switch from single-engine mode to dual-engine mode, the shading result of the first subtask generated before the synchronization marker is sent to other pipelines, while the shading result of the first subtask generated after the synchronization marker is sent to the second shader engine. This effectively utilizes the parallel processing capabilities of the two shader engines, thereby reducing task processing latency and improving the overall throughput of graphics processing.

[0161] Blocking refers to temporarily halting further processing of the first subtask generated after the synchronization marker indicates a switch from dual-engine mode to single-engine mode. This prevents tasks from being mistakenly sent to inappropriate processing paths before the mode switch is complete. The blocking mechanism ensures the stability of task scheduling during the switch, avoiding resource conflicts or task loss.

[0162] In dual-engine mode, the second subtask refers to a task consisting of shader instances generated by the second shader engine and sent to the task building unit. The second subtask requires the participation of the second shader engine for processing. Since the second shader engine is no longer used in single-engine mode, the first subtask, after being synchronized, can be directly sent to other pipelines for processing.

[0163] When a synchronization marker is detected indicating a switch from dual-engine mode to single-engine mode, the first subtask generated after the synchronization marker is blocked. Then, depending on whether task information for the second subtask generated before the synchronization marker is received, it is decided whether to forward the second subtask to other pipelines. This effectively manages task flow, avoids task backlog or disordered processing order, and ensures the orderliness and continuity of tasks during mode switching.

[0164] In practice, when a change in engine mode is detected, a synchronization flag is first generated. Based on the specific type of the synchronization flag (e.g., switching from single-engine mode to dual-engine mode or vice versa), a corresponding task scheduling strategy is triggered. For example, when switching to dual-engine mode, the first subtask after the synchronization flag is redirected to the second shader engine for further processing. When switching back to single-engine mode, the first subtask after the synchronization flag is blocked until it is confirmed that the second shader engine is no longer needed, at which point it is forwarded to other pipelines for processing. This entire process ensures that task flow is uninterrupted during engine mode switching and always meets the requirements of the current operating state, thus achieving efficient and stable graphics processing.

[0165] In this embodiment, by employing a reasonable data processing strategy when switching between different engine modes, data conflicts and resource waste can be effectively avoided, ensuring the continuity and efficiency of task execution. This significantly reduces latency in the graphics processing process, thereby improving the smoothness of graphics rendering. In particular, during mode switching, appropriate blocking mechanisms and task forwarding strategies are used to maintain the efficient and stable operation of the graphics processor.

[0166] Based on the foregoing embodiments, this application also provides a data processing method, which can be applied to any of the aforementioned graphics processors. Figure 2 This is a schematic diagram illustrating the implementation flow of a data processing method provided in an embodiment of this application, such as... Figure 2 As shown, the data processing method includes steps S21 to S23, wherein: Step S21: (Task building unit or task management unit) Assign at least two shader tasks; Step S22: (Task building unit or task assembly unit) In response to receiving a task assembly request, determine a first shader task from at least two shader tasks. The first shader task is used to assemble the shader instance in the task assembly request. Step S23: (Task Execution Unit) Execute the first shader task that has been assembled.

[0167] Here, a shader task refers to a task consisting of multiple shader instances. The process of allocating this shader task can be found in the aforementioned embodiments of the graphics processor.

[0168] A task assembly request is a signal from upstream indicating that a new shader instance needs to be assembled.

[0169] The first shader task is a shader task capable of constructing the shader instance in the task construction request. The process for determining the first shader task can be found in the aforementioned embodiments of the graphics processor.

[0170] The task execution unit receives shader tasks assembled by the task construction unit and executes the shader tasks in a predetermined order. The process of the task execution unit executing the first shader task can be found in the aforementioned embodiments of the graphics processor.

[0171] In this embodiment, firstly, multiple shader tasks are pre-allocated to avoid resource allocation upon receiving shader instances, thus reducing waiting time. Secondly, upon receiving a task assembly request, a suitable shader task is directly selected for assembly without further resource allocation upon receiving shader instances. This effectively decouples the resource allocation from shader instance reception, allowing upstream shader instance senders to continue sending without waiting for resource allocation to complete, fully utilizing upstream bandwidth and improving efficiency. It also reduces blocking during task assembly, significantly shortening the assembly time and thus dramatically improving the assembly speed. Finally, execution begins immediately upon receiving a complete shader task. Compared to the serial processing method in related technologies, this solution, by parallelizing shader task resource allocation and shader instance reception, efficiently completes task assembly and execution, significantly improving the overall performance and throughput of the image processor.

[0172] In some implementations, step S21 includes: (task building unit or task management unit) allocating at least two shader tasks based on all resource information.

[0173] In some embodiments, the data processing method further includes: (task building unit or task management unit) receiving configuration information, the configuration information including a second number of shader tasks and resource requirement information of the target shader; the step S21 includes: (task building unit or task management unit) allocating a second number of shader tasks based on available resource information and resource requirement information of the target shader.

[0174] In some implementations, the task building unit further includes a configuration unit; the data processing method further includes: the task building unit sending configuration information to the configuration unit; the configuration unit sending the configuration information to the task management unit, so that the task management unit allocates a second number of shader tasks.

[0175] In some implementations, the step S22 of "determining a first shader task from at least two shader tasks" includes: determining a first shader task based on the state of at least one shader task.

[0176] In some implementations, "determining a first shader task based on the state of at least one shader task" includes: determining a first shader task from at least one second shader task when the state of each shader task is not a second state and at least one second shader task in a first state exists among at least two shader tasks.

[0177] In some implementations, "determining a first shader task from at least one second shader task" includes: determining a first shader task based on allocation information for each second shader task, wherein the allocation information for the second shader task includes the allocation result of at least one resource required by the second shader task, and the resource allocation result indicates whether the resource has been allocated.

[0178] In some implementations, the step S22 of "determining a first shader task from at least two shader tasks" includes: determining a first shader task based on at least one shader task in the second state when at least one shader task is in the second state.

[0179] In some embodiments, the data processing method further includes at least one of the following: (task construction unit or task management unit) switches the state of the first shader task to a second state; (task construction unit or task management unit) sends the first shader task to the task execution unit; after sending the first shader task to the task execution unit, (task construction unit or task management unit) switches the state of the first shader task to a third state; and when it is determined that the first shader task has been completed, (task construction unit or task management unit) switches the state of the first shader task to a first state.

[0180] In some implementations, the data processing method further includes: when the first number of shader tasks in the first state is less than a preset number, (task building unit or task management unit) allocates at least one shader task based on available resource information, so that the number of shader tasks in the first state is greater than or equal to the preset number.

[0181] In some implementations, the data processing method further includes: when the shader task is successfully assigned, the task construction unit or task management unit updates the associated information of the shader task based on the assignment information of the shader task.

[0182] In some embodiments, the data processing method further includes: upon determining that the first shader task has been completed, (task construction unit or task management unit) updating the association information of the target shader task, wherein the target shader task includes the first shader task or other shader tasks, and the allocation result of at least one resource in the allocation information of the other shader tasks indicates that the corresponding resource has not been allocated.

[0183] In some embodiments, the geometry processing pipeline further includes a task generation unit, a shader engine, and a task control unit; the data processing method further includes: the task generation unit splitting the received drawing instructions into at least one task package and sending each task package to the shader engine; the shader engine generating at least one task component request based on each received task package and sending each task component request to the task building unit; the task building unit generating task information for a first shader task and sending the task information for the first shader task to the task control unit; and the task control unit obtaining the shading result of the first shader task based on the received task information of the first shader task and outputting the shading result of the first shader task to the target pipeline following the geometry processing pipeline.

[0184] In some implementations, the shader engine includes a first shader engine and a second shader engine, and the first shader task includes a first subtask, or a first subtask and a second subtask; the data processing method further includes: in single-engine mode, the first shader engine generates the first subtask; in dual-engine mode, the first shader engine generates the first subtask and the second shader engine generates the second subtask.

[0185] In some implementations, the task control unit obtains the shading result of the first shader task based on the received task information of the first shader task, including: the task control unit obtains the shading result of the first subtask based on the received task information of the first subtask. The task control unit outputs the shading result of the first shader task to the target pipeline after the geometry processing pipeline, including: in single-engine mode, the task control unit outputs the shading result of the first subtask to the target pipeline; or, in dual-engine mode, the task control unit outputs the shading result of the first subtask to the second shader engine, and obtains the shading result of the second subtask based on the received task information of the second subtask, and outputs the shading result of the second subtask to the target pipeline.

[0186] In some embodiments, the geometry processing pipeline further includes a subdivision unit; the data processing method further includes: the subdivision unit performing a surface subdivision operation or a derivation operation on the shading result of the first subtask sent by the task control unit to obtain an operation result, and sending the operation result to the second shader engine; the second shader engine generating the second subtask includes: the second shader engine generating at least one task component request for the second subtask and task information of the second subtask based on the operation result.

[0187] In some implementations, the data processing method further includes: the task generation unit determining a target engine mode based on configuration information, the target engine mode including a single engine mode or a dual engine mode; and generating a corresponding synchronization marker when the target engine mode is different from the previous target engine mode, the synchronization marker being used to indicate the transmission of the coloring result of the first subtask after the synchronization marker.

[0188] In some implementations, the task generation unit determines the target engine mode based on configuration information, including: when the configuration information indicates that the first shader is enabled, the task generation unit uses the single-engine mode as the target engine mode; when the configuration information indicates that the second shader is enabled, the task generation unit uses the dual-engine mode as the target engine mode; wherein the first shader includes one of the following: a vertex shader, a vertex shader and a geometry shader, and a mesh shader; the second shader includes one of the following: an amplification shader and a mesh shader, a vertex shader, a shell shader and a domain shader, or a vertex shader, a shell shader, a domain shader and a geometry shader; in the dual-engine mode, the first shader engine includes an amplification shader, or a vertex shader and a shell shader, and the first shader engine includes a mesh shader, or a domain shader, or a domain shader and a geometry shader.

[0189] In some implementations, the data processing method further includes: when the synchronization mark representation switches from a single-engine mode to a dual-engine mode, the task control unit outputs the coloring result of the first subtask after synchronization mark to the second shader engine; when the synchronization mark representation switches from a dual-engine mode to a single-engine mode, the task control unit blocks the first subtask after synchronization mark, and upon receiving the task information of the second subtask before synchronization mark, outputs the first subtask after synchronization mark to other pipelines.

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

[0191] The technical solution of this application is described in detail below.

[0192] In relevant solutions, a serial processing method is typically employed. When the shader assembly receives a shader instance, including vertex shaders, shell shaders, domain shaders, geometry shaders, or fragment shaders, it begins allocating the resources required by these shader instances, including but not limited to task identifiers, input resources, output resources, and local memory. This resource allocation takes some time, which will block upstream transmission of shader instances until the required resources are allocated. Only then will the shader assembly accept upstream shader instances and fill them into the shader task. After the shader task is assembled (typically containing a certain number of shader instances, such as 16 or 32), the shader task is sent to the shader execution part for execution.

[0193] The proposed solution requires that the resource allocation of shader tasks and the reception of shader instances be executed sequentially. While the shader task is not fully assembled, the shader assembly phase cannot accept shader instances sent from upstream, which significantly reduces the efficiency of upstream shader instance sending and lowers system throughput. Simultaneously, this also slows down the assembly speed of shader tasks, degrading system performance.

[0194] In order to make full use of the bandwidth of upstream shader instance sending, improve the speed of shader task assembly, and enhance the overall system performance, this application proposes a new method for rapid shader task assembly.

[0195] The geometric processing of the GPU proposed in this application is as follows: Figure 3 As shown: TBR (Tile-Based Rendering) GPUs mainly consist of two parts: a geometry processing pipeline and a pixel processing pipeline. Figure 3 This application primarily showcases a geometry processing pipeline. The geometry processing pipeline designed in this application mainly comprises the following parts: The task generation unit 31 is used to receive the draw command and dispatchmesh command sent by the user, and split them into appropriate task packages and send them downstream. When the shader mode is switched, the task generation unit needs to generate appropriate control flags (corresponding to the aforementioned synchronization flags) and send them downstream.

[0196] The first shader engine 32 is responsible for handling user-configured shader tasks.

[0197] The second shader engine 33 is responsible for handling user-configured specific shader tasks.

[0198] The shader task construction unit 34 (corresponding to the aforementioned task construction unit) receives shader tasks (i.e., shader instances) sent from the first shader engine and the second shader engine (and possibly the pixel shader), allocates corresponding resources to them, and sends the shader tasks to the shader execution unit. The information of the corresponding tasks (corresponding to the aforementioned task information) is synchronously sent to the task control unit.

[0199] The shader execution unit 35 (corresponding to the aforementioned task execution unit) executes the shader task sent by the shader task construction unit, uses resources including the on-chip storage unit 30, and finally outputs the result to the vertex buffer unit.

[0200] Vertex buffer unit 36 ​​is used to store the results of the geometry processing rendering pipeline.

[0201] The task control unit 37 receives task information sent from the shader task construction unit, processes the tasks from the first shader engine and the second shader engine correctly, sends the appropriate task back to the surface subdivision and mesh shading generation unit (corresponding to the aforementioned subdivision unit), and sends the appropriate task to rasterization, and enables the pixel processing part.

[0202] The tile generation unit 38 receives primitive information from the task control unit and obtains vertex information from the vertex buffer unit to construct a primitive block.

[0203] Tile storage unit 39 stores tile information.

[0204] The tile generation unit 310 constructs a tile control flow for the generated tiles and writes it to the storage 311.

[0205] The geometry processing pipeline utilizes a first-level shader engine and a second-level shader engine to handle different shader combinations, including VS, HS, DS, GS, AS, and MS. When the user uses different shader configurations, the first-level shader engine and the second-level shader engine are responsible for the following shader patterns respectively: When the user specifies that only a vertex shader or only a mesh shader is used, the first shader engine is responsible for sending vertex shading tasks (i.e., vertex shader instances) or the corresponding mesh shading tasks (i.e., mesh shader instances). When the user specifies that both vertex shading and geometry shading are used, only the first shader engine is responsible for sending both vertex shading tasks and geometry shading tasks (i.e., geometry shader instances). These three shader patterns only use the first shader engine, hence they are called single-shader-engine patterns (corresponding to the aforementioned single-engine pattern).

[0206] When the user configures the use of an amplification shader and a mesh shader, or a vertex shader plus a shell shader and a domain shader, or a vertex shader plus a shell shader, a domain shader, and a geometry shader, both shader engines are activated simultaneously. The first shader engine is responsible for the amplification shader, vertex shader, and shell shader, while the second shader engine is responsible for the remaining mesh shader, domain shader, and domain shader plus geometry shader. These three modes use two shader engines, hence this shader pattern is called the dual-shader-engine pattern (corresponding to the aforementioned dual-engine pattern).

[0207] In dual-shader engine mode, the output of the first shader engine is sent to the vertex buffer unit. The task control unit then retrieves the output from the vertex buffer unit and sends it back to the tessellation and mesh shader task generation unit. The tessellation and mesh shader task generation unit primarily handles the generation of tessellation and mesh shader tasks. This module mainly receives tessellation parameters generated by the shell shader during tessellation, or DispatchMesh command parameters generated by the amplified shader, performs tessellation, or derives the corresponding mesh shader MS thread group. The output of the tessellation and mesh shader task generation unit is sent to the second shader engine, which then sends the corresponding shader tasks.

[0208] The first and second shader engines send the corresponding shader instances to the shader task building unit. These shader instances include: In VS mode, one shader instance is sent for each vertex; During HS, a shader instance is sent for each patch (i.e., the set of control points); During DS (Data Shaders), a shader instance is sent to each vertex; During GS (Geometry Instance), one shader instance is sent for each primitive and each geometry instance (GS Instance). During AS, each thread sends one shader instance; In MS mode, each thread sends one shader instance.

[0209] The structure of the shader task construction unit designed in this application is as follows: Figure 4 As shown: The shader task construction unit 34 mainly consists of a task assembly unit 341, a shader configuration unit 342 (corresponding to the aforementioned configuration unit), an idle task maintenance unit 343 (corresponding to the aforementioned task management unit), and an available resource list 344. Specifically, the task assembly unit 341 receives shader instances from the first shader engine and the second shader engine, selects idle tasks from the idle task maintenance unit 343, packs the shader instances into the corresponding resources of the selected tasks, and sends the shader tasks to the shader execution unit. The task assembly unit 341 also receives configuration information from the first shader engine path and the second shader engine path and forwards it to the shader configuration unit 342.

[0210] The shader configuration unit 342 receives configuration information forwarded from the task assembly unit 341, including but not limited to: Shader patterns, such as whether to enable HS, whether to enable GS, whether to enable AS, etc.; The input and output resource sizes required for a specific shader; The amount of local storage resources required by a specific shader; The number of idle tasks configured (e.g., 5, 8, etc.).

[0211] The available resource list 344 represents available resource information, including task identifiers, input resources, output resources, local storage resources, etc. After receiving a series of information from the shader configuration unit 342, the idle task maintenance unit 343 will allocate resources to a certain number of idle tasks according to the available resources represented in the available resource list. Each task includes, but is not limited to, task identifiers, input resources, output resources, local storage resources, etc.

[0212] Among them, the process of querying available idle tasks by task composition unit 341 is as follows: Figure 5 As shown, the procedure includes steps S51 to S56, wherein: Step S51: The task assembly unit receives a shader task assembly request (i.e., when there is a shader instance in the first shader or second shader engine). Step S52: The task assembly unit needs to check the idle task maintenance unit; Step S53: The task assembly unit determines whether there are one or more idle tasks (i.e., whether there are available idle tasks). If there are, proceed to step S54; otherwise, proceed to step S56. Step S54: The task assembly unit can directly retrieve this idle task and remove it from the idle task maintenance unit; Step S55: The task creation unit uses the information from the retrieved idle tasks to create a task; Step S56: The task assembly unit needs to wait for a task to finish.

[0213] In this way, the idle task maintenance unit will reclaim the completed tasks, thereby providing a usable task for the task composition unit.

[0214] The workflow of the idle task maintenance unit 343 is as follows: Figure 6 As shown, the procedure includes steps S61 to S67, wherein: Step S61: After receiving the shader configuration (i.e., configuration information), the idle task maintenance unit will directly allocate a certain number of idle tasks, including all the resources they need.

[0215] Step S62: Receive a task assignment request from the task assembly unit; Step S63: The idle task maintenance unit checks whether the number of remaining idle tasks meets the set requirements. If not, proceed to step S64; if so, proceed to step S62. Step S64: The idle task maintenance unit will attempt to allocate new idle tasks.

[0216] Step S65: The idle task maintenance unit determines whether the allocation of a new idle task is successful. If the allocation is successful, proceed to step S66; if the allocation fails, proceed to step S67. Step S66: Fill the allocated idle task information into the maintained idle task list.

[0217] Step S67: Wait for a task to be completed.

[0218] If the number of idle tasks maintained in the idle task maintenance unit exceeds the set number, then there is no need to allocate new idle tasks; simply continue to respond to allocation requests from the task composition unit.

[0219] Optionally, the idle task allocation unit can allocate all available resources as idle tasks without requiring the shader configuration unit to specify the number of idle tasks. This approach can effectively reduce the allocation time for related resources and resolve potential fragmentation issues.

[0220] In another approach, idle task allocation can be segmented. That is, allocation occurs only when a portion of resources become available. When the task assembly unit needs an idle task, the idle task maintenance unit prioritizes idle tasks where all resources have been allocated. If none are available, it waits for already issued tasks to complete and updates the idle task maintenance list. When some idle tasks have only partially allocated resources, the completion of already issued tasks releases some resources. These released resources can be acquired and allocated by the incomplete idle tasks, thus making them complete. This approach can also effectively reduce the time required for task allocation.

[0221] To fully utilize the bandwidth of upstream shader instance sending, improve the speed of shader task assembly, and enhance overall system performance, this application proposes a novel method for rapid shader task assembly. This application advances the allocation of shader tasks before receiving shader instances by pre-allocating idle tasks, thus parallelizing the allocation and reception of shader instances. This significantly reduces the time required for shader task assembly and improves system performance.

[0222] Compared to existing solutions, the proposed solution can parallelize the assembly of shader tasks and the reception of shader instances, providing sufficient bandwidth for shader instance reception, improving the overall throughput of the system, and thus improving the system performance.

[0223] It should be noted that, in the embodiments of this application, if the above methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of software products. These software products are stored in a storage medium and include several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0224] This application provides an electronic device including any of the aforementioned graphics processors. The electronic device can be various types of terminals such as laptops, tablets, desktop computers, set-top boxes, and mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable gaming devices), or it can be implemented as a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0225] It should be noted that the description of the above device embodiments is similar to the description of the above graphics processor embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the graphics processor embodiments of this application for understanding.

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

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

[0228] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms. The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

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

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

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

Claims

1. A graphics processor, comprising: The graphics processor comprises a geometry processing pipeline, the geometry processing pipeline comprising a task building unit and a task execution unit, wherein: The task building unit is configured to assign at least two shader tasks, and determine a first shader task from the at least two shader tasks in response to receiving a task building request, the first shader task being used to build a shader instance in the task building request. The task execution unit is configured to execute the first shader task after the building is completed.

2. The graphics processor of claim 1, wherein: The task building unit is configured to determine the first shader task based on a state of at least one shader task.

3. The graphics processor of claim 2, wherein, The task building unit comprises a task building unit; The task building unit is configured to determine the first shader task from at least one second shader task in the at least two shader tasks in a case that the state of each of the shader tasks is not the second state and there is at least one second shader task in the first state in the at least two shader tasks.

4. The graphics processor of claim 3, wherein: The task building unit is configured to determine the first shader task based on assignment information of each of the second shader tasks, the assignment information of the second shader task comprising an assignment result of at least one resource required by the second shader task, the assignment result of the resource indicating whether the resource is assigned.

5. The graphics processor of claim 2, wherein, The task building unit comprises a task building unit; The task building unit is configured to determine the first shader task based on at least one shader task in the second state in a case that the state of at least one shader task is the second state.

6. The graphics processor of claim 2, wherein, The task building unit comprises a task management unit, and the task management unit is configured to at least one of: Switch the state of the first shader task to the second state, and send the first shader task to the task execution unit; Switch the state of the first shader task to a third state after the first shader task is sent to the task execution unit; Switch the state of the first shader task to the first state in a case that the execution of the first shader task is determined to be completed.

7. The graphics processor of claim 1, wherein, The task building unit comprises a task management unit; The task management unit is configured to assign at least one shader task based on available resource information in a case that a first number of shader tasks in the first state is less than a preset number, so that the number of shader tasks in the first state is greater than or equal to the preset number.

8. The graphics processor of claim 1, wherein, The task building unit comprises a task management unit, and the task management unit is configured to at least one of: In a case that the shader task is successfully assigned, update associated information of the shader task based on assignment information of the shader task; If it is determined that the first shader task has been completed, the association information of the target shader task is updated. The target shader task includes the first shader task or other shader tasks. The allocation result of at least one resource in the allocation information of the other shader tasks indicates that the corresponding resource has not been allocated.

9. The graphics processor of claim 1, wherein, The task construction unit includes a task management unit; The task management unit is used to allocate the at least two shader tasks based on all resource information.

10. The graphics processor of claim 1, wherein, The task construction unit includes a task management unit; The task management unit is configured to receive configuration information, which includes a second number of shader tasks and resource requirement information of the target shader; and to allocate the second number of shader tasks based on the available resource information and the resource requirement information of the target shader.

11. The graphics processor of claim 10, wherein, The task construction unit further includes a task assembly unit and a configuration unit, wherein: The task assembly unit is used to send the configuration information to the configuration unit; The configuration unit is used to send the configuration information to the task management unit so that the task management unit allocates the second number of shader tasks.

12. The graphics processor of any one of claims 1-11, wherein, The geometry processing pipeline also includes a task generation unit, a shader engine, and a task control unit, wherein: The task generation unit is configured to split the received drawing instructions into at least one task package and send each task package to the shader engine; the shader engine is configured to generate at least one task component request based on each received task package and send each task component request to the task building unit. The task construction unit is also used to generate task information for the first shader task and send the task information for the first shader task to the task control unit. The task control unit is configured to obtain the shading result of the first shader task based on the received task information of the first shader task, and output the shading result of the first shader task to the target pipeline after the geometry processing pipeline.

13. The graphics processor of claim 12, wherein, The shader engine includes a first shader engine and a second shader engine, and the first shader task includes a first subtask, or the first subtask and the second subtask. The first shader engine is used to generate the first subtask in a single-engine mode or a dual-engine mode; wherein, the single-engine mode is the mode in which the first shader engine works, and the dual-engine mode is the mode in which the first shader engine and the second shader engine work together. The second shader engine is used to generate the second subtask in the dual-engine mode.

14. The graphics processor according to claim 13, characterized in that, The task control unit is further configured to obtain the shading result of the first subtask based on the received task information of the first subtask; and in the single-engine mode, output the shading result of the first subtask to the target pipeline, or in the dual-engine mode, output the shading result of the first subtask to the second shader engine. Based on the received task information of the second subtask, the coloring result of the second subtask is obtained, and the coloring result of the second subtask is output to the target pipeline.

15. The graphics processor of claim 14, wherein, The geometry processing pipeline also includes subdivision units; The subdivision unit is used to perform surface subdivision or derivation operations on the shading results of the first subtask sent by the task control unit, obtain the operation results, and send the operation results to the second shader engine. The second shader engine is also configured to generate at least one task component request for the second subtask and task information for the second subtask based on the operation result.

16. The graphics processor according to claim 14, characterized in that, The task generation unit is further configured to determine a target engine mode based on configuration information, the target engine mode including the single engine mode or the dual engine mode; and generate a corresponding synchronization marker when the target engine mode is different from the previous target engine mode, the synchronization marker being used to indicate the transmission path of the coloring result of the first subtask after the synchronization marker.

17. The graphics processor of claim 16, wherein, The task control unit is also used for: When the synchronization mark representation switches from the single-engine mode to the dual-engine mode, the coloring result of the first subtask after the synchronization mark is output to the second shader engine; When the synchronization marker indicates a switch from the dual-engine mode to the single-engine mode, the first subtask following the synchronization marker is blocked. Upon receiving the task information of the second subtask before the synchronization mark, the first subtask after the synchronization mark is output to the target pipeline.

18. A data processing method, characterized by, Applied in a graphics processing unit (GPU), the GPU includes a geometry processing pipeline, and the data processing method includes: Assign at least two shader tasks; In response to receiving a task assembly request, a first shader task is determined from the at least two shader tasks, the first shader task being used to assemble the shader instance in the task assembly request; Execute the first shader task that has been assembled.

19. An electronic device, comprising: The graphics processor included in any one of claims 1 to 17.

Images