Rendering method, chip, device and rendering system

Abstract

The invention discloses a rendering method, a chip, equipment and a rendering system, and relates to the technical field of image rendering. The rendering system comprises a grating device, a fragment shader constructor, an interpolator and a fragment shader, the rendering method comprises the following steps: a rasterer sends first information to an interpolator and sends second information to a fragment shader constructor; the interpolator obtains first attribute data according to the first information and executes interpolation calculation based on the first attribute data to generate second attribute data; the fragment shader constructor generates a shader thread task based on the second information, and the shader thread task is used for coloring the target fragment; and the fragment shader executes a shader thread task based on the second attribute data, and generates a colored target fragment. According to the method, the graphic rendering efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of graphics rendering technology, and in particular to a rendering method, chip, device, and rendering system. Background Technology

[0002] In the graphics processing unit (GPU) rendering architecture, the graphics rendering pipeline includes the geometry processing pipeline and the fragment processing pipeline. The fragment processing pipeline is responsible for shading the primitives generated by the geometry processing pipeline.

[0003] In related technologies, the rasterizer in the fragment processing pipeline sends the rasterized primitives to the shader constructor. The shader constructor obtains the vertex attribute data of the primitives and generates a shader thread task, then sends the vertex attribute data to the interpolator to perform interpolation. Afterward, the fragment shader performs shading processing based on the shader thread task and the interpolation results.

[0004] However, the efficiency of graphics rendering is reduced because the process of acquiring vertex attribute data and generating shader thread tasks takes a lot of time. Summary of the Invention

[0005] This application provides a rendering method, chip, device, and rendering system. The technical solutions provided by this application include the following.

[0006] According to one aspect of the embodiments of this application, a rendering method is provided for use in a rendering system, the rendering system comprising: a rasterizer, a fragment shader constructor, an interpolator, and a fragment shader; The method includes: The rasterizer sends first information to the interpolator and second information to the fragment shader constructor; wherein, the first information is used to indicate first attribute data, the first attribute data is used to indicate the vertex attributes of the target primitive; the second information is used to indicate the positional distribution of the target fragments in the target primitive, the target fragments being multiple fragments generated after the target primitive is rasterized; The interpolator obtains the first attribute data based on the first information, and performs interpolation calculation based on the first attribute data to generate second attribute data; wherein, the second attribute data is fragment attribute data obtained after performing the interpolation calculation on the first attribute data; The fragment shader constructor generates a shader thread task based on the second information, and the shader thread task is used to shade the target fragment. The fragment shader executes the shader thread task based on the second attribute data to generate the shaded target fragment.

[0007] According to one aspect of the embodiments of this application, a rendering system is provided, the rendering system comprising: a rasterizer, a fragment shader constructor, an interpolator, and a fragment shader; The rasterizer is used to send first information to the interpolator and second information to the fragment shader constructor; wherein, the first information is used to indicate first attribute data, the first attribute data is used to indicate the vertex attributes of the target primitive; the second information is used to indicate the positional distribution of the target fragment in the target primitive, the target fragment being multiple fragments generated after the target primitive is rasterized; The interpolator is used to obtain the first attribute data according to the first information, and perform interpolation calculation based on the first attribute data to generate second attribute data; wherein, the second attribute data is fragment attribute data obtained after performing the interpolation calculation on the first attribute data; The fragment shader constructor is used to generate a shader thread task based on the second information, and the shader thread task is used to shade the target fragment. The fragment shader is used to execute the shader thread task based on the second attribute data to generate the shaded target fragment.

[0008] According to one aspect of the embodiments of this application, a GPU chip is provided, the GPU chip including the rendering system described above.

[0009] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device including a GPU chip, the GPU chip including the rendering system described above.

[0010] The technical solutions provided in this application embodiment may include the following beneficial effects.

[0011] The technical solution proposed in this application sends first and second information to the interpolator and fragment shader constructor respectively via a rasterizer, thereby initiating two parallel processing flows. On one hand, upon receiving the first information, the interpolator immediately obtains the first attribute data based on the first information and performs interpolation calculations to generate the second attribute data. On the other hand, upon receiving the second information, the fragment shader constructor can simultaneously begin generating a shader thread task for shading the target fragment based on the second information. Finally, the fragment shader executes the shader thread task based on the second attribute data to generate the shaded target fragment. This technical solution parallelizes the time-consuming processes of obtaining vertex attributes and generating shader thread tasks, shortening the waiting time before the fragment shader executes the shader thread task and improving the efficiency of graphics rendering. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a graphics rendering process provided in one possible implementation of related technologies; Figure 2 This is a schematic diagram of a rendering system provided in one possible implementation of related technologies; Figure 3 This is a schematic diagram of a rendering method provided in one possible implementation of this application; Figure 4 This is a schematic diagram of the first attribute table and the second attribute table provided in one possible implementation of this application; Figure 5 This is a schematic diagram of a rendering system provided in one possible implementation of this application; Figure 6 This is a simplified structural block diagram of an electronic device provided in one possible implementation of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0015] The chips and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of chips and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0016] The technical solutions of this application can be applied to various chips, such as graphics processing units (GPUs), central processing units (CPUs), artificial intelligence accelerators (AIAs), tensor processing units (TPUs), neural processing units (NPUs), digital signal processors (DSPs), or other chips. Typically, the chip in this application embodiment can be a GPU, or a chip with the same or similar functions as a GPU.

[0017] Before introducing the technical solution proposed in this application, the relevant technologies will be briefly described below.

[0018] In the graphics rendering pipeline, graphics data input to the GPU by software through the Application Programming Interface (API) is processed sequentially through the Geometry Pipeline and the Fragment Pipeline before the final result is displayed on the screen. Depending on the rendering architecture, graphics rendering can be mainly divided into two types: Immediate Mode Rendering (IMR) architecture and Tile-Based Rendering (TBR) architecture.

[0019] For example, please refer to Figure 1 , Figure 1 This is a schematic diagram of a possible implementation of the related technology, providing a graphics rendering process.

[0020] Step 110: Geometry Processing. The geometry pipeline performs vertex-level processing on the input primitives, including coordinate transformation and clipping, and then sends the processed primitives to the fragment pipeline for rendering.

[0021] Step 120: Tiling. Following the geometry pipeline, the system under the TBR architecture performs a tiling operation. The system divides the entire screen into multiple tiles and assigns primitives from the geometry pipeline to the corresponding tile lists based on their coverage. Subsequently, the fragment pipeline can process each tile independently; the fragment pipeline can correspond to multiple processing hardware, thereby processing different tiles in parallel to improve rendering efficiency.

[0022] Step 130: Rasterization. In the fragment processing stage for each tile, rasterization is performed first. Rasterization converts each primitive into a series of fragments that it covers.

[0023] Step 140: Early Depth Testing / Hidden Face Removal. After rasterization, early depth testing / hidden face removal is performed. This step uses depth information to preemptively remove invisible fragments that will eventually be occluded by other primitives, thereby reducing the number of fragments that need to be processed subsequently and improving rendering performance.

[0024] Step 150: Interpolation. After rasterization and early depth testing / hidden face removal, the interpolation stage begins. The interpolator receives the information of the fragments that have not been culled and their associated metadata. It then calculates and assigns the attribute data originally defined at the vertices of the fragments to each fragment based on the fragment's specific position within the primitive. This attribute assignment process can be implemented using two techniques: 1. Planar equation form: The interpolator pre-calculates a planar equation in screen space for each attribute that needs interpolation. The attribute value of any fragment is directly obtained by substituting its screen coordinates into the corresponding planar equation; 2. Direct sampling value form: The interpolator directly obtains the calculated attribute value at the fragment center or a specific multisampling point.

[0025] Step 160: Fragment Shading. The complete attribute data of each fragment output from the attribute interpolation stage enters the fragment shading stage. The fragment shader receives this attribute data after attribute interpolation and performs complex calculations to finally calculate the final color value of each fragment.

[0026] Step 170: Blend / Write. The final stage of the process involves a blend / write operation. The corresponding module receives fragment color data from fragment shading, blends the newly generated fragment color with the corresponding pixel color already existing in the frame buffer, and then writes the final blended color result back to the frame buffer. Once all necessary fragments in a frame have completed this process, the data in the frame buffer is output to the screen, completing the entire graphics rendering process.

[0027] Among related technologies, the following solutions exist for attribute interpolation in graphics rendering.

[0028] For example, please refer to Figure 2 , Figure 2 This is a schematic diagram of a rendering system provided in one possible implementation of the related technology.

[0029] The rasterizer 510 first converts primitives into multiple fragments and outputs the position information and vertex attribute data of the primitives to the fragment shader constructor 520. The fragment shader constructor 520 needs to complete two key steps sequentially: First, it allocates resources based on the fragment information, generates shader thread tasks, and sends them to the thread task scheduler 560; second, it sends the aforementioned vertex attributes and related information to the interpolator 530. Upon receiving the data, the interpolator 530 performs interpolation calculations to generate specific fragment attribute data for each fragment. Subsequently, the thread task scheduler 560 schedules the shader thread tasks to the computation unit of the fragment shader 540 for execution. The fragment shader 540 then uses the fragment attribute data sent by the interpolator 530 to perform these tasks, completing the shading of the fragments. Finally, the shading result is sent to the blending / writing unit 570 for processing.

[0030] It can be seen that the relevant technology employs a serial processing mode. Specifically, in this mode, since the fragment shader constructor obtains primitive information from the rasterizer, the acquisition of vertex attribute data occurs in the preceding module of the fragment shader constructor. The fragment shader constructor must first acquire all vertex attribute data before it can begin generating the shader thread task, and finally hand over the vertex attribute data to the interpolator for interpolation. The above process of "acquiring attributes → constructing tasks → performing interpolation" is executed sequentially.

[0031] The aforementioned serial processing mode has the following problems: First, since the amount of vertex attribute data can be very large, the process of retrieving it sequentially from its storage location is itself a time-consuming operation; second, the generation of shader thread tasks is also a time-consuming process involving resource allocation and management. The superposition of these two consecutive and time-consuming steps prolongs the overall processing delay from the completion of rasterization to the start of fragment shading, reducing the efficiency of graphics rendering.

[0032] To address the aforementioned problems, this application provides a rendering method applied in a rendering system. For example, please refer to... Figure 3 , Figure 3 This is a flowchart of a rendering method applied to a rendering system, provided in one possible implementation of this application. The method may include at least one of the following steps.

[0033] In step 310, the rasterizer sends first information to the interpolator and second information to the fragment shader constructor. The first information indicates first attribute data, which in turn indicates the vertex attributes of the target primitive; the second information describes the positional distribution of the target fragments within the target primitive, where the target fragments are multiple fragments generated after rasterization of the target primitive.

[0034] In some embodiments, the rasterizer is a module in the graphics rendering pipeline that follows the geometry processing stage. Its primary function is to rasterize primitives, that is, to transform and clip the geometric primitives to be processed, defined by the connections between vertices (such as triangles), into a series of discrete fragments corresponding to the screen pixel grid. Specifically, the transformation process determines the pixel area covered by the primitive based on its vertex coordinates and generates a fragment for each covered pixel. These fragments represent the pixel area covered by the primitive and are the basic units for subsequent shading calculations. They typically contain information such as screen space coordinates, depth values, and the index of the primitive.

[0035] In some embodiments, the data received by the rasterizer may include: 1. Vertex geometric coordinate information: The rasterizer receives the fully transformed vertex coordinates, which are typically located in normalized device coordinate space or screen space. These coordinates are the sole geometric basis for the rasterizer to perform coverage testing and depth value interpolation. Specifically, the rasterizer uses these coordinates to calculate the bounding box, edge equations, and barycentric coordinates of each pixel of the primitives, but does not receive or process any vertex attribute data (i.e., first attribute data); 2. Primitive topology and connectivity: The rasterizer receives explicit primitive assembly instructions, including primitive types (such as triangles, line segments, points) and vertex connection order. This information determines how to interpret the vertex sequence to form the basic geometric units to be rasterized and is a prerequisite for correctly generating fragment sets; 3. Primitive identification information: Each primitive is accompanied by a unique identifier, such as a system-generated primitive index or a primitive identifier (ID) provided by the application. This identifier does not contain geometric or attribute data, but serves as a key query basis for subsequent shading stages (especially the interpolator) to backtrack and obtain the corresponding vertex attributes; 4. Pipeline state configuration reference: The rasterizer receives a lightweight reference pointing to the currently effective rendering state, including configuration parameters for rasterization rules such as depth testing, stencil testing, and multisampling. These configurations exist in the form of indexes, and the rasterizer applies these rules by querying independent configuration register sets without receiving the complete configuration data itself. It is worth noting that in this embodiment, the rasterizer does not receive vertex attribute data (such as color, normals, texture coordinates, etc.).

[0036] In some embodiments, the first information is used to indicate the first attribute data, which in turn indicates the vertex attributes of the target primitive. For example, a primitive is a basic geometric unit that constitutes a graphic, typically including points, lines, triangles, etc. The aforementioned target primitive is the geometric unit (most commonly a triangle) currently being rasterized and prepared to generate fragments. Vertex attributes define various feature data for each vertex of the aforementioned target primitive. These attributes are the basis for subsequent shading and rendering. For example, common vertex attributes may include: position attributes: the coordinates of the vertex in model space, world space, or clip space. This is the most core and essential attribute; normal attributes: the normal vector of the vertex, used to calculate lighting and determine the brightness and three-dimensionality of the model surface; texture coordinate attributes: the coordinates of the vertex on the texture map, used to correctly "attach" the two-dimensional texture to the three-dimensional model surface; color attributes: the diffuse or specular color of the vertex, used to define the model's own color; tangent and bitangent attributes: used to perform complex lighting calculations in conjunction with the normal map to achieve detailed bump and concavity effects on the model surface. For example, a vertex is a collection of all its attribute data. A triangular primitive consists of three such vertices. Therefore, the first attribute data mentioned above is the set of all vertex attributes corresponding to the vertices that constitute all target primitives.

