Shader merging methods, apparatus, electronic devices and storage media

Abstract

This disclosure provides a shader merging method, apparatus, electronic device, and storage medium, relating to the field of computer technology. The method includes: obtaining a first shader program and a second shader program; combining the first shader program and the second shader program into a target shader program according to a preset shading order to generate first shading instructions and second shading instructions; inserting a merge shader barrier instruction between the first shading instructions and the second shading instructions, the merge shader barrier instruction being used to prevent the execution of the second shading instruction before the first shading instruction has been completed. This disclosure, by merging multiple shader segments in user mode and setting merge shader barrier instructions between instructions, ensures that each shading stage is executed in a predetermined order, and that the processing result of the previous shading stage is reliably obtained in the subsequent shading stage, forming a stable multi-stage shading process, thereby achieving unified control over the overall shading logic.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a shader merging method, apparatus, electronic device, and storage medium. Background Technology

[0002] In a graphics rendering pipeline, vertex shaders, geometry shaders, and other programs are typically used to process graphics data at different stages and complete their respective computational tasks according to a fixed hardware execution order. To achieve more complex rendering effects, developers often need to pass intermediate data between multiple shading stages to build more flexible geometry processing flows. For example, primitive information can be organized in advance while completing vertex-level calculations, or overall decisions can be made during the geometry generation stage based on intermediate results from previous stages.

[0003] However, such cross-stage collaborative processing relies on flexible control over shader execution order, stage boundaries, and intermediate data visibility, which traditional fixed pipeline structures struggle to meet. To address this issue, one proposed approach is to reconstruct the hardware pipeline using a mesh shader scheme to support new shading task distribution and execution modes. However, this approach requires modification to the underlying hardware pipeline structure, resulting in an execution model that differs from existing rendering pipelines. This not only makes it difficult to maintain compatibility with the existing software ecosystem but also significantly increases hardware design complexity and user learning and usage costs. Another technical solution places the shader composition and scheduling logic at the driver and compiler level, allowing the system to automatically handle shader merging and execution. However, in this approach, the shader composition and execution logic are primarily controlled by the underlying system, making it difficult for users to directly participate in the organization of shader logic. Consequently, it cannot flexibly construct cross-stage processing flows according to scene requirements, limiting its applicability.

[0004] Therefore, there is an urgent need to provide a technical solution that enables users to have autonomous control over the cross-stage shader execution process without relying on hardware pipeline modifications, so as to achieve more flexible and efficient geometry processing and rendering execution.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this disclosure is to provide a shader merging method, apparatus, electronic device, and storage medium to overcome, to a certain extent, the problem in related technologies where cross-stage shader processing schemes rely on hardware pipeline modifications or automatic merging on the system side, making it difficult for users to independently control the shader execution logic.

[0007] According to a first aspect of this disclosure, a shader merging method is provided, comprising: Obtain the first shader program and the second shader program; According to the preset shading order, the first shader program and the second shader program are combined into the target shader program to generate the first shading instruction and the second shading instruction. A merge shader barrier instruction is inserted between the first shader instruction and the second shader instruction; the merge shader barrier instruction is used to prevent the execution of the second shader instruction before the first shader instruction has finished executing.

[0008] In one exemplary embodiment of this disclosure, the method further includes: Determine the maximum number of input vertices and the maximum number of input primitives to be used to execute the target shader program; Based on the maximum number of input vertices and the maximum number of input primitives, a barrier range corresponding to the merge shader barrier instruction is generated; the barrier range is used to define the scope of the merge shader barrier instruction; the merge shader barrier instruction is also used to automatically expire after the first shader instruction within the barrier range has been executed.

[0009] In one exemplary embodiment of this disclosure, determining the maximum number of input vertices and the maximum number of input primitives for executing the target shader program includes: Based on the first shader program and the second shader program, determine the maximum number of input vertices and the maximum number of input primitives used to execute the target shader program.

[0010] In one exemplary embodiment of this disclosure, determining the maximum number of input vertices and the maximum number of input primitives for executing the target shader program, based on the first shader program and the second shader program, includes: Analyze the input structures and output structures of the first and second shader programs, as well as the intermediate resources declared in the target shader program; Based on the input structure, output structure, and intermediate resources, and combined with the resource constraints used to execute the target shader program, the maximum number of input vertices and the maximum number of input primitives are determined.

[0011] In one exemplary embodiment of this disclosure, determining the maximum number of input vertices and the maximum number of input primitives for executing the target shader program includes: It receives settings for the number of input vertices and the number of input primitives, and determines the maximum number of input vertices and the maximum number of input primitives to be used to execute the target shader program based on the settings.

[0012] In one exemplary embodiment of this disclosure, the method further includes: In response to an edit operation on the first shader program and / or the second shader program, update the first shader program and / or the second shader program; Update the target shader program based on the updated first shader program and / or second shader program.

[0013] In one exemplary embodiment of this disclosure, the first shader program and the second shader program are shaders of different types, including one or more of vertex shaders, geometry shaders, shell shaders, and domain shaders.

[0014] According to a second aspect of this disclosure, a shader merging apparatus is provided, comprising: The shader acquisition module is used to acquire the first shader program and the second shader program; The shader merging module is used to combine the first shader program and the second shader program into the target shader program according to a preset shading order, and generate the first shading instruction and the second shading instruction. The shader barrier module is used to insert a merge shader barrier instruction between the first shader instruction and the second shader instruction; the merge shader barrier instruction is used to prevent the execution of the second shader instruction before the first shader instruction has been completed.

[0015] According to a third aspect of this disclosure, an electronic device is provided, comprising: A graphics processor; and a storage unit for storing executable instructions of the graphics processor; wherein the graphics processor is configured to execute the above-described shader merging method by executing the executable instructions.

[0016] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a graphics processor, implements the above-described shader merging method.

[0017] The exemplary embodiments disclosed herein may have some or all of the following beneficial effects: The shader merging method provided in the exemplary embodiments of this disclosure combines a first shader program and a second shader program into a target shader program in a preset order, and inserts a merge shader barrier instruction between the corresponding first shader instruction and the second shader instruction, so that the execution of the second shader instruction is premised on the completion of the first shader instruction, thereby establishing a clear execution order relationship within the target shader program.