[0037] In one aspect of this embodiment, in order to determine and read the aforementioned first attribute data, the rasterizer sends first information to the interpolator. This first information indicates the first attribute data, and its purpose is to enable the interpolator to explicitly acquire and / or identify the vertex attribute data of the target primitive. The first information is not limited to a specific form, as long as it can indicate the first attribute data. For example, the first information can directly include the numerical value of the first attribute data itself, that is, providing the attribute values ​​(such as position coordinates, normal vectors, texture coordinates, etc.) of each vertex of the target primitive along with the identification information of its respective vertex or primitive. The interpolator can directly read the first information from the rasterizer without accessing external memory and use the first attribute data therein for interpolation calculation. The first information can also include an index value or a handle, which is used to find the corresponding first attribute data in a predefined attribute table or array. The first information can also be attribute data represented in encoded or compressed form, which the interpolator needs to decode or decompress to restore to usable vertex attribute values. In addition, the first information can also be a composite structure, that is, containing both some direct attribute values ​​and some references to storage locations, to achieve flexible data organization and access. All of the above forms can enable the interpolator to determine and use the vertex attributes of the target primitive, thereby realizing subsequent interpolation calculations.

[0038] In one aspect of this embodiment, the first information may not contain specific attribute values ​​itself, but rather provide logical or physical addressing information for the first attribute data in memory. Specifically, the aforementioned memory may include: 1. Vertex cache: a high-speed cache specifically designed for the first attribute data (including attributes such as position, normals, and texture coordinates). When the target primitive is reused (e.g., vertices shared in different meshes), data can be directly retrieved from this cache, avoiding access to external storage; 2. Multi-level cache: to improve performance, modern GPU architectures typically employ a multi-level cache system. Among them, Level 1 (L1) cache is the fastest but has the smallest capacity, usually allocated to each GPU core, with a capacity ranging from 128 kilobytes (KB) to 2 megabytes (MB). Level 2 (L2) cache has a moderate response speed and capacity, and can be unique to each GPU core or shared, with a capacity ranging from 256 KB to 32 MB. Level 3 (L3) cache has the slowest response time but the largest capacity. It is usually shared and ranges in size from 1 MB to 128 MB. All of the above cache levels can cache first attribute data. As general-purpose caches, they accelerate access to first attribute data. 3. On-Chip Cache: In some GPU architectures (such as some mobile GPUs or specific computing units), there are small blocks of high-bandwidth, low-latency on-chip memory. Through careful programming, the first attribute data corresponding to the target primitive can be preloaded here for interpolators to access with extremely high efficiency. 4. Vertex Buffer: This is the most important and standard area for storing first attribute data. It resides in GPU-dedicated video memory and is created and managed by the application through the graphics API. Vertex buffers have large capacities and are designed specifically for storing large amounts of first attribute data. 5. Mapped Memory: In systems with integrated graphics or using a unified memory architecture, vertex buffers may be directly allocated in system memory (RAM) shared by the CPU and GPU. The GPU accesses this data through the Peripheral Component Interconnect express (PCIe) bus. Although the latency is higher than video memory, it simplifies memory management; 6. Blocked local memory: In GPUs using the TBR architecture, the entire frame buffer is divided into multiple tiles. After primitives are allocated to each tile, the geometrically processed vertex data (i.e., first attribute data) associated with that tile may be temporarily stored in a dedicated on-chip storage area called "tile memory". When the interpolator processes fragments within that tile, it can directly read vertex attributes from the aforementioned dedicated on-chip storage area, greatly reducing access to external storage. It is worth noting that the above-mentioned form of memory is only an illustrative example, and this embodiment does not limit it.

[0039] For example, the first information can be a direct memory address, which points to the physical or virtual memory location where the first attribute data is stored. The interpolator directly translates this address into a physical memory addressing signal through the Memory Management Unit (MMU) and sends a load instruction to the memory controller. If it is a virtual address, a page table lookup must first be performed through the address-bypass cache to complete the translation from virtual address to physical address before the first attribute data corresponding to the target address is directly read through the memory bus.

[0040] For example, the first information can be a combination of a base address and an offset. The base address identifies the starting position of the first attribute data buffer, and the offset specifies the byte distance of the target attribute relative to the base address. The interpolator has a built-in address generation unit that synthesizes the final effective address by arithmetically adding the base address, the product of the vertex index and the vertex step size, and the attribute field offset.

[0041] For example, the first piece of information could be a descriptor table index. This index points to a descriptor table entry stored in the buffer. The interpolator adds the index value to the base address of the descriptor table, first reads the descriptor content (containing data such as the buffer's physical address and range limits), and then initiates a second memory access based on the address information in the descriptor.

[0042] For example, the first information could be an indirect buffer reference. This reference points to a secondary buffer containing the address of the actual first attribute data. The interpolator first reads the indirect address from the secondary buffer and then uses that address to retrieve the final first attribute data.

[0043] It is worth noting that the first information in the embodiments of this application is intended to cover any logical or physical information that can be used to indicate the first attribute data, regardless of its specific form, encoding method or the type of memory it points to, as long as it enables the interpolator to obtain the vertex attributes of the primitive independently of the fragment shader constructor, it falls within the protection scope of this application.

[0044] In some embodiments, the second information is used to indicate the positional distribution of target fragments within a target primitive, where the target fragments are multiple fragments generated after rasterization of the target primitive. In this embodiment, the second information is core data used to generate shader thread tasks and allocate computing resources. Exemplarily, the second information may include: 1. Fragment spatial distribution information: used to describe the specific way the target primitive covers the screen space, and is the basis for allocating pixel-level computing resources. Exemplarily, the fragment spatial distribution information includes a pixel coverage mask, pixel quadrilateral grouping, and multisampling data. The pixel coverage mask, in the form of a two-dimensional bitmap, identifies the pixel positions actually covered by the target primitive, enabling the fragment shader constructor to generate shader thread tasks only for effectively covered fragments, thereby avoiding the allocation of computing resources to blank areas and causing resource waste. Pixel quadrilateral grouping divides the screen space into pixel blocks of a preset size (e.g., 2x2 pixels), serving as the basic unit for calculating the target fragment. This grouping is the necessary basis for calculating the screen space derivative, ensuring the accuracy of subsequent fragment shading. 1. Multisampling data: When Multi Sample Anti-Aliasing (MSAA) is enabled, this data records the coverage status and position of each sub-sampling point within each pixel. It guides the rendering system to generate independent fragment data or perform correct blending calculations for each covered sampling point to achieve smooth edge graphics. 2. Resource scheduling hints: Metadata provided to optimize resource allocation for the rendering system. For example, this may include: Depth range pre-calculation, which provides the approximate depth distribution range of the target primitive in the depth buffer, facilitating hierarchical culling by the early depth testing module. This allows for the early termination of shader thread tasks for fragments deemed invisible, effectively reducing the computational load on the shaders. Shading complexity prediction: Based on primitive material and other information, the computational complexity of the upcoming fragment shader is evaluated and predicted. This prediction provides hints about the computational resources the system should allocate (such as register file size, wavefront / thread bundle size, etc.), helping to achieve load balancing among computational units and improve overall parallel efficiency.

[0045] It is worth noting that the above-mentioned second information is merely an illustrative example, and this embodiment does not limit it. The core function of the second information is to transform the rasterization result into a schedulable computational task. Any data combination or information structure that can achieve this purpose, regardless of its specific encoding form or the data fields it contains, should be considered to fall within the protection scope of this application. It should be specifically noted that, for the sake of brevity and conformity with the conventions of the field, the terms "target primitive" and "primitive," and "target fragment" and "fragment" are consistent in their referential objects throughout the entire application and in the embodiments. "Target primitive" specifically refers to a specific primitive instance after rasterization processing, while "primitive" is a general term for this type of geometric unit; similarly, "target fragment" specifically refers to a specific set of fragments generated from the target primitive through rasterization, while "fragment" is a basic general term for this type of pixel-level processing unit. In the context of specific processing flow, data association, or function implementation, "primitive" refers to "target primitive," and "fragment" refers to "target fragment," and both express the same technical meaning in the context of the rendering method provided in this application.

[0046] In this embodiment, the rasterizer is designed to simultaneously send different information to two independent downstream modules: the interpolator and the fragment shader constructor. Specifically, the rasterizer sends a first message to the interpolator and a second message to the fragment shader constructor. This parallelism is embodied in the following various implementations: In one aspect of this embodiment, the rasterizer has two independent physical or logical output interfaces. One interface is dedicated to sending first information to the interpolator, and the other interface is dedicated to sending second information to the fragment shader constructor. At the hardware level, the send controllers of these two interfaces are simultaneously triggered immediately after rasterization, utilizing different virtual channels or physical links of the on-chip network for transmission. Because the information paths are completely separated, the two send operations do not block each other, achieving true synchronous startup and parallel transmission.

[0047] One aspect of this embodiment employs a pipelined overlap mode based on data characteristics. Considering that the first information (typically a few bytes of address / index) has a much smaller data volume than the second information (potentially a bitmap covering a large number of pixels), this mode utilizes this characteristic. The rasterizer initiates a long transmission to send the larger amount of second information, while simultaneously, at some stage of the second information transmission, the rasterizer can insert and quickly complete the transmission of the first information. From a system timing perspective, the transmission process of the first information is completely covered by the transmission period of the second information, with the two overlapping significantly in time, allowing the interpolator to start working ahead of time.

[0048] In one aspect of this embodiment, an asynchronous mode based on a buffer queue is employed. The rasterizer, interpolator, and fragment shader constructor all have input buffers in front. After rasterization is complete, the rasterizer asynchronously writes the first information of a target primitive to the interpolator's buffer and simultaneously writes the second information of the same target primitive to the fragment shader constructor's buffer. Once the write operation is complete, the rasterizer immediately begins processing the next target primitive without waiting for responses from downstream modules (interpolator and / or fragment shader constructor). After receiving the first information in its buffer, the interpolator can immediately begin locating and obtaining the first attribute data based on that information; similarly, after receiving the second information in its buffer, the fragment shader constructor can also immediately begin generating shader thread tasks. The startup times of these two downstream modules depend entirely on the arrival time of their respective data and are independent of each other, thus achieving natural parallelism in their work.

[0049] Through any one or more of the above parallel transmission modes, the first information and the second information can be delivered to the interpolator and the fragment shader constructor simultaneously or with partial overlap. This allows the interpolator's acquisition of the first attribute data and the fragment shader constructor's generation of shader thread tasks based on the second information to be started and executed in parallel, thereby breaking the timing constraints that must be processed serially in related technologies and shortening the graphics rendering time.

[0050] Step 320: The interpolator obtains the first attribute data based on the first information, and performs interpolation calculations based on the first attribute data to generate the second attribute data. The second attribute data is the fragment attribute data obtained after performing interpolation calculations on the first attribute data.

[0051] In one aspect of this embodiment, the interpolator is an independent functional module in the rendering system responsible for attribute data acquisition and interpolation calculations. After receiving the first information from the rasterizer, it can autonomously complete the entire process from locating the first attribute data to generating fragment attribute data, without relying on the intermediate results of the fragment shader constructor. The core function of the interpolator is to convert the attribute information defined at the primitive vertices into attribute information distributed across each fragment, thereby enabling the fragment shader to obtain continuous and accurate input data. Exemplarily, the interpolator may include the following core components: 1. Control Logic, responsible for parsing the first information and determining the data addressing mode; 2. Data Access Unit, used to access the memory to obtain the original attribute values, i.e., the first attribute data; 3. Calculation Unit, used to perform mathematical operations on the vertex attributes according to the fragment position; 4. Intermediate Cache, used to temporarily store the calculation results. It is worth noting that the above components are merely illustrative examples. In different hardware implementations, the interpolator can be an independent hardware computing unit or integrated into the Fragment Processing Unit (FPU). As long as it can independently complete the acquisition and interpolation process, it meets the requirements.

[0052] In one aspect of this embodiment, the interpolator's workflow begins by determining the location of the first attribute data based on the first information. This process requires consideration of the graphics rendering pipeline context and hardware implementation characteristics, supporting various addressing methods for locating attribute data in memory. These methods can include, but are not limited to, direct address, base address plus offset, index value, indirect reference, and any other addressing method that can locate the first attribute data in memory. It is worth noting that these addressing methods can be used individually or in combination to adapt to different storage layouts of the first attribute data (such as scattered storage, contiguous arrays, interleaved formats, etc.), ensuring that the interpolator can accurately obtain the first attribute data of each vertex of the target primitive. After determining the addressing method and completing address resolution, the interpolator accesses the corresponding storage location through the data access unit and reads the first attribute data of each vertex of the target primitive. For example, for frequently accessed vertex attributes (such as position and texture coordinates), a cache prefetching mechanism can be used to preload them into the cache; for large-size attribute data (such as complex per-vertex structures), a block-based reading or on-demand loading strategy can be adopted to balance bandwidth utilization and access latency. At the same time, the data access unit needs to perform necessary format verification, such as data type matching and boundary checks, to avoid abnormal interpolation results due to storage errors.

[0053] In one aspect of this embodiment, after reading the first attribute data of each vertex of the target primitive, the interpolator enters the core interpolation calculation stage: based on the spatial position representation of the fragment within the target primitive (such as centroid coordinates) or other position representations, combined with a preset interpolation mode (such as perspective-corrected interpolation, linear interpolation, or flat interpolation), appropriate mathematical operations (such as weighted average or other interpolation algorithms) are performed on the first attribute data to obtain the attribute value corresponding to the fragment, i.e., the second attribute data. Specifically, this can include: 1. Acquisition of spatial position representation: The fragment position information generated during the rasterization stage (such as barycentric coordinates (u, v, w), satisfying u+v+w=1) directly reflects the relative position of the fragment within the target primitive; 2. Selection of interpolation algorithm: Based on the interpolation mode specified in the first information, the corresponding mathematical operation is adopted—perspective correction interpolation requires depth inverse weighting of vertex attributes in projection space to ensure visual correctness under perspective projection; linear interpolation directly performs weighted averaging based on barycentric coordinates or screen space position; constant interpolation ignores fragment position and directly reuses the first attribute data of a vertex as the second attribute data of all fragments; 3. Calculation precision and exception handling: The computing unit needs to support configurable calculation precision (such as 32-bit floating point (32FP) and 16-bit floating point (16FP)), and perform rounding, truncation, or overflow processing according to hardware capabilities. Handling ensures the validity and consistency of the second attribute data. After completing the interpolation operation, the interpolator temporarily stores the generated second attribute data in an intermediate buffer for subsequent fragment shader stages to read. For example, the form of the above intermediate buffer needs to match the parallelism of fragment processing, such as being managed at the fragment granularity or primitive block granularity.

[0054] It is worth noting that the function of the interpolator in this embodiment is to complete attribute data acquisition and interpolation calculation based on the first information. Its implementation method can vary with differences in hardware architecture, such as sequential processing, on-demand block processing, or batch prefetching. Any technical implementation that enables the interpolator to independently complete the above process falls within the protection scope of this application.

[0055] In one aspect of this embodiment, the first attribute data refers to various feature data associated with the vertices of the target primitive. It is organized by vertex and used to describe the geometric and appearance characteristics of the primitive. Common forms may include vertex coordinates, normals, texture coordinates, color, etc., but are not limited to these. Exemplarily, the first attribute data is only bound to vertices and does not directly correspond to fragments; it needs to be mapped to fragment space through interpolation calculations.

[0056] The storage location of the first attribute data is indicated by the first information. This location can be described using any form of memory addressing, such as directly pointing to a physical or virtual address, a combination of a base address and an offset, an index value pointing to a descriptor, or an indirect buffer. The memory corresponding to the storage location can be any medium capable of storing attribute data, such as cache, video memory, system memory, or on-chip dedicated memory (OCDM). During the acquisition of the first attribute data, the interpolator accesses the corresponding memory according to the addressing mode provided by the first information and reads the attribute values ​​of all vertices of the target primitive. This process does not depend on the fragment shader constructor or the specific information of the fragment position; it is only related to the vertex set and the storage location of the first attribute data.

[0057] In one aspect of this embodiment, the second attribute data is fragment-based attribute data obtained by the interpolator after interpolating the first attribute data. Its generation process involves mathematically converting vertex-level attribute values ​​according to the spatial distribution of fragments within primitives, so that each fragment obtains a set of attribute values ​​corresponding to its position. For example, the interpolation calculation can employ various algorithms, such as linear interpolation, perspective correction interpolation, constant interpolation, or preset value substitution, depending on rendering requirements and pipeline configuration. The fragment position used for calculation can be determined by centroid coordinates, sampling point positions, or equivalent position representations. After completing the calculation, the interpolator organizes the results into a fragment attribute set, i.e., the second attribute data. For example, the organization of the second attribute data typically corresponds one-to-one with fragments and can include various attribute types such as position, normal, texture coordinates, and color. The format and semantics of these attributes are pre-defined by the rendering pipeline to ensure that the fragment shader can correctly parse and use them. The second attribute data only contains numerical results and does not contain control instructions; its content and structure are determined by the interpolation process. It is worth noting that the generation of the second attribute data depends entirely on the interpolator's calculation of the first attribute data, and its possible interpolation algorithm, data format, and storage method can be determined according to system requirements. Any technical solution that can obtain fragment attribute data from vertex attribute data through interpolation falls within the protection scope of the embodiments of this application.

[0058] Step 330: The fragment shader constructor generates a shader thread task based on the second information. The shader thread task is used to shade the target fragment.

[0059] In one aspect of this embodiment, the fragment shader constructor is a functional module in the rendering system responsible for converting rasterization results into executable computational tasks. After receiving second information from the rasterizer, it can independently analyze the positional distribution of target fragments within the target primitives and generate a set of shader thread tasks accordingly. Each shader thread task corresponds to a target fragment, used to instruct the fragment shader to perform shading computation on that fragment. Exemplarily, the fragment shader constructor may include an information parsing unit, a task generation unit, a resource allocation unit, and a task output interface in its hardware structure. Specifically: 1. The information parsing unit is responsible for reading the second information and extracting data related to the distribution of the target fragments; 2. The task generation unit determines the number and spatial distribution of fragments to be shading based on the parsing results and creates a corresponding execution description for each fragment; 3. The resource allocation unit is responsible for planning the registers, caches, and other computational resources required for execution; 4. The task output interface sends the generated shader thread tasks to the subsequent scheduling or execution unit. It is worth noting that the fragment shader constructor can be an independent hardware module or integrated into the fragment processing unit or thread management unit. As long as it can independently complete the process of generating shader thread tasks from the second information, it falls within the protection scope of this embodiment.

[0060] In one aspect of this embodiment, the fragment shader constructor first parses the second information to determine the spatial distribution characteristics and quantity of the target fragments. This second information, typically output by the rasterizer, includes a description of the fragment's positional distribution in screen space or primitive space (such as fragment coordinate sets, scanline ranges, and tile partitioning information), but does not involve specific vertex attribute data (i.e., first attribute data). The parsing process relies solely on the description of fragment positional distribution in the second information, extracting features such as spatial continuity and density distribution of fragments through statistical analysis, clustering, or rule derivation, providing a basis for subsequent resource allocation. For example, the fragment shader constructor can allocate the necessary computational resources (such as Arithmetic Logic Unit (ALU) time slices, register file entries, and on-chip cache partitions) to each fragment based on the parsed features, and encapsulate and generate shader thread tasks. The core function of the shader thread task is to convey to the fragment shader the instructions to perform shading on a specific fragment, along with necessary contextual information (such as fragment screen coordinates, primitive identifier, depth value, associated texture sampler, etc.), enabling the fragment shader to perform independent shading calculations (such as lighting calculations, texture mapping, and opacity blending) for that fragment. It's worth noting that the fragment shader constructor's workflow is entirely based on second attribute data and does not have a direct data dependency with the interpolator, thus allowing it to run in parallel with the interpolator. This parallelism significantly reduces pipeline bubbles in fragment processing: while the interpolator is busy calculating second attribute data (such as texture coordinates and color values), the constructor can pre-generate shader thread tasks, providing the fragment shader with the interpolation results (i.e., second attribute data) once they are ready, thereby improving rendering throughput.

[0061] In one aspect of this embodiment, the implementation of the fragment shader constructor generating shader thread tasks can vary depending on hardware architecture. For example, it may include: 1. Single-threaded sequential generation: Suitable for area and power-sensitive embedded GPUs or system-on-chips (SoCs). The fragment shader constructor parses the fragment distribution one by one in a serial manner and generates shader thread tasks. The logic is simple but the throughput is limited.

[0062] 2. Multi-threaded parallel packaging: In GPUs, fragment shader constructors can be divided into multiple parallel working threads. Each thread allocates tasks based on fragments, using multi-threaded concurrency to accelerate task generation. Furthermore, the execution descriptions of multiple fragments can be packaged into batches to improve instruction sending efficiency.

[0063] 3. Streaming generation based on hardware scheduler: In an architecture that supports dynamic scheduling, the fragment shader constructor works with the hardware scheduler to stream generation tasks based on the real-time load of the fragment shader units, dynamically balancing the workload of the fragment shader and avoiding resource idleness or overload.

[0064] Furthermore, the constructor can introduce task merging and priority sorting optimizations. Specifically, it merges spatially adjacent shader thread tasks with similar execution descriptions to reduce scheduling overhead; and sorts shader thread tasks based on fragment depth, visibility, or rendering queue priority, allowing the fragment shader to prioritize fragments that contribute more to the final image, thus improving rendering efficiency and visual quality. It is worth noting that any technical solution that enables the fragment shader constructor to independently generate shader thread tasks based on the second information and supports parallel operation with the interpolator falls within the scope of this application.

[0065] Step 340: The fragment shader executes the shader thread task based on the second attribute data to generate the shaded target fragment.

[0066] In one aspect of this embodiment, the fragment shader is responsible for performing fragment-by-fragment shading calculations to determine the final color, transparency, depth, and other attributes of the fragment. The fragment shader takes the second attribute data as input and, in conjunction with the context information carried in the shader thread task generated by the fragment shader constructor, executes independent, parallelizable shading logic for each fragment. Exemplarily, the hardware implementation of the fragment shader can include: 1. In a GPU, it can be executed in parallel by multiple fragment shader cores, with each core handling multiple fragment shader thread tasks simultaneously; 2. In embedded or low-power scenarios, the fragment shader can be integrated within a fragment processing unit, operating in a microarchitecture manner. The core computational resources of a fragment shader can include: an arithmetic logic unit, a vector processing unit (VPU), a texture sampling unit (TSU), and register files, and support floating-point operations, vector operations, texture sampling, conditional branching, and other operations to meet the needs of complex shading algorithms (such as physically based rendering (PBR), procedural texture generation, lighting model calculation, etc.).

[0067] In one aspect of this embodiment, the fragment shader executes a shader thread task based on the second attribute data to generate the shaded target fragment. Exemplarily, the specific working process of the fragment shader may include the following steps: 1. Task Reception and Context Resolution: The fragment shader receives the shader thread task generated by the fragment shader constructor, parses the context information contained in the task (such as fragment screen coordinates, depth value, primitive identifier, texture sampler, etc.), and determines the target fragment to be processed. This process does not involve reading secondary attribute data; it only completes task scheduling and initialization of the execution environment.

[0068] 2. Acquisition of Second Attribute Data: The fragment shader reads the second attribute data corresponding to the target fragment from the intermediate cache or a specified storage area based on the index or address information of the attribute data specified in the shader thread task. For example, if the second attribute data includes texture coordinates and vertex colors, the fragment shader can read these interpolated attribute values ​​from the intermediate cache through the data access port to provide input for subsequent shading calculations.

[0069] 3. Shading Calculation Execution: The fragment shader executes predefined shading logic based on the read second attribute data and context information. The shading logic can be specified by the developer through the shader program or implemented by fixed hardware functions. For example, typical shading calculations may include: 1) Texture sampling: reading texture pixels from texture memory using texture coordinates and calculating texture color using texture filtering modes (such as bilinear filtering, trilinear filtering, and anisotropic filtering); 2) Lighting calculation: calculating the lighting contribution of fragments using a lighting model (such as a physically based rendering model) based on normal vectors, light source parameters (such as direction, intensity, and color), material properties (such as diffuse coefficient and specular coefficient), and viewpoint direction; 3) Color blending: weighted blending of texture color, lighting results, and vertex color, and determining the initial color of fragments by combining the transparency value; 4) Depth and stencil test preprocessing: performing comparisons or stencil value updates before depth testing based on the depth value and stencil buffer state, providing data for the subsequent depth-stencil test stage.