[0018] This approach combines the processing logic that was originally located in different shading stages into the same shader program. The stage connection relationship is constrained within the program by the instruction order and the merge shader barrier instruction, instead of relying on the fixed scheduling order of the shading stages by the hardware pipeline. This allows for clear control over the execution order across stages without changing the existing rendering pipeline structure, avoiding the implementation complexity and compatibility issues caused by refactoring the hardware pipeline to support cross-stage processing in related technologies.

[0019] Meanwhile, since the combination relationship and execution order of the first and second shading instructions are embodied in the target shader program in program form, the cross-stage processing flow can be changed as the target shader program is adjusted, without requiring the driver or compiler to fix the combination of multiple shader stages on the system side. Based on this, users can configure the cross-stage processing logic by adjusting the organization of shading instructions and merging shader barrier instructions in the target shader program, thereby gaining controllability over the shader execution flow within the existing rendering pipeline and overcoming the problems of system-side limitations and insufficient flexibility in shader combination methods in related technologies.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0022] Figure 1 A system architecture diagram is shown that can be applied to the shader merging method in the embodiments of this disclosure.

[0023] Figure 2 A flowchart illustrating a shader merging method according to an embodiment of this disclosure is shown.

[0024] Figure 3 A flowchart illustrating a method for determining the barrier range corresponding to a merge shader barrier instruction is shown in an embodiment of this disclosure.

[0025] Figure 4 A flowchart illustrating a method for determining the maximum input size of a target shader program is shown in an embodiment of this disclosure.

[0026] Figure 5A schematic diagram of the principle of a graphics processing rendering pipeline applying the shader merging method of this disclosure is shown in an embodiment of the present disclosure.

[0027] Figure 6 A schematic diagram of a process for executing a merge shader is shown in an embodiment of this disclosure.

[0028] Figure 7 A schematic diagram illustrating the execution of the geometry processing phase after the introduction of the merge shader barrier function is shown in an embodiment of this disclosure.

[0029] Figure 8 A block diagram of a shader merging apparatus according to an embodiment of the present disclosure is shown.

[0030] Figure 9 A schematic diagram of the structure of an electronic device suitable for implementing embodiments of the present disclosure is shown.

[0031] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0032] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this disclosure more comprehensive and complete, and to fully convey the concept of the example embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more of the specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0033] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0034] First, the relevant technical background of the exemplary implementation methods disclosed herein will be introduced: In computer graphics, graphics processors (GPUs) are commonly used to process input geometric data to generate displayable images. GPUs typically have a rendering pipeline, which performs a series of transformations and calculations on geometric primitives (such as points, lines, and triangles). The rendering pipeline contains multiple consecutive processing stages, each responsible for a specific data processing task and working in conjunction with adjacent stages to achieve a complete transformation from geometric primitives to pixel results.

[0035] Specifically, the rendering pipeline can be divided into a geometry processing section and a pixel processing section. The geometry processing section includes stages such as vertex input, vertex shading, primitive assembly, geometry shading, clipping, and screen mapping. It receives vertex data provided by the application and transforms, assembles, and processes it at the primitive level. Through these stages, the input geometric data is progressively converted into primitive data located in screen space.

[0036] Vertex input refers to passing vertex data from the application to the geometry pipeline. Vertex data includes attributes such as position, color, and normals. Vertex shading refers to calculating each input vertex using a vertex shader, which can perform various transformations and operations, such as model transformations, view transformations, and projection transformations. It can also calculate vertex lighting and texture coordinates. Primitive assembly refers to converting vertices into complete geometric primitives using a primitive assembler. Geometry shading refers to manipulating and generating geometric primitives using a geometry shader. This includes creating new primitives and changing their shape, size, and position. Clipping refers to comparing primitives with screen boundaries using a clipper and discarding portions outside the view frustum. Screen mapping refers to mapping clipped primitives to pixel coordinates in screen space.

[0037] Subsequently, the pixel processing section rasterizes the primitives output from the geometry stage to generate corresponding fragments. Then, in the fragment coloring and pixel operation stages, it performs pixel-level processing such as lighting, texture sampling, depth and stencil testing, and color mixing to determine the final display attributes of each pixel in the image.

[0038] Rasterization refers to converting geometric primitives into pixels on the screen and determining the position, color, and other attributes of each pixel. Fragment shading refers to performing calculations on each rasterized pixel using a fragment shader, which involves performing pixel-level lighting calculations, texture sampling, depth testing, and other operations. Pixel operations refer to performing final pixel processing, such as blending, dithering, and anti-aliasing.

[0039] The aforementioned stages rely on the parallel architecture of the graphics processing unit (GPU) to achieve efficient computation, enabling the rendering pipeline to process large amounts of graphics data in real-time rendering scenarios. Geometry processing and pixel processing together constitute the core workflow of GPU rendering, providing graphics applications with complete data processing and image generation capabilities.

[0040] refer to Figure 1 The diagram illustrates a system architecture diagram to which the shader merging method described in this disclosure can be applied.

[0041] like Figure 1 As shown, system architecture 100 may include one or more terminal devices such as smartphone 101, portable computer 102, and desktop computer 103, network 104, and server 105. Network 104 is used as a medium to provide a communication link between the terminal devices and server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0042] The terminal device may include a graphics processor or a processing component with graphics rendering capabilities for executing the shader merging method in the embodiments of this disclosure. Typically, the terminal device can locally acquire a first shader program and a second shader program, and generate a target shader program based on the first and second shader programs. Importantly, a shader merging barrier instruction can be inserted into the target shader program. This shader merging barrier instruction can prevent the execution of the second shader program before the first shader program has finished running, thereby establishing a clear execution order in the local graphics processing flow. The generated target shader program can be executed by the graphics processor of the terminal device.

[0043] Server 105 can be used for resource management or rendering task scheduling, providing shader source code, program templates or related configuration data to terminal devices. Accordingly, the terminal devices can execute shader merging methods based on resources obtained from the server or locally saved files.

[0044] In practical applications, the terminal device can provide a user interface for editing shader programs, allowing users to independently input, modify, or manage the contents of the first and second shader programs. After the user completes editing, the terminal device can trigger a corresponding merging process, enabling the user to adjust the organization of the shader logic as needed, without relying on external tools or automatic processing by the driver layer.

[0045] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, there can be any number of terminal devices, networks, and servers. For example, server 105 could be a server cluster composed of multiple servers.