[0070] 4. Shading Result Output: After completing the shading calculation, the fragment shader generates the shaded target fragment. The target fragment contains attributes such as the final color value, depth value, transparency, and stencil value, and writes these as output data to a specified output buffer, such as a color buffer, depth buffer, or other specific buffer. The above output data will serve as input data for subsequent rendering stages (such as depth-stencil testing, blending, and framebuffer updates), and ultimately participate in the generation of the screen image.

[0071] It is worth noting that the specific implementation of the fragment shader may vary depending on the hardware architecture, but as long as it can execute the shader thread task based on the attribute data and generate the shaded target fragment, it falls within the protection scope of this application.

[0072] By functionally splitting the information output from the rasterization stage into first information and second information, and sending them to the interpolator and fragment shader constructor respectively, the decoupling and parallelization of attribute data generation and shading task construction are achieved. The interpolator only needs to focus on locating and obtaining the vertex attribute data (first attribute data) of the target primitive based on the first information, and then generating fragment attribute data (second attribute data) through interpolation calculation, without needing to care about the specific distribution of fragments or shading logic. The fragment shader constructor, on the other hand, parses the spatial distribution characteristics and quantity of the target fragments based entirely on the second information, and independently generates shader thread tasks, avoiding direct data dependence with the interpolator or attribute data acquisition stage. The aforementioned decoupling mechanism allows the interpolator and fragment shader constructor to run in parallel, reducing rendering pipeline latency and improving overall throughput. Simultaneously, the fragment shader can directly execute shader thread tasks based on the second attribute data generated by the interpolator, forming an interpolation-construction-shading pipeline. This ensures timely data supply and, by constructing shader thread tasks at the fragment level, enables the fragment shader to perform independent and efficient shading calculations for each target fragment. Furthermore, this process is highly adaptable to hardware implementation. The specific implementation methods of the interpolator, fragment shader constructor, and fragment shader (such as independent hardware units or integrated modules) can be flexibly adjusted according to the architecture. As long as the core logic of "information decomposition—parallel processing" is followed, performance and resource utilization optimization can be achieved while ensuring rendering correctness, thereby improving graphics rendering efficiency.

[0073] In some embodiments, the first information includes primitive information and a first attribute table. The primitive information indicates the vertices constituting the target primitive, and the first attribute table records the storage location information of the first attribute data.

[0074] For example, the primitive information may be the same as or different from the primitive identification information received and sent by the rasterizer, but its core function is to uniquely indicate the vertices that constitute the target primitive. Specifically, the primitive information contains key identifiers that can be traced back to the original geometric data, such as a system-generated primitive index or a primitive ID provided by the application. Using this information, the interpolator can clearly identify which vertices constitute the primitive that needs to be processed, which is a prerequisite for subsequently locating and obtaining the attribute data (i.e., the first attribute data) of these vertices. In some embodiments, the primitive information may include not only the basic primitive index, but also the starting index of the vertex sequence and the number of vertices. When indexed drawing is used, the primitive information may also include the base address and index offset of the index buffer, enabling the interpolator to indirectly obtain vertex identifiers through the index buffer. In addition, the primitive information may also include instance identifiers related to instantiation drawing, used to distinguish the source of attribute data for the same target primitive in different instances. It is worth noting that the expression of primitive information is not limited to the above examples. Any information representation that can uniquely determine the set of vertices constituting primitives and enable the interpolator to locate the first attribute data accordingly falls within the protection scope of the embodiments of this application.

[0075] For example, the core function of the first attribute table is to record the storage location information of the first attribute data. Specifically, the specific form of the first attribute table may include: 1. Direct Address Record Table: In this form, the first attribute table is essentially an address lookup table. Each entry in the table directly records the starting address and data range of one or more first attribute data in memory. The interpolator, based on the vertex index determined by the primitive information, can look up the table to obtain the precise memory location of the corresponding first attribute data, and then initiate a direct memory access.

[0076] 2. Descriptor Index Table: In this form, the first attribute table does not directly store memory addresses, but instead stores one or more descriptor indices. These indices point to specific entries in the global descriptor heap, and the descriptor entries contain complete information about the buffer view, such as the device virtual address, size, and format of the buffer resource. This approach abstracts away the details of resource management, allowing drivers to flexibly reorganize memory without updating all first attribute tables.

[0077] 3. Indirect Buffer Reference Table: In this form, the first attribute table acts as a first-level indirect reference layer. The table records the addresses of second-level buffers, which store the actual first attribute data or its exact address. The interpolator first reads the first attribute table to obtain the pointer to the second-level buffer, and then accesses the second-level buffer to resolve the final target data address. This multi-level addressing method is particularly suitable for managing large amounts of small or dynamic vertex attribute data.