[0046] This disclosure provides a shader merging method that allows users to combine multiple existing shader codes within a single program structure and adjust the merged shader logic according to actual needs, or write their own unified shader code for cross-stage processing. By organizing multiple shader processing segments in an explicit code manner, the segmented pipeline process dependent on the geometry processing stage can be reduced to some extent, making the graphics processing execution path more compact, thereby helping to improve the overall efficiency of the graphics processing process and reducing unnecessary resource consumption in the corresponding hardware execution environment.

[0047] refer to Figure 2 As shown, the shader merging method may include the following steps S210 to S230: Step S210: Obtain the first shader program and the second shader program; Step S220: According to the preset shading order, combine the first shader program and the second shader program into the target shader program to generate the first shading instruction and the second shading instruction. Step S230: Insert a merge shader barrier instruction between the first shading instruction and the second shading instruction. The merge shader barrier instruction is used to prevent the execution of the second shading instruction before the first shading instruction has been completed.

[0048] The shader merging method in this example embodiment will now be described in detail.

[0049] In step S210, the first shader program and the second shader program are obtained.

[0050] In the exemplary embodiments of this disclosure, the first shader program and the second shader program are typically used to represent shader code belonging to different processing stages in the graphics rendering pipeline; that is, the first shader program and the second shader program are shaders of different types. Optionally, the type of shader may include one or more of vertex shaders, geometry shaders, shell shaders, and domain shaders.

[0051] The vertex shader performs vertex-by-vertex processing on the input vertex data, typically including coordinate space transformation, normal vector calculation, and texture coordinate transformation, to generate vertex attribute data for subsequent geometry processing stages. The geometry shader receives geometric data provided by the preceding stages at the primitive level (e.g., points, lines, or triangles), and can generate new primitives or modify the structure, quantity, or attributes of input primitives, thereby achieving primitive-level geometric expansion or reconstruction. The shell shader performs shell evaluation on the input primitives in the subdivision surface processing flow. This stage calculates the shell factor for subdivision control based on shader logic to determine the density and distribution of subdivision operations, providing the domain shader with subdivided domain space coordinates. The domain shader performs point-by-point evaluation on the domain space coordinates generated by the shell shader, calculates the subdivided vertex positions and their related attributes according to subdivision rules, and outputs subdivided geometric data usable by subsequent geometry processing stages (e.g., the geometry shader).

[0052] In different rendering tasks, the pairing of the first and second shader programs can vary as needed. For example, the first shader program can be a vertex shader to process the input vertex data, while the second shader program can be a geometry shader, shell shader, or domain shader to perform further geometric processing operations based on the results of the first stage calculation. As another example, the first shader program can be a domain shader to evaluate the domain points generated by the shell shader and generate spatial coordinates on the surface during the subdivision surface pipeline, while the second shader program can be a geometry shader to generate new primitives, adjust primitive structures, or perform other geometric level extension processes based on the data provided in the previous stage.

[0053] Of course, the shader type is not limited to the listed types. It can also be other shader program types with independent processing stages in the graphics rendering pipeline, such as user-written custom shader code used to extend geometry processing capabilities. As long as the shader of this type can participate in the geometry processing flow and form a sequential execution relationship with other shaders after merging, it can be used as the first shader program and the second shader program in this disclosure. This disclosure does not limit this.

[0054] Considering that different types of shader programs have different responsibilities in the rendering pipeline, and their input formats, output formats and data dependencies also differ, it is necessary to obtain the two shader programs separately before performing the merging process so that they can be combined according to their structural characteristics and data requirements in subsequent steps.

[0055] In terms of specific acquisition methods, the first and second shader programs can be obtained through various means. For example, they can be read from the local storage space of the terminal device, such as vertex shader, domain shader, or geometry shader scripts pre-completed by the developer. Alternatively, they can be received from the user's real-time input or modification of shader code through the graphical editing interface provided by the terminal device, allowing the user to independently write or adjust the shader program to be merged according to actual rendering needs. Furthermore, in scenarios with a remote development environment, shader templates or pre-compiled shader files delivered by the project build environment can be obtained from the server side, and the terminal device can perform the corresponding merging process after loading these files.

[0056] By obtaining the first shader program and the second shader program, the basic input for the subsequent combination of the two into the target shader program is provided, enabling the merging logic to unfold on top of a defined shader structure.

[0057] It is understood that in practical applications, two or more shader programs can be combined into a target shader program, and the combination relationship between different shaders can be established sequentially in the manner of adjacent stages. Since the merging process of multiple shader programs can be regarded as a repetitive operation between several adjacent shader pairs, the embodiments of this disclosure use the merging process of two shader programs as an example to clearly demonstrate the merging principle, but this does not constitute a limitation on the number of shaders that can be merged.

[0058] In step S220, the first shader program and the second shader program are combined into the target shader program according to the preset shading order to generate the first shading instruction and the second shading instruction.

[0059] In the exemplary embodiments of this disclosure, the preset shading order can be determined based on the existing stage relationships of the graphics rendering pipeline. For example, the shader program that undertakes the preliminary geometry processing task is placed before the target shader program, and the shader program used for subsequent processing is placed after it. Currently, the preset shading order can also be adjusted by the user in the graphics editing interface, allowing the user to determine the order of the two shader programs according to actual rendering needs.

[0060] It is understandable that the first and second shader instructions are constructed based on the instruction segments in the first and second shader programs, respectively. Therefore, during the assembly process, the code structure in the first and second shader programs can be parsed to extract their respective instruction segments, variable declarations, and dependencies. While maintaining their original logical independence, their respective instruction segments can be sequentially integrated into the target shader program.

[0061] In this context, an instruction segment refers to a continuous code block within a shader program used to execute specific computational logic. A variable declaration is a statement within a shader program that defines, specifies the type of, or binds resources to variables that will be used. Dependencies reflect the logical relationships between different code segments, variables, or resources within a shader program.

[0062] For example, the instruction segment corresponding to the first shader program can be placed at the beginning of the target shader program to form the first shader instruction, and the instruction segment corresponding to the second shader program can be placed at the end of the target shader program to form the second shader instruction. In this way, the processing logic that originally belonged to two independent shader programs is integrated into two instruction units in the same program structure.

[0063] During the integration of instruction segments, semantic validation can be performed on the merged shader code, such as checking for variable naming conflicts, resource binding conflicts, or inconsistent data types, to ensure that the target shader program can correctly access input and intermediate data during execution. If necessary, auxiliary code structures for transferring data between the two instruction segments can also be automatically generated during composition, such as local variable declarations or intermediate storage areas.