[0078] The core design of the aforementioned first attribute table lies in establishing an accurate mapping relationship from primitive vertices to their attribute data storage locations, laying the foundation for the interpolator to independently obtain the first attribute data. It is worth noting that the aforementioned first attribute table and primitive information are merely illustrative examples. Any data structure capable of providing the interpolator with the location information required to obtain the first attribute data, regardless of its specific implementation as the aforementioned lookup table, index table, reference table, mapping table, or other forms of configuration data, link lists, or hierarchical data structures, as long as it records the storage location information of the first attribute data, falls within the protection scope of this application's embodiments.

[0079] By designing the first information as a combined structure including primitive information and a first attribute table, the following technical effects are achieved. First, the primitive information uniquely identifies the set of vertices constituting the target primitive in a concise data form (such as primitive index, starting index, etc.), while the first attribute table centrally records the storage location information of all relevant first attribute data in a highly structured manner (such as address record table, descriptor index table, etc.). This design makes the first information small in data volume and compact in structure. Furthermore, due to its small data volume, the rasterizer can send the first information to the interpolator extremely quickly, reducing communication bandwidth consumption and transmission latency, and saving valuable time for subsequent parallel processing. After receiving the first information, the interpolator can quickly determine the vertices of the target primitive based on the concise primitive information, and use the first attribute table to directly parse the storage location of the corresponding first attribute data through fast operations such as table lookup, thereby quickly initiating memory access and avoiding the process of slow searching or complex address calculations in large amounts of data.

[0080] In some embodiments, the interpolator obtains first attribute data based on first information, including: the interpolator determines the vertices constituting the target primitive based on primitive information; the interpolator obtains the first attribute data based on the storage location information of the first attribute data corresponding to the vertices constituting the target primitive.

[0081] In one aspect of this embodiment, the interpolator first receives and parses the primitive information in the first information. This primitive information is crucial for locating the vertex set. Exemplarily, when the primitive information contains primitive indices, the interpolator includes an address generation unit and / or a dedicated state machine. The address generation unit and / or state machine use the primitive index as a lookup address to access a primitive-vertex mapping table preloaded into on-chip cache or constant memory by the driver. This mapping table is typically a linear array, with each entry storing a list of vertex identifiers constituting a primitive (e.g., for a triangle primitive, an entry contains three vertex indices). Through one or more cache accesses, the interpolator can obtain the vertex identifiers of all vertices constituting the current target primitive. In some embodiments, the primitive information also includes instance identifiers. In this case, the interpolator's control logic activates the instance data processing path. It uses the instance identifier as an offset to access a specific instance data buffer. This buffer stores data such as the transformation matrix and material ID for each instance, and also includes the base address offset of the instantiated vertex data. The interpolator superimposes the base address offset obtained from this buffer with the vertex index obtained from the primitive-vertex map to calculate a globally unique vertex identifier for each vertex in the instantiated vertex buffer.

[0082] After obtaining the precise vertex identifiers, the interpolator reads the first attribute table and performs the corresponding first attribute data acquisition operation according to the specific form of the first attribute table.

[0083] In one aspect of this embodiment, the first attribute table is a direct address record table. The interpolator performs the following specific operations through its internal memory management unit to obtain the first attribute data: the memory management unit combines the vertex identifier with the attribute type identifier (e.g., used to distinguish whether the attribute to be obtained is a position attribute or a normal attribute) to generate a query key value. This query key value is used for retrieval in the direct address record table (i.e., the first attribute table). The direct address record table is typically integrated in the form of an array in the on-chip static random-access memory (SRAM) to achieve high-speed access within a single clock cycle. Each entry in the table contains a base address and the size information of the attribute data block. After obtaining the corresponding entry, the address generation unit of the interpolator performs an address calculation operation. Specifically, the calculation formula is: effective address = base address + (vertex identifier × attribute data step size). Here, the attribute data step size refers to the byte interval between the corresponding data of two adjacent vertices when the same type of attribute data is arranged continuously in the storage buffer. This value is pre-configured by the system software according to the vertex buffer layout and informed to the interpolator. After the address calculation is complete, the interpolator's data loading unit submits the obtained valid address to the memory subsystem. This request may undergo virtual address to physical address translation via the Translation Lookaside Buffer (TLB) and then be issued as a burst read transaction. The first attribute data stream returned from memory is temporarily stored in the interpolator's input data buffer, awaiting subsequent interpolation calculations.

[0084] In one aspect of this embodiment, the first attribute table is a descriptor index table, and the interpolator can obtain the first attribute data through the following steps: 1. The interpolator uses the vertex identifier and attribute type identifier as input to query a descriptor index from the descriptor index table (i.e., the first attribute table). 1. The index's bit width is optimized, typically only a few to tens of bits, thus reducing the storage overhead of the index table itself; 2. After obtaining the descriptor index, the interpolator calculates the specific location of the target descriptor in memory using its internally maintained Base Address Register (BAR) and the preset descriptor size information. The calculation formula is: Descriptor address = Descriptor base address + (Descriptor index × Descriptor size); 3. Subsequently, the interpolator sends a request to the memory subsystem to load the target descriptor content into its internal cache; 4. The interpolator decodes the obtained descriptor, extracting key information, including but not limited to: attribute buffer base address, buffer effective range, and attribute data step size; 5. Finally, based on the decoded buffer base address and attribute data step size, combined with the vertex identifier, the interpolator generates the final effective memory address. The calculation formula is: Effective address = Buffer base address + (Vertex identifier × Attribute data step size). The subsequent data loading process can be the same as the aforementioned implementation method. The interpolator initiates a memory read request based on the valid address, and the obtained first attribute data is temporarily stored in the input data buffer, waiting for subsequent interpolation calculations.

[0085] In one aspect of this embodiment, the first attribute table is an indirect buffer reference table. The interpolator can obtain the first attribute data through the following steps: 1. The interpolator takes the vertex identifier as input and accesses the indirect buffer reference table. This table stores multiple secondary buffer pointers, not the final attribute data address. The interpolator reads the corresponding secondary buffer pointer according to the input information; 2. The interpolator then accesses the secondary buffer pointed to by the pointer. According to the system design, the processing of the secondary buffer is divided into two forms: 1) When the secondary buffer is organized as an address list, the interpolator uses the vertex identifier as an index and directly reads the final target address by calculating: address index = vertex identifier. The address acquisition formula at this time is: final address = secondary buffer base address + address index × address unit size; 2) When the secondary buffer is organized as a data block, the interpolator can use the vertex identifier combined with the attribute data unit size to calculate the data offset. The data acquisition formula at this time is: data offset = vertex identifier × attribute data unit size, effective address = secondary buffer base address + data offset; 3. After obtaining the final target address, the interpolator initiates a read request to the memory subsystem. The returned first attribute data is temporarily stored in the input data buffer, awaiting subsequent interpolation calculations. This two-level addressing mechanism maintains flexibility in attribute data management while ensuring the interpolator can efficiently and independently complete data acquisition tasks. When the system needs to update attribute data, only the contents or pointers of the second-level buffer need to be adjusted, without modifying the main structure of the first attribute table.

[0086] For example, when the interpolator actually retrieves the first attribute data, its internal scheduling and execution strategy can be selected based on the hardware architecture and the objective. Specifically, it can include, but is not limited to, the following methods: 1. Sequential Traversal-Based Acquisition Method. In some embodiments, the interpolator employs a deterministic sequential execution strategy. Its internal control logic (such as a finite state machine) iterates sequentially through all target primitives specified by the first information. For each primitive, after resolving its vertex set, the interpolator further iterates sequentially through all information blocks related to that primitive in the first attribute table (e.g., descriptors or address records for different attributes such as position, normals, and texture coordinates). For each information block processed, the interpolator initiates one or a set of memory requests to retrieve the corresponding vertex attribute data block from memory and temporarily stores it in an internal buffer. This method is logically simple, has low hardware implementation complexity, and is suitable for designs sensitive to power consumption and area.

[0087] 2. On-Demand Fetching Based on IMR Architecture. In the IMR architecture, rendering commands are executed immediately, and pipeline state switching is frequent. To accommodate this characteristic, the interpolator does not prefetch all attribute data for a single primitive, but rather tightly couples with the rhythm of rasterization and fragment generation. For example, the interpolator is immediately triggered after the rasterizer completes the rasterization of a primitive block (e.g., a 2x2 pixel quadrilateral) and sends the first information. The interpolator only calculates the required interpolation parameters (such as barycentric coordinates) for the fragments covered by the current primitive block. Then, the interpolator only fetches the corresponding first attribute data necessary to perform the interpolation calculation for this small batch of fragments. This fetching strategy greatly reduces the instantaneous pressure on the chip's internal cache and memory bandwidth, avoiding the movement of large amounts of useless data.

[0088] 3. Batch Fetching Based on TBR Architecture. In the TBR architecture, the entire pixel screen area is divided into multiple small tiles for rendering. Under this architecture, the interpolator's data fetching strategy is more global and batch-processing-oriented. For example, after the geometry processing stage, the system performs a tile allocation process to determine which tiles each primitive belongs to. For example, the interpolator can intervene at this stage. The system generates a first information list for all primitives within a tile. Subsequently, before the specific rendering of that tile begins, the interpolator can perform a batch prefetch operation. It iterates through the aforementioned first information list, identifies all the first attribute data required by all primitives within the tile, and uniformly preloads this data from system memory into the on-chip cache. When the fragments within the tile begin to be rendered, all the first attribute data required by the interpolator is already in the high-speed on-chip cache, thus achieving extremely low latency and extremely high bandwidth for the interpolation operation, thereby improving performance.

[0089] It's worth noting that the interpolator's method of obtaining first attribute data is not static; it can be flexibly configured based on the target architecture (IMR or TBR), performance, and power consumption requirements. Whether it's simple sequential traversal, on-demand loading under IMR, or batch retrieval under TBR, the core objective is to utilize the memory system most effectively while ensuring correctness, ensuring that the interpolator can obtain first attribute data in a timely manner, thereby supporting the parallel operation of the entire graphics rendering pipeline.

[0090] It is worth noting that the data acquisition methods based on the direct address record table, descriptor index table, and indirect buffer reference table, as well as scheduling strategies such as sequential traversal, on-demand acquisition, and batch prefetching, are all illustrative examples of the embodiments of this application. The core of this application lies in enabling the interpolator to locate and acquire the first attribute data independently of the fragment shader constructor through the first information, thereby achieving parallelization of attribute information acquisition and shader thread task generation. Any technical solution that can realize this core idea, regardless of the specific data structure used to organize the first information (including but not limited to the above table structure or its combination), or the memory access mode and scheduling strategy used (including but not limited to the above sequential, on-demand, or prefetching methods), as long as it achieves the fundamental purpose of the interpolator independently acquiring the first attribute data based on the first information, falls within the scope of protection claimed by the embodiments of this application.

[0091] The entire process described above is driven by the interpolator's internal hardware logic. Throughout the process, the interpolator operates autonomously based solely on the initial information from the rasterizer, without any synchronization requirements or data dependencies between it and the fragment shader constructor. Specifically, after receiving the initial information, the interpolator can independently complete the operations from vertex localization to attribute data acquisition without waiting for any intermediate results or control signals from the fragment shader constructor. Therefore, the interpolator's workflow and the fragment shader constructor's workflow achieve true hardware-level parallelism, effectively eliminating inter-module waiting and improving the throughput of the graphics rendering pipeline.

[0092] In some embodiments, the first attribute table includes multiple attribute table headers. The attribute table headers are used to indicate their corresponding second attribute table; the second attribute table is used to record control information of the first attribute data, including: interpolation instructions for indicating interpolation calculations and type information of the first attribute data.

[0093] For example, please refer to Figure 4 , Figure 4 This is a schematic diagram of a first attribute table and a second attribute table provided in one possible implementation of this application. The first attribute table 410 may include multiple attribute table headers (attribute table header 0 to attribute table header N), and each attribute table header corresponds to a second attribute table, such as... Figure 4 The attribute header 0 corresponds to attribute table 0, which is the second attribute table 420.

[0094] In this embodiment, the attribute header is the most basic unit of the first attribute table. Essentially, it is a simple location descriptor, and its core function is to indicate a corresponding second attribute table (e.g., ...). Figure 4The second attribute table (420) is a collection of attribute control information blocks containing complete control information for multiple first attribute data (such as position, normal, texture coordinates, etc.), and may include: storage location information, type information, and interpolation instructions. Exemplarily, the attribute table header itself is typically presented in the form of a starting physical address (or device virtual address) combined with the table size. This design abstracts and encapsulates the control information of an entire set of attributes in a fixed-size data structure (attribute table header). Exemplarily, the attribute table header can be defined as a fixed-length data structure. When the rasterizer transmits the first information to the interpolator, the portion concerning the attribute table only needs to transmit the index or data of one or more attribute table headers. For example, to transmit primitive information containing three attributes—position, normal, and texture coordinates—a conventional approach might require transmitting three separate attribute block information, while in the technical solution proposed in this application, the rasterizer only needs to transmit an attribute table header pointing to the second attribute table containing the control information of these three attributes (i.e., the first attribute data). The above structure significantly reduces the amount of data transmitted for communication between the rasterizer and the interpolator, and for the interpolator, processing fixed-length data units is simpler than processing variable-length data streams. For example, the first attribute table itself can be organized into an attribute header array. In some embodiments, the first information passed from the rasterizer to the interpolator only needs to contain one or more attribute header indices. The interpolator can obtain the target attribute header using the global attribute header array base address and the received primitive information. This approach provides great flexibility, allowing the driver to dynamically reorganize attribute groups (i.e., update the contents of the second attribute table) or remap their positions (update the attribute headers) without modifying the rasterizer's output path or the first information already sent. It is worth noting that the control information described above, which uses attribute headers as basic units and references the second attribute table to read the first attribute data, is only a preferred implementation of the first attribute table. The scope of protection for the first attribute table in this application is not limited to this. Any data structure or information set that can indicate the first attribute data and can be read by the interpolator so that the interpolator can obtain the first attribute data independently of the fragment shader constructor falls within the definition and protection scope of the first attribute table in this application.

[0095] In some embodiments, the second attribute table (such as...) Figure 4 The function of the second attribute table (420) is to provide the interpolator with all the control information required to perform the first attribute data acquisition and interpolation calculation. This control information collectively guides the interpolator to complete the process from data acquisition to interpolation calculation. For example, it may specifically include the following types of control information: 1. Storage Location Information of First Attribute Data: The storage location information indicates the position of the first attribute data in memory or cache, and is the direct basis for the interpolator to perform data acquisition operations. Its specific form varies, and it is a set of addressing information composed of multiple parameters, which may include: Device Virtual Address: A direct memory address pointing to the starting position of the vertex buffer, translated into a physical address by the GPU memory management unit; Descriptor Index: An index value used to look up the corresponding buffer descriptor in the global descriptors maintained by the driver. This descriptor contains complete information such as the buffer's device virtual address, size range, and format; The attribute's offset value in memory, which is usually divided into two key parameters: offset and step. These two parameters together define the accurate position of the first attribute data in memory. The offset specifies the starting byte position of a certain attribute in the first attribute data within a vertex data block (i.e., all attribute data of a vertex). The step defines the byte distance between the starting addresses of two adjacent vertex data blocks in the vertex buffer. It can be understood as the offset value that the address needs to skip for each increment of the vertex index. For example, after obtaining the aforementioned addressing parameters, the address generation unit inside the interpolator executes a computational pipeline. The core objective of this pipeline is to synthesize the abstract addressing parameters into a specific effective memory address. Specifically, it first calculates the address offset caused by the vertex index. The formula is: Index Offset = Vertex Index × Vertex Step Size. This step determines the position of the target vertex's data block relative to the starting point of the buffer. Next, based on the index offset obtained in the previous step, the static offset of the target attribute within its own vertex data block is added. The formula is: Effective Offset = Index Offset + Attribute Field Offset. This effective offset is the complete byte distance of the current vertex's target attribute data relative to the base address, i.e., the total deviation value. Finally, the calculated effective offset is added to the base address of the vertex buffer to generate the final absolute address used to initiate the memory access request. The formula is: Effective Address = Base Address + Effective Offset.

[0096] For example, suppose a vertex buffer stores the vertex data of a primitive with a triangular shape. The data structure of each vertex is as follows: position (consisting of three 32-bit floating-point numbers, occupying 12 bytes), normal (also consisting of three 32-bit floating-point numbers, occupying 12 bytes), and texture coordinates (consisting of two 32-bit floating-point numbers, occupying 8 bytes). Therefore, the total size of a single vertex data is: 12 bytes + 12 bytes + 8 bytes = 32 bytes. Here, the base address is 0x1000 (the starting address of the vertex buffer in memory), the target attribute is texture coordinates, the attribute field offset of the texture coordinates is 24 bytes (this is the starting position of the attribute within the vertex data block, determined by the sum of the space occupied by the preceding position attribute and normal attribute: 12 bytes + 12 bytes = 24 bytes), the vertex stride is 32 bytes (this is the byte distance between the starting addresses of two adjacent vertex data blocks in the buffer, equal to the total size of a single vertex data), and the currently processed vertex index is 1 (intending to obtain the texture coordinate data of the second vertex). For example, based on the above assumptions, the index offset = vertex index × vertex stride = 1 × 32 = 32 bytes; the effective offset = index offset + attribute field offset = 32 + 24 = 56 bytes, which is the total deviation of the texture coordinate data of the second vertex from the base address 0x1000. Finally, the effective address = base address + effective offset = 0x1000 + 56 = 0x1038. Through the above calculations, the interpolator's address generation unit will output a valid address of 0x1038. Subsequently, the interpolator initiates a loading request for this address, which precisely points to the texture coordinate data of the second vertex in the vertex buffer. It is worth noting that the storage location information and specific values ​​of the first attribute data described above are merely illustrative. Any data capable of indicating the physical or logical location of the first attribute data in memory falls within the protection scope of this application's embodiments.

[0097] 2. Interpolation Instructions for Interpolation Calculation: This category defines how the interpolator should calculate the acquired first attribute data to generate an interpolation result applicable to each fragment. It is a set of coded control signals that provide operational guidance for the interpolator's calculation unit. Specifically, the interpolation instructions mainly include the following aspects of control: 1. Perspective Correction Interpolation: This mode instructs the interpolator to consider the nonlinear changes in vertices after perspective projection transformation when performing interpolation. The interpolator will use the depth information of the fragment to perform nonlinear weighted calculations on the first attribute data to ensure that attributes that change linearly in three-dimensional space (such as texture coordinates and color) are correctly represented on the two-dimensional screen image. This is the standard and necessary mode for processing most surface attributes (such as texture coordinates and color); 2. Linear Interpolation: This mode instructs the interpolator to perform a linear weighted average directly in screen space. It is suitable for attributes whose changes remain linear after transformation from 3D space to screen space, such as depth values; 3. Planar shading: This mode instructs the interpolator not to perform fragment-by-fragment calculations on attributes, but instead to directly assign the attribute value of a specific vertex (usually designated as the first vertex) in a primitive to all fragments covered by that primitive. This mode is also called constant interpolation and is suitable for situations that require a planar shading rendering style; 4. Default value handling control: When an attribute is marked as "use default value", it instructs the interpolator to bypass the normal data acquisition and interpolation process in a specific scenario. For example, when a first attribute data is not bound to a valid buffer, or the data is unavailable for other reasons, the interpolator will no longer attempt to read from memory, but will directly use a default value pre-configured during pipeline state settings (e.g., setting the color to white by default, or setting the texture coordinates to (0, 0) by default). This effectively prevents rendering errors or pipeline stalls caused by missing data; 5. Per-pixel interpolation, which instructs that a complete interpolation calculation be performed once for each pixel center or each sampling point, is the way to ensure the highest image quality; 6. Per-pixel quadrilateral interpolation, which instructs that interpolation calculations be performed in units of pixel blocks of a preset size. This method mainly serves operations that require calculating screen space derivatives. By obtaining the attribute values ​​of adjacent pixels at the same time, the hardware can efficiently calculate gradients in different directions through differential calculation. By reading and executing the above interpolation instructions, the interpolator can adapt to various rendering needs from simple to complex, from high-speed to high-quality, ensuring the generation of correct fragment attribute data (i.e., second attribute data) for the shader to use.

[0098] It is worth noting that the specific types, control methods, and implementation details of the interpolation instructions described above are merely illustrative examples. Any implementation that guides the interpolator on how to process the first attribute data to generate the second attribute data falls within the protection scope of this application's embodiments.

[0099] 3. Type Information of First Attribute Data: This category information describes the format and semantics of the first attribute data itself and its association with the shader program. It is crucial to ensure that the original data can be correctly parsed, calculated, and ultimately used by the shader. It defines the data interface specification for collaboration between the interpolator and the fragment shader. Specifically, the above type information may include: 1. Shader Input Semantic Association: This information establishes a mapping relationship between the second attribute data generated after interpolation and the fragment shader input. Its core is a shader input locator, which specifies where the second attribute data should be written in the fragment shader (e.g., a specific shader input register address). This mechanism not only solves the problem of physical data storage, but more importantly, it defines the data type and rendering semantics of the second attribute data through its location. For example, data specified to be sent to a particular register will be interpreted as diffuse color in the shader program, while data sent to another register will be interpreted as a set of texture coordinates. In this way, type information ensures that the second attribute data output by the interpolator can be structurally and semantically precisely matched with the list of input parameters expected by the shader thread task; 2. Data format specification, this information describes the original storage format of the first attribute data in memory, guiding the interpolator on how to decode the acquired byte stream into a computable numerical value. It can typically include: 1) Data type: indicating the basic building block of the data, such as a 32-bit signed / unsigned integer, a 16-bit or 32-bit floating-point number; 2) Component composition: defining how many components the data contains (such as a scalar, a 2D vector, a 3D vector or a 4D vector); 3) Encoding and normalization method: specifying whether the integer group data needs to be normalized to a specific floating-point range, such as normalizing an 8-bit unsigned integer [0, 255] to a floating-point number [0.0, 1.0]. According to this specification, the interpolator parses, converts, and assembles the read raw bytes into a complete vector, preparing operands with the correct format for subsequent interpolation calculations; 3. Data precision and processing hints: In some implementations, the type information may also include hints about data precision. For example, it may indicate that certain properties (such as normal vectors used for lighting) require high-precision interpolation, while other properties (such as certain auxiliary colors) can use a lower-precision calculation mode to save power. Through the above type information, the interpolator can not only perform numerical interpolation but also ensure the consistency and correctness of data format and semantics throughout the rendering pipeline. It is worth noting that the description and specific composition of the above type information are merely illustrative examples, and the scope of protection of this application is not limited thereto.

[0100] In some embodiments, the second attribute table (such as...) Figure 4The second attribute table (420) is a structured data table whose core function is to define a complete set of control information for a group of logically related first attribute data in the rendering pipeline. For example, this table describes a "resource configuration template" for a set of attributes, rather than vertex attributes specific to a particular primitive. This design enables the reuse of attribute configurations, allowing multiple primitives with the same attribute requirements (such as using the same shader or vertex format) to share the same second attribute table. For example, as... Figure 4 As shown, the second attribute table 420 contains multiple sets of control information, each set uniquely corresponding to a first attribute data (for example, first attribute data 1 might correspond to a position, first attribute data 2 to a normal, and first attribute data 3 to texture coordinates). For each first attribute data, its corresponding control information can include the following three types of information: 1. Storage location information of the first attribute data, which provides an independent set of addressing parameters for each attribute in the attribute group. In hardware implementation, this is represented as an array of attribute addressing parameters. Each array element contains the base address (or descriptor index), offset, and step size of the corresponding attribute. When the interpolator processes multiple attributes in parallel, it can access the addressing parameters of multiple attributes simultaneously through the attribute index and calculate the effective addresses of multiple attributes in parallel through independent address generation units; 2. Interpolation instructions used to instruct interpolation calculations. This part is organized into an array of interpolation control words in the second attribute table, with each control word corresponding to the interpolation configuration of an attribute. In hardware implementation, these control words can be pre-loaded into the configuration register of the interpolator. When processing specific fragments, the interpolator simultaneously enables multiple interpolation calculation units based on the fragment's type (such as whether it is on the edge) and attribute characteristics. Each unit performs interpolation calculations in different modes, such as perspective correction, linear interpolation, or planar shading, according to its respective control word configuration. 3. The type information of the first attribute data is organized into an array of type descriptors in the second attribute table. Each descriptor explicitly specifies the data format, component composition, and shader input association of the corresponding attribute.

[0101] It is worth noting that the specific structure of the second attribute table and its interaction mechanism with the hardware unit described above are merely illustrative examples. Any technical solution that can organize control information of multiple attributes into a unified data structure and obtain first attribute data and perform interpolation calculations by providing control information for interpolator access by attribute, regardless of whether it uses an array, linked list, or other data structure, falls within the protection scope of the embodiments of this application.

[0102] By constructing a hierarchical attribute table structure, a complete technical support is provided for the interpolator to achieve efficient and autonomous data acquisition and interpolation calculation. First, the interpolator can independently complete the entire process without relying on the fragment shader constructor, using only the first and second attribute tables. Specifically, the fixed-length attribute header in the first attribute table greatly reduces the amount of data transmitted between the rasterizer and the interpolator, enabling rapid transmission and accurate mapping of attribute control information. Second, the second attribute table, through integrated storage location information, interpolation instructions, and type information, provides the interpolator with the complete set of control logic required from data location and acquisition to interpolation calculation and result distribution. This design allows the address generation unit inside the interpolator to achieve direct location based on a preset pipeline, and multiple interpolation calculation units can execute interpolation operations on different fragments in parallel, improving the throughput and computational efficiency of the interpolation operation.

[0103] In some embodiments, the interpolator performs interpolation calculations based on the first attribute data to generate the second attribute data, including: the interpolator classifies the first attribute data according to the type information in the control information; the interpolator performs interpolation calculations on the classified first attribute data according to the interpolation instructions in the control information to generate the second attribute data.

[0104] In one aspect of this embodiment, the interpolator performs interpolation calculations based on the acquired first attribute data to generate second attribute data for use by the fragment shader. The execution of this process depends on control information recorded in the second attribute table. Specifically, this may include: first, the interpolator classifies and formats the first attribute data according to type information in the control information. Specifically, the interpolator reads the predefined type descriptor for each attribute in the second attribute table and parses the acquired raw byte stream into a normalized data vector according to the data format specified therein. In some embodiments, the shader input register address included in the type information establishes a semantic classification identifier for each attribute. Specifically, in the graphics rendering pipeline, the fragment shader program predefines a list of input parameters, each parameter having its specific data type and rendering semantics. For example, a fragment shader might expect to receive second attribute data of type world space location in register 0, second attribute data of type normal vector in register 1, and second attribute data of type texture coordinates in register 2. The shader input register address in the second attribute table serves as the bridge binding the aforementioned second attribute data to a specific input parameter expected by the fragment shader program. For example, when the interpolator reads the type information of an attribute and finds that its shader input register address is set to 1, it not only knows which logical location to store the data in, but more importantly, it indirectly learns through this address that the final use of the data is a normal vector. This binding relationship allows the interpolator to perform more direct preprocessing and classification. The interpolator does not need to understand high-level semantics such as "normal," but only needs to follow a simple rule: all first attribute data pointing to the same register address belongs to the same semantic category and may require consistent processing. Therefore, through the shader input register address, the interpolator can effectively distribute the acquired first attribute data to different logical channels. For example, all data marked as being sent to register 2 (texture coordinates) can be identified as a category requiring perspective correction interpolation; while all data marked as being sent to another register (such as depth values) may be identified as another category requiring linear interpolation.