[0064] It should be noted that when constructing the target shader program, the internal code structure of the first shader program and the second shader program may not be split. Instead, the first shader program and the second shader program may be introduced into the target shader program as a whole as the first shader instruction and the second shader instruction, respectively. This allows the first shader instruction and the second shader instruction to correspond to the complete shader program content, thereby achieving the sequential combination of cross-shading stage processing logic while keeping the original logical structure of each shader program unchanged.

[0065] Furthermore, this disclosure does not limit the construction method of the first shading instruction and the second shading instruction. Specifically, it can be selected according to the structural characteristics of the first shader program and the second shader program, implementation requirements or development environment, as long as the first shader program and the second shader program can be constructed as two shading instruction units in the target shader program.

[0066] This step merges the first and second shader programs from their original independent program files into a unified code structure, laying the foundation for setting merge boundaries and controlling the execution order of the two shader stages.

[0067] For example, the graphics processing rendering pipeline in this embodiment merges the traditionally separate vertex shader (VS), geometry shader (GS), hull shader (HS), and domain shader (DS), so that the processing logic that was originally scattered in multiple stages can be completed in fewer merging stages, thereby forming a new geometry processing mode.

[0068] For ease of explanation, Table 1 compares the geometric processing modes of the conventional rendering pipeline with the geometric processing modes supported by the embodiments of this disclosure.

[0069] Table 1 In Table 1, VGS mode represents merging VS and GS into a unified shader program, i.e., a vertex-geometry shader. In this mode, the processing logic related to vertex transformation and the geometric extension processing logic for primitives are integrated into the same shader and executed in a preset order, allowing operations that previously required two hardware stages to be completed in a single stage. VHS mode represents merging VS and HS, i.e., a vertex-shell shader. In this mode, the transformation processing of vertex data and the shell control point processing in the tessellation surface process are encapsulated in the same shader code structure and executed, thus completing the pre-processing for surface tessellation without the need for a separate HS stage. DGS mode represents merging DS and GS, i.e., a domain-geometry shader. In this mode, the domain point data generated by the domain shader can be directly accessed by the geometric processing logic within the same shader, achieving a direct connection from tessellation domain evaluation to geometric primitive generation, avoiding additional synchronization and data migration caused by cross-shader stages.

[0070] As shown in Table 1, the geometry processing flow in traditional rendering pipelines often requires multiple independent shader stages to work together, for example, up to four different types of shader stages, such as VS+HS+DS+GS. In contrast, by merging the shader programs in this embodiment, the originally scattered multi-stage geometry processing can be integrated into fewer merged stages, so that a single geometry processing can cover the processing capabilities of the original multiple stages with a maximum of only two shader stages. Furthermore, the specific merging method of the shaders can be flexibly configured according to application requirements, and this disclosure does not limit it in this regard.

[0071] By reducing the number of geometry processing stages, we can not only simplify the rendering pipeline structure, but also reduce pipeline overhead caused by stage switching, thus providing higher execution efficiency for subsequent rendering operations.

[0072] In step S230, a merge shader barrier instruction is inserted between the first shading instruction and the second shading instruction. The merge shader barrier instruction is used to prevent the execution of the second shading instruction before the first shading instruction has been completed.

[0073] In the exemplary implementation of this disclosure, the merge shader barrier instruction is used to define the execution boundary between two instruction segments within the target shader program. Specifically, when the first shader instruction reaches the barrier location, the graphics processor pauses the advancement of the subsequent execution path according to the semantics of the merge shader barrier instruction and checks the execution status of the shader thread corresponding to the first shader instruction. After a preset release condition is met, the barrier is released, and the second shader instruction can continue to execute.

[0074] The merge shader barrier instruction provides a barrier between the two merged shaders, preventing erroneous behavior caused by the first shader not yet completing its execution while the second shader is running. This control structure creates explicit sequential dependencies within the target shader program, ensuring stability when the second shader instruction accesses data generated by the first shader instruction.

[0075] In its implementation, the insertion operation parses the syntax structure of the target shader program and inserts the merge shader barrier instruction at the end of the code segment corresponding to the first shader instruction. It's understandable that the position of the merge shader barrier instruction in the target shader program can be automatically determined by the merge logic, or it can be inserted based on the merge boundary set by the user in the graphics editing interface. The existence of the merge shader barrier instruction allows the target shader program to clearly distinguish the lifecycles of the two instruction segments during execution, ensuring that the second shader instruction will only begin execution after the first shader instruction has completed all its computational tasks.

[0076] In addition, during the insertion of the merge shader barrier instruction, checks can be performed on constraints related to variable scope, intermediate data storage methods, and execution order to ensure that the second shader instruction can correctly access the data generated by the first shader instruction after the barrier is removed. For example, it can be confirmed that local variables or intermediate storage areas written by the first shader instruction remain visible after the merge shader barrier is removed, and that data access will not be abnormal due to scope conflicts or resource overwriting.

[0077] This step establishes explicit synchronization control between the two instruction segments within the target shader program, enabling subsequent execution phases to achieve stable connection across shading logic while maintaining the overall structure of the rendering pipeline.

[0078] In some example implementations, in order to ensure that the merge shader barrier instruction can play a correct synchronization role when it is executed, it is necessary to further determine the barrier range corresponding to the merge shader barrier instruction. The barrier range is used to define the scope of the merge shader barrier instruction, that is, to clarify the set of shader threads to which it plays a role and the applicable boundary of the synchronization constraint.

[0079] refer to Figure 3 As shown, the process of determining the barrier range corresponding to the merge shader barrier instruction may include the following steps S310 and S320: Step S310: Determine the maximum number of input vertices and the maximum number of input primitives used to execute the target shader program.

[0080] When merging shader code, it's necessary to determine the maximum number of input vertices and the maximum number of input primitives used to execute the target shader program. This helps the hardware allocate appropriate storage resources and scheduling capabilities to the program. The maximum number of input vertices represents the upper limit of the number of vertices that may participate in processing during a single execution of the target shader program. The maximum number of input primitives represents the upper limit of the number of primitives that may appear during the geometry processing phase.

[0081] The maximum number of input vertices and the maximum number of input primitives can be derived from the resource usage of the target shader program, or can be set by the user in the development environment through configuration. This disclosure does not limit these settings.