[0105] In one aspect of this embodiment, after acquiring and classifying the first attribute data, the interpolator enters the core interpolation calculation stage. This stage strictly follows the interpolation instructions predefined for each attribute in the second attribute table, converting the first attribute data of the three vertices (taking a triangle primitive as an example) into the second attribute data of each fragment. Exemplarily, the interpolator internally includes one or more interpolation calculation units, which perform corresponding interpolation operations according to different modes of the interpolation instructions. Specifically, exemplarily, this may include: 1. Perspective correction: When the interpolation instruction is specified as perspective correction, the interpolator first configures its internal perspective correction calculation unit. This unit receives the attribute data vectors of the three vertices and their corresponding depth reciprocals, and simultaneously obtains the screen space centroid coordinates (α, β, γ) of the current fragment. The calculation unit performs two levels of operations: first, depth correction is performed on the attribute data by dividing the attribute value of each vertex by its corresponding depth value; then, linear interpolation is performed using the centroid coordinates; finally, the interpolation result is multiplied by the depth value of the current fragment to complete the perspective correction process. This series of operations ensures that attributes such as texture coordinates and color maintain the correct spatial relationships under perspective projection; 2. Linear interpolation: For the first attribute data marked as linear interpolation, the interpolator enables a simplified linear multiply-accumulate unit. This unit directly uses the barycentric coordinates (α, β, γ) in screen space to perform a linear weighted average of the first attribute data (A0, A1, A2) of the three vertices. The calculation process does not involve depth correction, but only performs the basic operation: second attribute data = αA0 + βA1 + γA2, which is suitable for attributes that change linearly in screen space, such as window coordinates; 3. Planar shading: When the instruction is specified as planar shading, the interpolator controls the internal multiplexer to directly connect the data path to the attribute data output of the first vertex. In this mode, the interpolator completely bypasses all computation units, directly copying the attribute value of the first vertex (e.g., vertex 0) in the primitive to the corresponding output channels of all fragments; 4. Default value handling: If the use default value flag in the interpolation instruction is set, the interpolator will initiate a special processing procedure: immediately suspending the normal calculation path of the current attribute and instead reading the pre-configured value from the internal default value register file. These default values ​​are set by the driver according to the attribute type during the pipeline initialization phase, such as color attributes being set to pure white, texture coordinates being set to (0, 0), etc. This mechanism ensures that the rendering pipeline can continue to work normally even if the first attribute data is missing or the binding is abnormal.

[0106] For example, through the interpolation calculation process controlled by the control information described above, the interpolator converts first attribute data (vertex attributes) belonging to the same primitive into a series of second attribute data (fragment attributes) corresponding to the fragments generated from that primitive. It is worth noting that the process by which the interpolator performs interpolation calculations on the first attribute data based on the control information to generate the second attribute data is merely an illustrative example. Any core inventive concept that enables the interpolator to independently complete interpolation calculations driven by control information falls within the protection scope of the embodiments of this application.

[0107] In one aspect of this embodiment, the second attribute data is a set of fragment-level attribute data generated by the interpolator after performing interpolation calculations on the first attribute data. This data set serves as a bridge connecting the interpolation stage and the fragment shading stage, and its content and organization are strictly defined by the type information in the control information. For example, the second attribute data may include: 1. Attribute values, which are the actual attribute values ​​obtained through interpolation calculations, such as the final color value, texture coordinates, normal vector, tangent vector, and other custom shader parameters for each fragment. These values ​​have been standardized according to the data format specified in the type information; 2. Semantic identifiers, each attribute in the second attribute data implicitly or explicitly carries its semantic identifier. This identifier originates from the shader input register address defined in the type information, ensuring that each interpolation result can be uniquely associated with a specific input parameter expected by the fragment shader program (e.g., register 1 corresponds to reflection color, register 2 corresponds to texture coordinates); 3. Primitive and fragment association information, the second attribute data is associated with specific primitives and fragments during generation and storage. This association allows each second attribute data block to be uniquely indexed and located using primitive identifiers and fragment location identifiers (such as pixel coordinates or fragment IDs). For example, in physical storage, the second attribute data can be stored as a structured data packet, where each attribute is arranged according to its predefined shader input register address order. This organization allows subsequent stages to efficiently retrieve and process this data using a unified access mode. It is worth noting that the second attribute data itself does not contain any computational logic or instructions; it is purely a collection of interpolation results, the structure and content of which are entirely predetermined by the control information in the second attribute table, ensuring consistency and accuracy in data transfer throughout the rendering pipeline.

[0108] Through the control information (including type information, interpolation instructions, and storage location information) in the second attribute table, the interpolator obtains all the operational specifications required to perform interpolation calculations. Storage location information ensures that the interpolator accurately acquires the first attribute data corresponding to the vertices of the target primitive; type information ensures correct parsing and semantic classification of the first vertex attribute data; and interpolation instructions specify the most suitable calculation mode (such as perspective correction, linear interpolation, etc.) for each type of attribute. This control mechanism guarantees the accuracy of interpolation calculations, laying a solid foundation for high-quality graphics rendering results. Secondly, the interpolator's autonomous operation mode based on control information eliminates its dependence on the fragment shader constructor. The interpolator only needs to locate the second attribute table based on the first information to obtain complete operation instructions, and then independently complete the entire process from data parsing and format conversion to interpolation calculations. This architecture breaks the serial bottleneck in the traditional rendering pipeline where the interpolation stage must wait for thread construction to complete, achieving true parallel processing. In summary, the technical solution provided in this application achieves autonomy and parallelism in the interpolator's interpolation calculations while ensuring rendering accuracy.

[0109] In some embodiments, the second information includes fragment location information, which is used to indicate the positional distribution of the target fragments in the target primitives.

[0110] In one aspect of this embodiment, the primitive information is consistent with the primitive information in the first information received by the interpolator, and is used to uniquely indicate the vertex corresponding to the target primitive being processed. In this embodiment, the primitive index is used as the core of the primitive information, and this index is used to accurately locate the set of vertices constituting the target primitive in the global primitive list. The aforementioned primitive information is also the basis for subsequently associating the second attribute data and ensuring that the correct data is used in the fragment shading calculation.

[0111] In one aspect of this embodiment, the core function of fragment location information is to indicate the positional distribution of target fragments within target primitives. Exemplarily, fragment location information may include, but is not limited to: 1. A pixel coverage mask, which is a two-dimensional bitmap where each bit represents a specific pixel position in screen space. A bit value of '1' indicates that the pixel is covered by a primitive. The fragment shader constructor can accurately and efficiently determine the total number of fragments to be processed by quickly traversing and counting the number of '1's in the bitmap. This is the direct basis for allocating shader register resources and creating corresponding shader thread tasks; 2. Pixel quadrilateral information, which divides the screen space into pixel blocks of a preset size (e.g., 2x2) for processing. It serves two main purposes: First, it defines the basic unit for calculating the screen space derivative, allowing the fragment shader constructor to know which adjacent fragments need to be grouped to ensure correct gradient calculation. Secondly, it provides a coarse-grained task packaging method, allowing the fragment shader constructor to organize threads by pixel quadrilaterals rather than individual pixels, which helps reduce task scheduling overhead and optimize computational consistency; 3. Multisampling information: When multisampling anti-aliasing is enabled, this information records which sub-sampling points within each pixel are covered by the target primitive. This enables the fragment shader constructor to identify all target fragments that need to be shaded independently, thereby allocating corresponding resources and generating threads, ensuring that no fragments that need to be computed are missed in anti-aliasing scenarios; 4. Fragment space identifier list: This is a more direct representation, providing a list that explicitly lists the screen space coordinates (X, Y) of each fragment and its possible sub-sampling point indices. This method provides the fragment shader constructor with a detailed fragment distribution map, enabling it to accurately generate shader thread tasks for each target fragment; 5. Hierarchical block descriptor: For large-area target primitives, this information spatially divides the target primitive's coverage area into multiple blocks of different levels or sizes and describes the distribution of these blocks. The fragment shader constructor can utilize this information for hierarchical load distribution. For example, it can prioritize allocating more computing resources to larger blocks or assign different blocks to different computing units for parallel processing, thereby achieving load balancing. Through one or more of the above information, fragment location information can provide the fragment shader constructor with instructions ranging from macroscopic (total quantity, range) to microscopic (precise location), and from routine processing to special optimizations (such as the aforementioned MSAA), enabling it to efficiently generate shader thread tasks and configure computing resources. It is worth noting that the above enumeration of the specific composition of fragment location information is merely illustrative, and the scope of protection for fragment location information in this application is not limited thereto. Any data format capable of indicating the quantitative characteristics of fragment spatial distribution falls within the protection scope of the embodiments of this application.

[0112] By using primitive information and fragment location information, complete input information is provided to the fragment shader constructor. Specifically, primitive information, through primitive indexing and other methods, ensures that the constructor can uniquely and correctly associate with the target primitive, clarifying the source object of the target fragment being processed; while fragment location information, through diverse data formats, accurately describes the specific distribution of the rasterized fragment set within the screen space and its respective primitive. The combination of these two types of information allows the fragment shader constructor to clearly grasp which fragments need to be processed and where the fragments are specifically located at the initial stage of generating shader thread tasks. The technical solution provided in this application embodiment enables the fragment shader constructor to directly and accurately establish a complete mapping relationship from primitives to fragments and then to shader thread tasks without relying on indirect forwarding from other modules or complex calculations, providing the necessary data input for subsequent allocation of computing resources and generation of shader thread tasks.

[0113] In some embodiments, fragment location information includes pixel sampling point information and pixel quadrilaterals. The fragment shader constructor generates shader thread tasks based on the second information, including: determining the spatial range of the target fragment based on the pixel quadrilaterals; determining the number of target fragments based on the spatial range of the target fragments and the pixel sampling point information; allocating multiple shader registers corresponding to the target fragments based on the number of target fragments, the shader registers being used to store the second attribute data; and generating shader thread tasks corresponding to the target fragments based on the allocated shader registers.

[0114] In one aspect of this embodiment, the core function of the fragment shader constructor is to convert the geometric information generated by rasterization into parallel tasks that can be efficiently executed by the computational units, and to ensure that the aforementioned parallel tasks can be correctly associated with the second attribute data generated by the interpolator. Specifically, the fragment shader constructor first parses the pixel quadrilateral information in the second information. Pixel quadrilaterals define the most basic processing unit block (usually 2x2 pixels) in the screen space. The fragment shader constructor quickly determines the spatial range of the target fragment by identifying all pixel quadrilaterals that are covered or partially covered by the target primitive. Based on this, the constructor can further perform task partitioning optimization: according to the system architecture (such as the number of computational units and cache size), the entire coverage area is divided into multiple sub-regions. Each sub-region contains a set of continuous pixel quadrilaterals, serving as an independent scheduling unit.

[0115] In one aspect of this embodiment, after defining the spatial range, the fragment shader constructor precisely quantifies the task load by combining pixel sampling point information, i.e., determining the number of target fragments. This process is based on two types of key data: pixel coverage mask and multisampling data. Specifically, the pixel coverage mask serves as a first-level index, identifying in bitmap form which pixels within the spatial range are at least partially covered by the primitive; the multisampling data serves as a second-level index, precisely describing the specific coverage state of each sub-sampling point within each covered pixel. The constructor's control logic sequentially traverses each pixel position within the spatial range: first, it queries the pixel coverage mask; if the corresponding bit is invalid, it skips it directly; otherwise, if it is valid, it further parses the multisampling bitmap of the pixel, quickly counting the number of set bits through bit operations. This value is the exact number of fragments to be generated within the pixel. By accumulating the statistical results of all covered pixels after traversal, the total number of target fragments corresponding to the current primitive can be obtained.

[0116] For example, suppose a triangular primitive, after rasterization, has a coverage area defined as a 2x2 pixel quadrilateral, and the system enables 4x multisampling anti-aliasing. A given pixel coverage mask shows that three pixels within this area are covered (bitmap values ​​of 11; 10), while the multisampling data further reveals the detailed coverage of each pixel: the first pixel's subsampled point coverage pattern is 1100 (corresponding to 2 effective fragments), the second pixel is 1010 (corresponding to 2 effective fragments), and the third pixel is 1111 (corresponding to 4 effective fragments). The constructor iterates through these three pixels according to a predetermined process, counts the effective fragments for each pixel, and then performs an accumulation calculation: 2 + 2 + 4 = 8. The final output target fragment count is 8, accurately reflecting the number of shader thread tasks that need to be created, ensuring the accuracy of subsequent register allocation and task generation.

[0117] In one aspect of this embodiment, after accurately quantifying the task load, the fragment shader constructor enters the crucial resource allocation phase. The core task of this phase is to allocate a dedicated shader register for each target fragment based on the determined number of target fragments and to establish an efficient data routing mechanism. Specifically, the fragment shader constructor first initiates a batch allocation request to a unified register stack management unit. This request explicitly includes the total number of registers required (i.e., the number of target fragments × the size of the register stack required for each fragment). It is worth noting that this allocation process is not a simple average allocation but introduces a shading complexity prediction mechanism. For example, for fragment shaders performing complex calculations involving complex lighting models and multiple texture samples, the constructor allocates more register stacks for each corresponding target fragment to ensure sufficient storage space for temporary variables and intermediate results, avoiding register overflow during execution. Conversely, for fragment shaders performing simple color transfer or texture sampling calculations, a simplified register allocation scheme is adopted to improve the overall utilization of register resources.

[0118] In some embodiments, after allocating shader register resources, the fragment shader constructor synchronously constructs a crucial data routing map. This map serves as a data bridge connecting the interpolator and the fragment shader execution unit. The constructor creates an entry in the map for each target fragment, explicitly recording the starting address of the shader register allocated to that fragment and logically binding this address to the second attribute data to be output by the interpolator. More specifically, the map defines the specific offset within the target register set where each attribute (such as position, normal, or texture coordinate) in the second attribute data should be stored. This design allows subsequent fragment shaders, when scheduled for execution, to access all their input attributes accurately without needing to know the physical source of the second attribute data, simply through a unified, predefined register address offset scheme.

[0119] In one aspect of this embodiment, after the allocation of shader registers is completed, the fragment shader constructor enters the final task encapsulation stage. The core objective of this stage is to integrate all the preliminary work and generate a shader thread task that can be directly scheduled and executed by the fragment shader. For example, each shader thread task may include the following key information: 1. Execution context, containing a pointer to a specific shader program code segment and the base address of the constant buffer required for the program's execution, providing a complete code and environment context for the shader thread task execution; 2. Data descriptor, explicitly specifying the range of shader register addresses allocated to the shader thread task, which strictly corresponds to the records in the data routing map, ensuring that the thread can accurately access its dedicated input data (second attribute data); 3. Spatial identifier, containing pixel coordinates, sample point index, and primitive identifier, uniquely determining the spatial location and geometric origin of the target fragment in the rendering target (i.e., the corresponding target primitive), which is the cornerstone of ensuring the correctness of the rendering result; 4. Scheduling attributes, containing priority flags determined by the driver or system, and computational resource requirements based on shader complexity prediction (such as estimated execution cycle), providing the thread scheduler with intelligent scheduling basis.