[0082] For example, the maximum number of input vertices and the maximum number of input primitives for executing the target shader program can be determined based on the first shader program and the second shader program.

[0083] For example, refer to Figure 4 As shown, the process of determining the maximum input size of the target shader program may include the following steps S410 and S420: Step S410: parse the input structure, output structure, and intermediate resources declared in the target shader program corresponding to the first shader program and the second shader program.

[0084] Step S420: Based on the input structure, output structure, and intermediate resources, and in conjunction with the resource constraints used to execute the target shader program, determine the maximum number of input vertices and the maximum number of input primitives.

[0085] The input structure can represent vertex or primitive attributes that the target shader program can receive. The output structure can represent the variables or data formats that the first and second shader instructions need to write. Intermediate resources may include data buffer structures in the target shader program used across instruction segments.

[0086] By analyzing these structures, the total amount of resources that the target shader program may use during runtime can be obtained. Furthermore, based on resource constraints such as storage space usage, thread scheduling limits, and local caching capabilities, the maximum number of input vertices and primitives required to execute the target shader program can be derived. The resulting maximum input scale ensures that the target shader program runs within the hardware's resource limits and provides a basis for setting subsequent barrier limits.

[0087] For example, the maximum number of input vertices and primitives used to execute the target shader program can be determined by setting the number of input vertices and primitives. For instance, the user can directly set the number of input vertices and primitives in the graphics editing interface to determine the maximum processing capacity of the target shader program. This disclosure does not limit the specific method of setting these parameters; the setting can be completed by inputting values, selecting preset options, or adjusting corresponding parameters in the graphics editing interface, as long as the number of input vertices and primitives used to execute the target shader program is clearly specified.

[0088] In other example implementations, the driver and compiler can automatically derive the appropriate maximum number of input vertices and the maximum number of input primitives based on the user-provided inputs, outputs, and intermediate resources. This approach avoids the uncertainty caused by manual configuration of the input scale by the user, making the generated input scale more consistent with the actual availability of hardware resources.

[0089] To facilitate developers obtaining the input scale calculated by the system after the merge shader program is built, a query interface can be provided, allowing users to read the maximum number of input vertices and the maximum number of input primitives determined by the driver. For example, a query can be performed using the following sample interface: int query_max_input_vertex(const void*combined_shader_code); int query_max_input_primitive(const void*combined_shader_code); The combined_shader_code is used to indicate the code object of the constructed merged shader program. The driver can use this to parse the input structure, output structure and intermediate resources contained in the target shader program, thereby returning the derived maximum input size.

[0090] Through the query interface, users can directly know the actual number of input vertices and input primitives used in the execution after the shader is merged, which can be used as a reference for debugging, performance analysis or resource optimization.

[0091] Step S320: Generate the barrier range corresponding to the merge shader barrier instruction based on the maximum number of input vertices and the maximum number of input primitives.

[0092] After determining the maximum number of input vertices and the maximum number of input primitives, a barrier range corresponding to the merge shader barrier instruction can be generated based on these two parameters. The barrier range defines the set of threads whose execution status needs to be checked at the barrier location. For example, in the execution of the target shader program, if an execution batch may involve M vertices and N primitives, the barrier range can be represented as the detection interval for the execution threads related to these M vertices and the execution threads related to these N primitives. When the merge shader barrier instruction is triggered, the graphics processor will check the execution status of the thread corresponding to the first shader instruction within this range.

[0093] It's important to emphasize that the merge shader barrier function only applies between specified vertices and primitives. For example, if the maximum number of input vertices is determined to be 64 and the maximum number of input primitives to be 128, then the merge shader barrier instruction will take effect in a scenario where 64 vertices might form 128 primitives. However, in a scenario with 63 vertices and 128 primitives, the merge shader barrier instruction will not take effect; in other words, the merge shader barrier instruction will not cross between two different scenarios.

[0094] In the exemplary embodiments of this disclosure, the merge shader barrier instruction is also used to automatically invalidate after the first shading instruction within the barrier range has been executed. For example, during the execution of the merge shader program, when the graphics processor reaches the merge shader barrier instruction location, it needs to determine, based on the pre-determined barrier range, whether all threads corresponding to the first shading instruction have been executed. If the detection result indicates that there are still threads executing within the barrier range, the merge shader barrier instruction continues to execute. Only when it is confirmed that all threads of the first shading instruction have finished, and the merge shader barrier instruction automatically invalidates, is it allowed to continue executing the second shading instruction.

[0095] Specifically, when the target shader program reaches the location of the merge shader barrier instruction, the graphics processor checks the execution status of each shader thread corresponding to the first shader instruction within the determined barrier range. The execution status can include information such as whether the thread has exited and whether it has written to its assigned intermediate output, used to determine whether the thread has completed its corresponding processing task.

[0096] Once it is detected that all threads corresponding to the first shading instructions within the barrier area have completed execution, the merge shader barrier instruction automatically becomes invalid. If the detection result indicates that there are still threads that have not yet exited, the graphics processor will remain in a waiting state at the barrier, periodically checking the thread execution status until all threads have completed.

[0097] This example establishes a synchronization mechanism within the target shader program that matches the input size, ensuring that the timing of the release of the merge shader barrier instruction accurately corresponds to the overall execution progress of the first shader instruction. This guarantees that when the second shader instruction accesses data generated by the first shader instruction, all data is ready, avoiding incomplete data reading or access conflicts caused by inconsistent thread execution progress, thus ensuring the processing stability of the target shader program in a multi-stage architecture.

[0098] After the merge shader barrier instruction automatically expires, the target shader program continues to execute the second shader instruction. Since the first shader instruction had completed the execution of all threads before the barrier was removed, the corresponding intermediate data was already in an accessible and stable state. Therefore, the second shader instruction can directly read the intermediate data generated by the first shader instruction during its execution.

[0099] Specifically, during the execution phase of the second shading instruction, the graphics processor can load the intermediate data written by the first shading instruction based on the variable binding relationships, cache layout, or intermediate resource declarations defined in the target shader program, and perform further geometric processing, primitive generation, or attribute calculations on this basis. For example, the second shading instruction can rely on vertex positions, normals, subdivided domain point information, or other phased calculation results generated in the first phase, and execute subsequent logic based on the above data, thereby forming a continuous processing flow across phases.

[0100] Because the execution of the second shader instruction is based on the data state confirmed by the merge shader barrier instruction, the intermediate data it accesses is semantically consistent and complete. This avoids problems such as data tearing and uninitialized reads that may occur due to inconsistent thread progress in a parallel environment. In this way, the target shader program can achieve data transfer and scheduling control between multiple stages without modifying the hardware pipeline, enabling different shader processes to be sequentially connected and run stably in a single program structure.

[0101] refer to Figure 5 The diagram illustrates a schematic representation of a graphics processing rendering pipeline employing a shader merging method according to an embodiment of this disclosure. Figure 5As can be seen, in the graphics processing rendering pipeline, the input data is first processed by the input assembly stage. This stage is responsible for receiving vertex buffers, index buffers, and related attribute data from the application and assembling them into primitives to be processed. After the input processing is completed, the rendering pipeline selects different geometry processing paths according to the shader mode specified by the user.

[0102] When the user selects VS mode, the geometry pipeline only executes the vertex shader, which performs basic processing such as position transformation and attribute calculation for each input vertex. If shader merging is supported, the user can also choose to execute the merged VGS (Vertex-Geometry Shader). In this mode, the processing logic originally belonging to the vertex shading and geometry shading stages is integrated into the target shader program, enabling the merged program to complete joint vertex-level and primitive-level operations in a single stage.

[0103] In some rendering tasks, if the graphics processing flow involves surface tessellation, a merged VHS (Vertex-Shell Shader) can be executed. The output of the VHS is passed to the tessellation shader, which subdivides the primitives based on the tessellation factor output by the shell shader. After the tessellation process is complete, the rendering pipeline can further choose to execute DS to calculate the domain points generated after tessellation, or choose to execute a merged DGS (Domain-Geometry Shader) to directly perform geometric level addition or generation operations after the domain point evaluation, so that the calculation logic of the tessellation stage and the geometry stage is completed continuously in a single shader.

[0104] Regardless of whether VS, VGS, DS, or DGS is selected, the output will be sent to the rasterization stage. Rasterization is responsible for converting primitives into fragments and determining the pixel regions to be processed based on screen space coordinates. After the fragments are generated, they will further enter the pixel shader stage for pixel-level lighting calculations, texture sampling, and attribute output. Finally, the pixel shader results undergo depth testing, blending, and other necessary final processing in the output merging stage to form the output frame of the rendering pipeline.

[0105] pass Figure 5 As shown in the diagram, the graphics processing rendering pipeline can flexibly organize the execution structure of the geometry stage according to the shader mode selected by the user, thereby supporting the combination of multiple shader programs into a merged shader and running it in the pipeline.

[0106] In addition to automatically merging user-mode shaders based on existing shader programs, this disclosure also allows users to directly write merged shader programs. Users with some shader development experience can implement the corresponding processing logic themselves, following the structure of the merged shader, without relying on existing staged shaders.

[0107] In these merge shaders, the program code typically consists of two main parts: a front-end that processes input vertex, domain, or patch-level data, and a back-end that executes primitive-level processing logic. These two parts are isolated by merge shader barrier instructions to ensure that the back-end processing is executed only after the front-end data has been fully generated.

[0108] Furthermore, the merge shader can indicate the maximum input size it may process in a single execution through parameters such as max_input_vertex and max_input_primitive, providing a basis for hardware resource allocation.

[0109] For example, the sample code for writing a VGS merge shader is as follows: [max_input_vertex=M,max_input_primitive=N] VGS_Output vgs_main() { / / Per Vertex process part combined_shader_barrier(); / / Per primitive process part } Here, `max_input_vertex=M` and `max_input_primitive=N` are used to declare the maximum input size that the merged shader may process in a single execution. `VGS_Output vgs_main()` defines the entry function of the merged shader. ` / / Per Vertex process part` indicates that the following instruction segment belongs to the vertex-level processing part. `combined_shader_barrier()` is the shader barrier function used to establish a synchronization point between two processing segments. ` / / Per primitive process part` indicates that the processing logic after the merged shader barrier instruction belongs to the primitive-level computation stage.

[0110] For a rendering workflow involving subdivision processing, the following is sample code for writing a VHS merge shader: [max_input_vertex=M,max_input_primitive=N] VHS_Output vhs_main() { / / Per Vertex process part combined_shader_barrier(); / / Per primitive / patch process part } Similarly, for scenarios combining domain shaders and geometry shaders, the following is sample code for writing a DGS merge shader: [max_input_vertex=M,max_input_primitive=N] DGS_Output dgs_main() { / / Per Domain point process part combined_shader_barrier(); / / Per primitive process part } It should be noted that the code structure of the VHS and DGS merge shaders is consistent with the VGS example in terms of merging method, barrier setting logic, and processing segment division. The only difference is the specific calculation content of the respective stages. Therefore, the code structure of the latter two will not be described again.

[0111] In some example implementations, dynamic adjustments to the merged shader program are also supported to accommodate code modifications that may occur during development. Specifically, in response to edit operations on the first and / or second shader programs, the first and / or second shader programs are updated, and the target shader program is updated based on the updated first and / or second shader programs.

[0112] In practical applications, users can modify shader code through the shader editing interface provided by the terminal device, such as adding new variable declarations, adjusting data processing logic, modifying input / output structures, or supplementing specific graphics processing statements. When such editing operations are detected, the edited first and / or second shader programs can be reloaded, and their instruction segments, variable binding information, and resource usage can be parsed to identify the content that needs to be updated during the merging process.

[0113] Based on the updated shader program, the target shader program can be rebuilt, including regenerating the corresponding first and second shader instructions, verifying variable dependencies, updating intermediate resource declarations, and maintaining or reinserting merge shader barrier instructions as needed. This ensures that the target shader program always remains consistent with the latest shading logic and that the merged structure does not become invalid due to changes in the underlying code.

[0114] Based on this, users can flexibly adjust the shader programs used for merging during development without manually reorganizing the overall structure after merging. Correspondingly, the target shader program can be automatically updated as user input changes, making the shader merging process more aligned with actual graphics development workflows.

[0115] refer to Figure 6 The diagram illustrates the principle of executing a merge shader, where: Step S610: Execute the first shader segment in the merge shader.

[0116] In this step, the graphics processor, based on the compilation results of the target shader program, performs operations on the first segment of processing logic in the merge shader, which is located before the merge shader barrier instruction. This first segment of the shader typically corresponds to the instruction segment in the original first shader program and is used to complete the basic processing at the vertex, domain, or other shading stages. As hardware thread scheduling progresses, multiple instances of the first segment of the shader can run in parallel to process the input data independently.