[0120] In some embodiments, after generating all shader thread tasks, the fragment shader constructor performs final task packaging and submission optimization. The core objective of this stage is to organize discrete thread tasks into efficient data packets suitable for hardware parallel execution. Specifically, the fragment shader constructor optimally groups and packages tasks according to the wavefront size or thread bundle dimension of the target architecture, ensuring that each submitted computation packet can fully utilize the parallel processing capabilities of the computation units (i.e., fragment shaders). During the packaging process, the constructor pays special attention to the spatial locality of tasks, prioritizing the packaging of fragment tasks of adjacent pixels in screen space into the same group. This spatial proximity-based grouping strategy can significantly improve the cache hit rate of subsequent texture sampling operations and reduce memory access latency. In some embodiments, the optimized and packaged thread groups are submitted to the thread task scheduler. The thread task scheduler, as the central hub of the task execution pipeline, is responsible for receiving task packets from the fragment shader constructor and dynamically allocating them to the various computation units of the fragment shader for execution according to the built-in scheduling strategy. The thread task scheduler uses a preset algorithm to intelligently distribute tasks based on the priority flags carried in each task package and the real-time load of the current system. This achieves a balanced distribution of computing load among the computing units, avoiding situations where some computing units are idle while others are overloaded, thereby maximizing the throughput of the entire fragment shader stage.

[0121] It is worth noting that the specific implementation of the fragment shader constructor generating shader thread tasks based on the second information is not limited to the above embodiments. Any technical solution that uses primitive information and fragment position information to complete the generation of shader thread tasks and the allocation of computing resources, regardless of its specific data structure, processing flow, or optimization strategy, falls within the protection scope of the embodiments of this application as long as it realizes the core inventive idea that the fragment shader constructor is independent of the vertex attribute data processing flow.

[0122] By enabling the fragment shader constructor to independently generate shader thread tasks and allocate resources based on the second information, it can start working in parallel without waiting for the first attribute data (i.e., vertex attribute data). The fragment shader constructor accurately quantifies the task size based on pixel quadrilaterals and sampling point information and allocates the corresponding shader registers. At the same time, it uses primitive identifiers to establish a logical association with the second attribute data generated by the interpolator. The technical solution proposed in this application not only eliminates the timing bottleneck caused by waiting for vertex attribute data, but also ensures that the parallel-generated thread tasks can accurately match the attribute data output by the interpolator through the identifier mapping mechanism, ultimately improving the throughput efficiency of the graphics rendering pipeline while maintaining rendering correctness.

[0123] In some embodiments, the second information includes primitive information, which is used to indicate the vertices constituting the target primitives, and the rendering method further includes: The fragment shader constructor generates a task index for the shader thread task corresponding to the target fragment based on the primitive information, and sends the task index to the interpolator. The task index includes a primitive identifier, a fragment position identifier, and a shader register address. The primitive identifier is determined by the primitive information and indicates the target primitive corresponding to the target fragment. The fragment position identifier determines the position of the target fragment, and the shader register address indicates the shader register corresponding to the target fragment. The interpolator determines the second attribute data corresponding to the target fragment based on the primitive identifier and the fragment position identifier. The interpolator then sends the task index and the second attribute data corresponding to the target fragment to the fragment shader.

[0124] In one aspect of this embodiment, the primitive information is consistent with the primitive information in the first information received by the interpolator, and is used to uniquely indicate the vertex corresponding to the target primitive being processed. In this embodiment, the primitive index is used as the core of the primitive information, and this index is used to accurately locate the set of vertices constituting the target primitive in the global primitive list. The aforementioned primitive information is also the basis for subsequently associating the second attribute data and ensuring that the correct data is used in the fragment shading calculation.

[0125] This application describes a specific mechanism for data collaboration between the fragment shader constructor and the interpolator through task indexing. The core of this mechanism lies in establishing a precise matching relationship between the shader thread task and the second attribute data, ensuring that the computation task can obtain the correct input data.

[0126] In one aspect of this embodiment, after generating shader thread tasks, the fragment shader constructor generates a unique task index for each shader thread task. The task index generation process can be based on the complete context contained in the primitive information in the second information: the fragment shader constructor first extracts the primitive identifier from the primitive information, parses the fragment position identifier from the fragment position information, and combines this with the previously allocated shader register address to encapsulate this information into a complete task index data structure. This process is completed internally by a dedicated index generation unit, which assembles the three key fields into a data packet that can be efficiently transmitted between modules according to a fixed format. Specifically, the aforementioned task index data structure may include the following key fields: 1. Primitive Identifier Field: stores the identifier of the target primitive corresponding to the target fragment, ensuring the correct association between the interpolation result and the original geometric data; 2. Spatial Positioning Field: contains precise positioning information such as pixel coordinates and sampling point index, establishing a mapping relationship between the shader thread task and screen space; 3. Resource Reference Field: stores the allocated shader register address range, providing addressing basis for data matching; 4. Version Control Field: contains a generation timestamp or sequence number, used to process multiple fragment shading tasks at the same location. Exemplarily, the generated task index can be sent to the thread task scheduler as a key component of the task descriptor, guiding the scheduling and execution between different shader thread tasks; it can also be sent to the interpolator as guidance information for data matching, ensuring that the second attribute data matches the corresponding shader thread task. It is worth noting that the specific implementation of the above task index generation mechanism, including field composition, generation process, and transmission path, are all illustrative examples. Any technical solution capable of identifying shader thread tasks and establishing a correct association with the second attribute data falls within the protection scope of this application.

[0127] In one aspect of this embodiment, the task index, as a complete data structure, is a key link connecting the fragment shader constructor, interpolator, and fragment shader. Exemplarily, the above data structure may include the following three core fields: 1. Primitive Identifier: This field is an identification information strictly corresponding to primitive information. Its core function is to establish a reverse mapping from the shader thread task to the original geometric data, enabling the interpolator to accurately identify the target fragment corresponding to the current shader thread task, thereby locating the correct fragment attribute dataset (second attribute data); 2. Fragment Position Identifier: This field encodes the fragment's position in screen space and its relative positional relationship within the primitive, and can adopt various optimized representation forms. Exemplarily, it may include: 1) Composite coordinate representation: including pixel coordinates (X, Y), sub-pixel offsets (Δx, Δy), and multisampling index; 2) Normalized barycentric coordinates: barycentric coordinates stored in fixed-point format, which can be directly used for matching. The fragment position identifiers mentioned above enable the interpolator to reproduce the relative position of the target fragment within the corresponding target primitive; 3. Shader register address, this field is a direct address reference to a specific hardware resource. For example, it may include: 1) a register file base address, which points to the starting position of a register group in the fragment shader register file; 2) a register offset, determining the precise offset of the target register within the aforementioned register group; 3) a data layout description, containing auxiliary information such as data step size and alignment requirements to ensure compliance of data writing. The aforementioned shader register address is determined when the fragment shader constructor allocates registers. By specifying the storage location of the second attribute data in the fragment shader register file, it ensures that the interpolator's output data (i.e., the second attribute data) can be correctly accessed and used in subsequent shading stages.

[0128] In one aspect of this embodiment, upon receiving the task index from the fragment shader constructor, the interpolator immediately initiates an efficient and precise data retrieval and assembly process. This process fully utilizes the three pieces of information included in the task index: the primitive identifier, the fragment location identifier, and the shader register address, to achieve precise matching between the second attribute data and the shader thread task. For example, during the data retrieval phase, the interpolator first reads the identifier field in the task index and searches for the corresponding data block in its internally maintained cache. This cache is organized according to the primitive identifier, with each entry storing the second attribute data of all fragments of a complete primitive. Since the interpolator and constructor work in parallel, when the index arrives, the corresponding data block has typically already been calculated and resides in the intermediate cache. Next, the interpolator uses the fragment location identifier in the task index to precisely locate the second attribute data of the specific target fragment from the found data block. For example, if the identifier uses composite coordinates (such as pixel coordinates + sampling point index), it is directly used as the address offset to calculate the precise position in the data array and index the corresponding second attribute data; if the identifier uses normalized barycentric coordinates, it is input into a dedicated interpolation calculation unit in the interpolator. This unit combines the cached first attribute data and quickly reproduces the precise attribute value of the fragment, i.e., the second attribute data, through multiplication and addition operations.

[0129] In one aspect of this embodiment, after successfully retrieving the second attribute data corresponding to the target fragment, the interpolator also needs to perform the following operations: 1. Data verification and formatting: The data verification circuit checks the integrity and validity of the retrieved second attribute data. Simultaneously, based on the pre-configured data format descriptor, the data undergoes necessary alignment and formatting to ensure it meets the input requirements of the fragment shader; 2. Address resolution and binding: The shader register address in the task index is read, converted into a specific physical register number using an address decoder, and a hardware write enable association is established with the data; 3. Message assembly optimization: The formatted second attribute data, the parsed shader register address, the data validity flag, and timing control information are assembled into a fixed-length data message unit; 4. Directed transmission scheduling: The above data message unit is directly sent to the target computation unit (i.e., the computation unit in the fragment shader). The transmission process supports multi-path parallelism, and the data transmission of different computation units is independent of each other, avoiding resource contention and transmission bottlenecks.

[0130] It is worth noting that the specific implementation of the above-mentioned task index generation, transmission, and data matching mechanism is merely illustrative, and the scope of protection for the task index-based collaborative mechanism in this application is not limited to this. Any technical solution that establishes an association between shader thread tasks and second attribute data through task indexes, regardless of the changes in the data structure, transmission path, data retrieval method, or message assembly format of its task index, falls within the protection scope of the embodiments of this application as long as it implements the core inventive idea of ​​matching the second attribute data generated by the interpolator with the shader thread tasks generated by the fragment shader constructor through the task index.

[0131] A task indexing mechanism is introduced to establish a precise collaborative bridge between the fragment shader constructor and the interpolator, two components that execute in parallel. The task index, as structured data carrying identification information, enables accurate matching between the independently generated shader thread tasks and the second attribute data based on shared primitive identifiers and fragment position information. This design ensures that the performance advantages of parallel processing are fully utilized while guaranteeing the correctness of the subsequent rendering process. When the interpolator accurately writes the second attribute data to the register address indicated by the task index, the fragment shader can immediately begin executing the corresponding calculation task, achieving a seamless connection from data preparation to calculation execution. This maintains system parallelism while ensuring the accuracy of the final rendering result.

[0132] In some embodiments, the fragment shader executes a shader thread task based on the second attribute data to generate the shaded target fragment, including: the fragment shader stores the second attribute data into the shader register corresponding to the target fragment according to the shader register address contained in the task index; the fragment shader executes the shader thread task to read the second attribute data in the shader register and generate the shaded target fragment.

[0133] In one aspect of this embodiment, after receiving a data packet (including task index and second attribute data) from the interpolator, the fragment shader initiates a data loading process. Exemplarily, this may specifically include: 1. Data Packet Parsing: The input processing unit of the fragment shader first parses the data packet header, extracts the task index and payload boundary, and identifies the type and quantity of the second attribute data contained in the data packet.

[0134] 2. Address Resolution and Verification: Based on the shader register address in the task index, the fragment shader's memory management unit maps the logical address to the physical register location in the fragment shader register file through the address decoding circuit. This unit simultaneously verifies the address's validity, ensuring it falls within the legal register address range allocated to the current shader thread task, and checks the target register's readiness status to avoid data conflicts during the write process.

[0135] 3. Parallel Data Writing: After address verification, the fragment shader writes the second attribute data to the resolved physical register locations via multiple parallel data paths. Specifically, this process distributes different types of second attribute data to their dedicated register sets: for example, position data is written to the position property register set, normal vectors are written to the normal property register, texture coordinates are written to the texture sampling register, and color information is written to the color calculation register. This parallel data writing mechanism ensures that various attribute data can be quickly and accurately placed in the specified locations that the fragment shader's computation unit can directly access, preparing the data for subsequent shading calculations.

[0136] In one aspect of this embodiment, after the register loading of the second attribute data is completed, the fragment shader initiates the shading calculation process. Exemplarily, this shading calculation process may specifically include: 1. Execution Environment Initialization: The fragment shader first completes the final configuration of the execution environment based on the context information contained in the task index. This includes loading the corresponding shader program code from the instruction cache into the execution unit, establishing an accurate mapping with the constant buffer, and initializing the temporary register set used for storing intermediate results.

[0137] 2. Data Reading and Distribution: After the shader program begins execution, the computation unit reads the required second attribute data from the ready shader registers through a unified register file interface. The read data is distributed to different dedicated computation pipelines according to its type and computational requirements: for example, texture coordinates are sent to the texture sampling unit, normal vectors are sent to the lighting calculation unit, and basic color values ​​are sent to the color blending unit.

[0138] 3. Parallel Shading Computation: Each computation unit executes a specific shading algorithm in parallel based on the received second attribute data. This process may involve obtaining texels from texture coordinates and performing filtering in the texture sampling pipeline, performing complex lighting model calculations (such as physically based rendering) based on normals and material properties in the lighting computation unit, and performing operations such as color blending and transparency calculations in the arithmetic logic unit. Multiple computation units work collaboratively in a Single Instruction Multiple Data (SIMD) manner, processing multiple data components simultaneously.

[0139] 4. Result Integration and Output: Intermediate results from each computational pipeline are collected in the result integration unit. This unit performs final color value blending, depth testing, and possible stencil testing. After passing the tests, the final pixel color values ​​are generated, along with auxiliary information such as depth, organized into a data packet conforming to the rendering target format, and output to the subsequent blending / write stages of the rendering pipeline, thereby completing the generation of the shaded target fragments.

[0140] It is worth noting that the above fragment shader executes shader thread tasks based on the second attribute data to generate the shaded target fragment, including the parallel data writing mechanism in the data loading process and the multi-pipeline parallel computing mode in the shading calculation process, etc., are only illustrative examples.

[0141] By enabling the fragment shader to precisely store the second attribute data into a dedicated register allocated to that fragment based on the shader register address carried in the task index, the following technical effects are achieved: First, it ensures that each shader thread task, during execution, can read the completely matching second attribute data from its dedicated, predefined register location. This precise data location and loading mechanism fundamentally avoids misalignment or confusion of attribute data between different fragments, guaranteeing the accuracy and consistency of the input data for shading calculations. Simultaneously, by decoupling data preparation (register writing) from computation execution (shading calculations) and establishing an independent register mapping for each fragment, the fragment shader can execute complex shading algorithms without waiting for data retrieval or worrying about data conflicts. This allows it to fully leverage the advantages of its parallel computing architecture, perform efficient computations, and ultimately generate accurately shaded target fragments.

[0142] In some embodiments, the rasterizer performs depth testing and / or hidden face removal on the rasterized data to generate first information and second information. The depth testing and / or hidden face removal are used to cull occluded fragments and determine the target fragment.