[0117] Step S620: Execute the barrier function.

[0118] When the execution flow reaches the merge shader barrier instruction in the target shader program, the graphics processor enters the barrier detection phase. At this time, the merge shader barrier instruction acts as a synchronization point to prevent the execution of the subsequent second shader segment, and at the same time triggers a check process on the execution status of the first shader segment to determine whether it has completed all processing tasks corresponding to the barrier range.

[0119] Step S630: Determine whether the barrier requirements are met.

[0120] In this step, it is confirmed whether all execution threads corresponding to the first segment shader have completed based on the predefined barrier range (such as the maximum number of input vertices and the maximum number of input primitives). If any threads are still detected as not having finished, the barrier remains in an unresolved state, and the graphics processor continues to execute step S620 to perform a status check until all threads have completed. If it is determined that the first segment shader has been fully executed within the barrier range, the barrier requirement is considered to have been met, and step S640 can be continued.

[0121] Step S640: Execute the second segment shader in the merge shader.

[0122] After satisfying the barrier requirements and removing the merge shader barrier instruction, the graphics processor continues to execute the second shader segment in the target shader, which follows the merge shader barrier instruction. The second shader segment corresponds to the instruction segment in the original second shader program and can perform subsequent geometric processing, primitive generation, or other staged operations based on the intermediate data generated by the first shader segment to achieve cross-stage joint processing logic.

[0123] pass Figure 6 The process shown allows the target shader program to establish clear stage boundaries during execution, enabling the first and second stage shaders to run sequentially within a single program structure. It also ensures that the first stage processing is completed before the second stage shader accesses the data generated by the first stage shader, thus improving the determinism and reliability of cross-stage data interaction.

[0124] In the exemplary implementation of this disclosure, the execution of the geometry processing stage is further optimized by introducing a merge shader barrier. The presence of the barrier enables the hardware to accurately distinguish between the preceding and following processing logic in the merge shader, thereby allowing certain functions used only in the second shader code to be processed in parallel with the execution of the first segment without breaking data dependencies.

[0125] refer to Figure 7 The diagram illustrates the execution of the geometry processing phase after the introduction of the merge shader barrier feature. In a traditional rendering pipeline, the geometry phase is typically executed sequentially in a strict order: primitive assembly → vertex shading → geometry shading. That is, vertex shading cannot begin until all primitive assembly is complete, and geometry shading cannot begin until all vertex shading is finished. While this fixed order ensures the inter-phase dependencies, it also prevents primitive assembly and vertex shading from overlapping, increasing overall processing latency.

[0126] By adopting the merge shader disclosed herein, the user merges the vertex shader and geometry shader into a single target shader program, whose code structure contains a first segment of vertex processing and a second segment of geometry processing, separated by a merge shader barrier. This structure allows the hardware to directly identify the preconditions required for each segment of processing, thereby enabling more flexible scheduling of the execution flow.

[0127] like Figure 7 As shown, after the input data enters the rendering pipeline, it is simultaneously distributed in two directions: one part enters the primitive assembly unit to construct primitives; the other part is directly sent to the merge shader to perform the first stage of vertex shading processing. Since the first stage of processing usually does not depend on the result of primitive assembly, the two types of operations can be carried out in parallel at the hardware level.

[0128] When the merge shader reaches the barrier, it performs a synchronization check according to the barrier definition: firstly, it confirms whether all threads corresponding to the first stage of processing have finished; secondly, it confirms whether primitive assembly has been completed. When both conditions are met, the barrier is removed, and the second stage of geometry processing logic begins, reading the prepared primitive data from the primitive assembly unit. If either condition is not met, it waits at the barrier until it is safe to proceed to the next stage.

[0129] In this way, the originally sequential primitive assembly and the first stage of coloring are executed concurrently, thereby reducing the waiting time between stages, improving the overall parallelism and data flow efficiency of the geometry processing path, and ultimately enhancing the system's throughput. For merged modes involving subdivision processing (such as VHS and DGS), the same optimization mode can be adopted based on the dependencies between the two processing stages, allowing the data required for the second processing stage to be prepared in advance during the execution of the first stage, which is beneficial to further improve the utilization of hardware resources.

[0130] In summary, this disclosure introduces shader merging capabilities in user space, freeing the organization of shading stages from the fixed flow of the driver. Developers can adjust the shading logic on the application side as needed and determine the execution relationships between different stages themselves. This mechanism can be used not only for merging vertex-geometry or vertex-shell stages, but also to cover more complex rendering paths including tessellation, making the merging method applicable to various types of graphics processing tasks.

[0131] Furthermore, this disclosure provides the ability to automatically generate merged shaders based on existing shader source code, constructing corresponding merged versions based on existing vertex, geometry, shell, and domain shaders. The generated code can still be modified or extended, allowing users to adjust specific processing logic according to project needs. In this way, merged shaders can be more easily integrated into actual development processes, improving the efficiency of shader debugging and building, and giving the overall solution better scalability and adaptability in different application scenarios.

[0132] In an exemplary embodiment of this disclosure, a shader merging apparatus is also provided. (See reference...) Figure 9 As shown, the shader merging apparatus 800 includes a shader acquisition module 810, a shader merging module 820, and a shader barrier module 830, wherein: Shader acquisition module 810 is used to acquire the first shader program and the second shader program; The shader merging module 820 is used to combine the first shader program and the second shader program into the target shader program according to a preset shading order, and generate the first shading instruction and the second shading instruction. The shader barrier module 830 is used to insert a merge shader barrier instruction between the first shader instruction and the second shader instruction. The merge shader barrier instruction is used to prevent the execution of the second shader instruction before the first shader instruction has been completed.

[0133] In an optional embodiment, the shader merging apparatus 800 further includes a barrier range determination module, and the barrier instruction release module includes: The maximum size determination submodule is used to determine the maximum number of input vertices and the maximum number of input primitives for executing the target shader program; The barrier range determination module is used to generate a barrier range corresponding to the merge shader barrier instruction based on the maximum number of input vertices and the maximum number of input primitives. The barrier range is used to define the scope of the merge shader barrier instruction. The merge shader barrier instruction is also used to automatically become invalid after the first shader instruction within the barrier range has been executed.

[0134] In one alternative implementation, the maximum scale determination submodule includes: The first scale determination unit is used to determine the maximum number of input vertices and the maximum number of input primitives for executing the target shader program based on the first shader program and the second shader program.

[0135] In one optional implementation, the first scale determination unit includes: The program parsing unit is used to parse the input structure, output structure, and intermediate resources declared in the target shader program corresponding to the first shader program and the second shader program. The scale determination unit is used to determine the maximum number of input vertices and the maximum number of input primitives based on the input structure, output structure, and intermediate resources, combined with the resource constraints used to execute the target shader program.

[0136] In one alternative implementation, the maximum scale determination submodule includes: The second scale determination unit is used to determine the maximum number of input vertices and the maximum number of input primitives for executing the target shader program based on the setting operations for the number of input vertices and the number of input primitives.

[0137] In an optional implementation, the shader merging apparatus 800 further includes a target shader update module configured to update the first shader program and / or the second shader program in response to an edit operation on the first shader program and / or the second shader program, and update the target shader program based on the updated first shader program and / or the second shader program.

[0138] In one alternative implementation, the first shader program and the second shader program are shaders of different types, including one or more of vertex shaders, geometry shaders, shell shaders, and domain shaders.

[0139] The specific details of each module in the aforementioned shader merging apparatus have been described in detail in the corresponding shader merging methods, so they will not be repeated here.

[0140] Exemplary embodiments of this disclosure also provide a computer-readable storage medium having a program product stored thereon capable of implementing the methods described above in this specification. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when run on an electronic device, causes the electronic device to perform the steps described in the "Exemplary Methods" section of this specification according to the various exemplary embodiments of this disclosure. This program product may be a portable compact disc read-only memory (CD-ROM) including program code and may run on an electronic device, such as a personal computer. However, the program product of this disclosure is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0141] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0142] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0143] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0144] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C#, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0145] Exemplary embodiments of this disclosure also provide an electronic device capable of implementing the above-described method. Referring below... Figure 9 To describe an electronic device 900 according to such an exemplary embodiment of the present disclosure. Figure 9 The electronic device 900 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0146] like Figure 9 As shown, the electronic device 900 can be represented as a general-purpose computing device. The components of the electronic device 900 may include, but are not limited to: at least one graphics processor 910, at least one storage unit 920, a bus 930 connecting different system components (including the storage unit 920 and the graphics processor 910), and a display unit 940.

[0147] The storage unit 920 stores program code that can be executed by the graphics processor 910, causing the graphics processor 910 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the graphics processor 910 can execute... Figures 2 to 4 The methods and steps in the text.

[0148] Storage unit 920 may include readable media in the form of volatile storage units, such as random access memory (RAM) 921 and / or cache memory (Cache) 922, and may further include read-only memory (ROM) 923.

[0149] Storage unit 920 may also include a program / utility 924 having a set (at least one) program module 925, such program module 925 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0150] Bus 930 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a graphics processor, or a local bus using any of the various bus structures.

[0151] Electronic device 900 can also communicate with one or more external devices 970 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 900, and / or with any device that enables electronic device 900 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 950. Furthermore, electronic device 900 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 960. As shown, network adapter 960 communicates with other modules of electronic device 900 via bus 930. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 900, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0152] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the method according to the exemplary embodiments of this disclosure.

[0153] Furthermore, the above figures are merely illustrative representations of the processes included in the methods according to exemplary embodiments of this disclosure, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0154] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0155] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0156] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A shader merging method, characterized in that, include: Obtain the first shader program and the second shader program; According to the preset shading order, the first shader program and the second shader program are combined into the target shader program to generate the first shading instruction and the second shading instruction; Insert a merge shader barrier instruction between the first shader instruction and the second shader instruction; The merge shader barrier instruction is used to prevent the execution of the second shader instruction before the first shader instruction has been completed.

2. The shader merging method according to claim 1, characterized in that, The method further includes: Determine the maximum number of input vertices and the maximum number of input primitives used to execute the target shader program; Based on the maximum number of input vertices and the maximum number of input primitives, a barrier range corresponding to the merge shader barrier instruction is generated; the barrier range is used to define the scope of the merge shader barrier instruction; the merge shader barrier instruction is also used to automatically expire after the first shader instruction within the barrier range has been executed.

3. The shader merging method according to claim 2, characterized in that, Determining the maximum number of input vertices and the maximum number of input primitives used to execute the target shader program includes: Based on the first shader program and the second shader program, determine the maximum number of input vertices and the maximum number of input primitives for executing the target shader program.

4. The shader merging method according to claim 3, characterized in that, The step of determining the maximum number of input vertices and the maximum number of input primitives for executing the target shader program based on the first shader program and the second shader program includes: The input structure, output structure, and intermediate resources declared in the target shader program are parsed for the first shader program and the second shader program. Based on the input structure, the output structure, and the intermediate resources, and in conjunction with the resource constraints for executing the target shader program, the maximum number of input vertices and the maximum number of input primitives are determined.

5. The shader merging method according to claim 2, characterized in that, Determining the maximum number of input vertices and the maximum number of input primitives used to execute the target shader program includes: Receive setting operations for the number of input vertices and the number of input primitives, and determine the maximum number of input vertices and the maximum number of input primitives for executing the target shader program based on the setting operations.

6. The shader merging method according to claim 1, characterized in that, The method further includes: In response to an edit operation on the first shader program and / or the second shader program, the first shader program and / or the second shader program are updated; The target shader program is updated based on the updated first shader program and / or the updated second shader program.

7. The shader merging method according to claim 1, characterized in that, The first shader program and the second shader program are shaders of different types, and the types of shaders include one or more of vertex shaders, geometry shaders, shell shaders and domain shaders.

8. A shader merging apparatus, characterized in that, include: The shader acquisition module is used to acquire the first shader program and the second shader program; The shader merging module is used to combine the first shader program and the second shader program into the target shader program according to a preset shading order, thereby generating the first shading instruction and the second shading instruction. A shader barrier module is used to insert a merge shader barrier instruction between the first shader instruction and the second shader instruction; The merge shader barrier instruction is used to prevent the execution of the second shader instruction before the first shader instruction has been completed.

9. An electronic device, characterized in that, include: Graphics processor; as well as A storage unit for storing the executable instructions of the graphics processor; The graphics processor is configured to execute the shader merging method of any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the graphics processor, it implements the shader merging method according to any one of claims 1 to 7.

Images