[0143] In one aspect of this embodiment, the rasterizer performs an early depth test on the rasterized data to generate first and second information. Specifically, the rasterizer integrates a depth testing unit that immediately accesses the depth buffer after rasterization and compares the currently generated fragment depth value with the depth value stored at the corresponding position in the depth buffer. According to a preset depth testing function, if the current fragment is determined to be occluded, the fragment is marked as culled and will not be included in the subsequently generated second information; only fragments that pass the depth test are determined as valid target fragments, and their relevant information is organized into the second information and sent to the fragment shader constructor. For example, regardless of whether a fragment passes the depth test, the first information of its primitive is sent by the rasterizer to the interpolator.

[0144] In one aspect of this embodiment, the rasterizer performs hidden surface removal on the rasterized data to generate first information and second information. Specifically, the rasterizer employs a tile-based rendering architecture, allocating primitives to various screen-space tiles after the geometry processing stage and sorting the primitives within each tile. By implementing algorithms such as depth pre-filling, the rasterizer can identify and cull completely occluded primitives or portions of primitives. Only those primitive portions that are likely to be visible in the final image are rasterized into target fragments, and their relevant information is organized into the second information and sent to the fragment shader constructor. Similarly, the first information of the relevant primitives is sent in parallel to the interpolator.

[0145] It is worth noting that the depth testing and hidden face removal in the embodiments of this application are merely illustrative examples of implementing the fragment culling function. Any functional unit or processing flow that can identify and cull occluded or invisible primitives through any algorithm or hardware mechanism during the rasterization stage or its subsequent stages, thereby reducing the number of fragments requiring subsequent processing, falls within the protection scope of the embodiments of this application.

[0146] By integrating early depth testing and / or hidden face removal modules into the rasterizer, occluded or invisible fragments can be effectively identified and culled early in the rendering pipeline, before the fragment shader constructor and interpolator begin parallel operation. This culling mechanism reduces the number of invalid fragments requiring subsequent processing, eliminating the need for the fragment shader constructor to create shader thread tasks for these invisible fragments, and avoiding unnecessary attribute fetching and interpolation calculations for these fragments by the interpolator. This optimization reduces the workload of the entire rendering pipeline at its source, saving valuable computational resources, register resources, and memory bandwidth, while also reducing power consumption during graphics rendering.

[0147] The rendering method proposed in this application sends first and second information to the interpolator and fragment shader constructor, respectively, via a rasterizer, thereby initiating two parallel processing flows. On one hand, upon receiving the first information, the interpolator immediately obtains the first attribute data based on the first information and performs interpolation calculations to generate the second attribute data. On the other hand, upon receiving the second information, the fragment shader constructor can simultaneously begin generating shader thread tasks for shading the target fragment based on the second information. Finally, the fragment shader executes the shader thread tasks based on the second attribute data to generate the shaded target fragment. This rendering method parallelizes the time-consuming processes of obtaining vertex attributes and generating shader thread tasks, shortening the waiting time before the fragment shader executes its shader thread tasks and improving the efficiency of graphics rendering.

[0148] The following will use system embodiments to describe in detail the technical solutions provided in the embodiments of this application. For content not described in the system embodiments, please refer to the above method embodiments, which will not be repeated here.

[0149] Please refer to Figure 5 , Figure 5 This is a schematic diagram of a rendering system provided in one possible implementation of this application. The rendering system includes: a rasterizer 510, a fragment shader constructor 520, an interpolator 530, and a fragment shader 540.

[0150] Rasterizer 510 is used to send first information to interpolator 530 and second information to fragment shader constructor 520. The first information indicates first attribute data, which in turn indicates the vertex attributes of the target primitive; the second information indicates the positional distribution of the target fragments within the target primitive, where the target fragments are multiple fragments generated after rasterization of the target primitive.

[0151] Interpolator 530 is used to obtain first attribute data based on first information, and perform interpolation calculations based on the first attribute data to generate second attribute data. The second attribute data is the fragment attribute data obtained after performing interpolation calculations on the first attribute data.

[0152] Fragment shader constructor 520 is used to generate shader thread tasks based on the second information. The shader thread tasks are used to shade the target fragment.

[0153] Fragment shader 540 is used to execute shader thread tasks based on the second attribute data to generate shaded target fragments.

[0154] In some embodiments, the rendering system further includes a memory 550 and a thread task scheduler 560. The memory 550 is used to store first attribute data, and the thread task scheduler 560 is used to receive shader thread tasks from the fragment shader constructor and dynamically allocate the shader thread tasks to the various computing units of the fragment shader to perform fragment shading according to its built-in scheduling policy.

[0155] In some embodiments, the first information includes primitive information and a first attribute table. The primitive information indicates the vertices constituting the target primitive, and the first attribute table records the storage location information of the first attribute data.

[0156] In some embodiments, the interpolator is further configured to determine the vertices constituting the target primitive based on primitive information; and to obtain the first attribute data based on the storage location information of the first attribute data corresponding to the vertices constituting the target primitive.

[0157] In some embodiments, the first attribute table includes multiple attribute table headers. The attribute table headers are used to indicate their corresponding second attribute table; the second attribute table is used to record control information of the first attribute data, including: interpolation instructions for indicating interpolation calculations and type information of the first attribute data.

[0158] In some embodiments, the interpolator is further configured to classify the first attribute data according to the type information in the control information; and to perform interpolation calculation on the classified first attribute data according to the interpolation instructions in the control information to generate second attribute data.

[0159] In some embodiments, the second information includes fragment location information, which is used to indicate the positional distribution of the target fragments in the target primitives.

[0160] In some embodiments, fragment location information includes pixel sampling point information and pixel quadrilaterals. The fragment shader constructor is further configured to: determine the spatial extent of the target fragment based on the pixel quadrilaterals; determine the number of target fragments based on the spatial extent of the target fragments and the pixel sampling point information; allocate multiple shader registers corresponding to the target fragments based on the number of target fragments, the shader registers being used to store second attribute data; and generate shader thread tasks corresponding to the target fragments based on the allocated shader registers.

[0161] In some embodiments, the second information includes primitive information, which is used to indicate the vertices constituting the target primitive. The fragment shader constructor is further used to: generate a task index for the shader thread task corresponding to the target primitive based on the primitive information, and send the task index to the interpolator. The task index includes a primitive identifier, a fragment position identifier, and a shader register address. The primitive identifier is determined by the primitive information and is used to indicate the target primitive corresponding to the target fragment. The fragment position identifier is used to determine the position of the target fragment, and the shader register address is used to indicate the shader register corresponding to the target fragment. The interpolator is further used to: determine the second attribute data corresponding to the target fragment based on the primitive identifier and the fragment position identifier; and send the task index and the second attribute data corresponding to the target fragment to the fragment shader.

[0162] In some embodiments, the fragment shader is further configured to store the second attribute data into the shader register corresponding to the target fragment according to the shader register address contained in the task index; execute the shader thread task, read the second attribute data in the shader register, and generate the shaded target fragment.

[0163] In some embodiments, the rasterizer is further configured to perform depth testing and / or hidden face removal on the rasterized data to generate first information and second information, wherein the depth testing and / or hidden face removal is used to cull occluded fragments and determine target fragments.

[0164] For details not described in this embodiment, please refer to the method embodiment.

[0165] The rendering system proposed in this application sends first and second information to the interpolator and fragment shader constructor, respectively, via a rasterizer, thereby initiating two parallel processing flows. On one hand, upon receiving the first information, the interpolator immediately obtains the first attribute data based on the first information and performs interpolation calculations to generate the second attribute data. On the other hand, upon receiving the second information, the fragment shader constructor can simultaneously begin generating shader thread tasks for shading the target fragment based on the second information. Finally, the fragment shader executes the shader thread tasks based on the second attribute data to generate the shaded target fragment. This rendering system parallelizes the time-consuming processes of obtaining vertex attributes and generating shader thread tasks, shortening the waiting time before the fragment shader executes its shader thread tasks and improving the efficiency of graphics rendering.

[0166] In some embodiments, a GPU chip is also provided, which includes the rendering system described above.

[0167] For example, please refer to Figure 6 , Figure 6 This is a simplified structural block diagram of an electronic device provided in one possible implementation of this application. For example... Figure 6 As shown, the electronic device 600 includes the aforementioned GPU chip, which in turn includes the aforementioned rendering system. The electronic device 600 can be used to implement the rendering method applied to the rendering system provided in the above embodiments.

[0168] Typically, electronic device 600 includes a processor 610 and a memory 620.

[0169] Processor 610 may include one or more processing cores, such as a quad-core processor, a seven-core processor, etc. Processor 610 may be implemented using at least one hardware form selected from DSP, Field Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). Processor 610 may also include a main processor and a coprocessor. The main processor, also known as the CPU, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 610 may integrate a GPU, which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 610 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0170] The memory 620 may include one or more computer-readable storage media, which may be non-transitory. The memory 620 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 620 are used to store a computer program configured to be executed by one or more processors to implement the rendering method described above applied to the rendering system.

[0171] Those skilled in the art will understand that Figure 6 The structure shown does not constitute a limitation on the electronic device 600, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0172] In some embodiments, the electronic device 600 may be a server, a server cluster, an artificial intelligence computing cluster, a cloud computing cluster, etc., wherein the artificial intelligence computing cluster may also be simply referred to as an intelligent computing cluster or a smart computing cluster, and this application does not limit it in this regard.

[0173] It should be understood that "multiple" as mentioned herein refers to two or more. Furthermore, the step numbers described herein are merely illustrative of one possible order of execution. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this practice.

[0174] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A rendering method applied to a rendering system, characterized in that, The rendering system includes: a rasterizer, a fragment shader constructor, an interpolator, and a fragment shader; the method includes: The rasterizer sends first information to the interpolator and second information to the fragment shader constructor; wherein, the first information is used to indicate first attribute data, the first attribute data is used to indicate the vertex attributes of the target primitive; the second information is used to indicate the positional distribution of the target fragments in the target primitive, the target fragments being multiple fragments generated after the target primitive is rasterized; The interpolator obtains the first attribute data based on the first information, and performs interpolation calculation based on the first attribute data to generate second attribute data; wherein, the second attribute data is fragment attribute data obtained after performing the interpolation calculation on the first attribute data; The fragment shader constructor generates a shader thread task based on the second information, and the shader thread task is used to shade the target fragment. The fragment shader executes the shader thread task based on the second attribute data to generate the shaded target fragment.

2. The method according to claim 1, characterized in that, The first information includes primitive information and a first attribute table; wherein, the primitive information is used to indicate the vertices constituting the target primitive, and the first attribute table is used to record the storage location information of the first attribute data.

3. The method according to claim 2, characterized in that, The interpolator obtains the first attribute data based on the first information, including: The interpolator determines the vertices constituting the target primitive based on the primitive information; The interpolator obtains the first attribute data based on the storage location information of the first attribute data corresponding to the vertices constituting the target primitive.

4. The method according to claim 2, characterized in that, The first attribute table includes multiple attribute headers; The attribute header is used to indicate its corresponding second attribute table; The second attribute table is used to record control information of the first attribute data. The control information includes: interpolation instructions for instructing the interpolation calculation and type information of the first attribute data.

5. The method according to claim 4, characterized in that, The interpolator performs interpolation calculations based on the first attribute data to generate second attribute data, including: The interpolator classifies the first attribute data according to the type information in the control information; The interpolator performs the interpolation calculation on the classified first attribute data according to the interpolation instruction in the control information to generate the second attribute data.

6. The method according to claim 1, characterized in that, The second information includes fragment position information, which is used to indicate the positional distribution of the target fragment in the target primitive.

7. The method according to claim 6, characterized in that, The fragment location information includes pixel sampling point information and pixel quadrilaterals; The fragment shader constructor generates shader thread tasks based on the second information, including: The fragment shader constructor determines the spatial range of the target fragment based on the pixel quadrilateral; The fragment shader constructor determines the number of target fragments based on the spatial range of the target fragment and the pixel sampling point information; The fragment shader constructor allocates multiple shader registers corresponding to the target fragments based on the number of target fragments, and the shader registers are used to store the second attribute data; The fragment shader constructor generates the shader thread task corresponding to the target fragment based on the allocated shader register.

8. The method according to claim 1, characterized in that, The second information includes primitive information, which is used to indicate the vertices constituting the target primitive. The method further includes: The fragment shader constructor generates a task index for the shader thread task corresponding to the target primitive based on the primitive information, and sends the task index to the interpolator; wherein, the task index includes a primitive identifier, a fragment position identifier, and a shader register address, the primitive identifier is determined by the primitive information and is used to indicate the target primitive corresponding to the target fragment, the fragment position identifier is used to determine the position of the target fragment, and the shader register address is used to indicate the shader register corresponding to the target fragment; The interpolator determines the second attribute data corresponding to the target fragment based on the primitive identifier and the fragment position identifier; The interpolator sends the task index and the second attribute data corresponding to the target fragment to the fragment shader.

9. The method according to claim 8, characterized in that, The fragment shader, based on the second attribute data, executes the shader thread task to generate the shaded target fragment, including: The fragment shader stores the second attribute data into the shader register corresponding to the target fragment based on the shader register address contained in the task index. The fragment shader executes the shader thread task, reads the second attribute data in the shader register, and generates the shaded target fragment.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: The rasterizer performs depth testing and / or hidden face removal on the rasterized data to generate the first information and the second information. The depth testing and / or hidden face removal are used to remove occluded fragments and determine the target fragment.

11. A rendering system, characterized in that, The rendering system includes: a rasterizer, a fragment shader constructor, an interpolator, and a fragment shader; The rasterizer is used to send first information to the interpolator and second information to the fragment shader constructor; wherein, the first information is used to indicate the storage location of first attribute data, and the first attribute data is used to indicate the vertex attributes of the target primitive; the second information is used to indicate the positional distribution of the target fragments in the target primitive, and the target fragments are multiple fragments generated after the target primitive is rasterized. The interpolator is used to obtain the first attribute data according to the first information, and perform interpolation calculation based on the first attribute data to generate second attribute data; wherein, the second attribute data is fragment attribute data obtained after performing the interpolation calculation on the first attribute data; The fragment shader constructor is used to generate a shader thread task based on the second information, and the shader thread task is used to shade the target fragment. The fragment shader is used to execute the shader thread task based on the second attribute data to generate the shaded target fragment.

12. A GPU chip, characterized in that, The GPU chip includes the rendering system as described in claim 11.

13. An electronic device, characterized in that, The electronic device includes a GPU chip, and the GPU chip includes the rendering system as described in claim 11.

Images