Three-dimensional scene rendering method and device based on graphics processor, equipment and medium

Abstract

The invention relates to the technical field of image rendering, and discloses a three-dimensional scene rendering method, device and equipment based on a graphics processor and a medium, the method is applied to the graphics processor, and the method comprises the following steps: receiving instance attribute data sent by a central processing unit; calling a calculation shader to distribute a calculation thread group according to the number of objects in the instance attribute data; calculating a corresponding transformation matrix for each object in parallel through the calculation thread group; adding the instance attribute data and the transformation matrix into an instance buffer area to obtain to-be-rendered instance data of each object; extracting to-be-rendered instance data from the instance buffer area, and performing invisible object removal processing on the to-be-rendered instance data through the calculation thread group to obtain target instance data of a visible object; and rendering the target instance data. According to the invention, the rendering effect and rendering efficiency of the three-dimensional scene are improved.

Description

Technical Field

[0001] This invention relates to the field of image rendering technology, and specifically to a method, apparatus, device, and medium for rendering three-dimensional scenes based on a graphics processor. Background Technology

[0002] With the rapid growth in demand for multimodal interaction and high-precision 3D navigation in intelligent cockpits, in-vehicle systems are placing increasingly stringent requirements on real-time rendering capabilities for high-density dynamic 3D scenes. Current mainstream 3D rendering architectures generally employ instantiation and static culling strategies based on the Central Processing Unit (CPU). The CPU traverses the scene graph to determine the visibility of objects, then performs instantiation calculations on visible objects, submitting the generated instantiation data to the Graphics Processing Unit (GPU) for rendering. However, in highly dynamic scenes such as traffic flow simulation and dense urban model rendering, this architecture faces significant performance bottlenecks. The CPU needs to traverse the visibility state of dynamic objects (such as vehicles and pedestrians) frame by frame and reorganize the instantiation data, resulting in a single-frame instantiation buffer update delay exceeding 3ms. Furthermore, frequently updated moving objects can easily cause GPU batch processing breaks. Decoupling the CPU-side instantiation logic from the GPU-side rendering pipeline leads to wasted memory bandwidth (e.g., repeatedly uploading the same model matrix for each frame). Therefore, how to improve the hardware performance during 3D scene rendering, thereby improving the rendering effect and efficiency, is a problem worthy of research. Summary of the Invention

[0003] In view of this, the present invention provides a method, apparatus, device and medium for rendering three-dimensional scenes based on a graphics processor, so as to solve the problem of poor rendering effect and rendering efficiency when rendering three-dimensional scenes.

[0004] In a first aspect, the present invention provides a three-dimensional scene rendering method based on a graphics processor (GPU), applied to a GPU, the method comprising: receiving instance attribute data sent by a central processing unit (CPU), wherein the instance attribute data is data processed by the CPU using object metadata in an instantiation format, the instantiation format being a data format that the GPU can recognize and process, and the object metadata being used to describe object attributes in a three-dimensional scene; allocating a computational thread group by calling a computational shader according to the number of objects in the instance attribute data; calculating a corresponding transformation matrix for each object in parallel through the computational thread group, the transformation matrix being used to describe the pose of each object; adding the instance attribute data and the transformation matrix to an instance buffer to obtain instance data to be rendered for each object, the instance buffer being a region in the GPU's video memory; extracting the instance data to be rendered from the instance buffer, and performing invisible object culling processing on the instance data to be rendered through the computational thread group to obtain target instance data of visible objects; and rendering the target instance data.

[0005] In some optional implementations, the step of calling the compute shader to allocate compute thread groups based on the number of objects in the instance attribute data includes: configuring each compute thread group to contain 128 compute threads by default; reducing the number of compute threads in the thread group when the 128 compute threads exceed the capacity of the graphics processor; dividing the 3D scene into even partitions according to the distribution of the number of objects in the 3D scene, and allocating a corresponding compute thread group to each partition.

[0006] In some optional implementations, adding the instance attribute data and the transformation matrix to the instance buffer to obtain the instance data to be rendered for each object includes: identifying dynamic data and static data in the instance data to be rendered, wherein the dynamic data represents data that is likely to be updated with changes in the frame rate, and the static data represents data that is not updated with changes in the frame rate; storing the dynamic data in the high-frequency update area of ​​the instance buffer; and storing the static data in the static data area of ​​the instance buffer.

[0007] In some optional implementations, storing the dynamic data in the high-frequency update area of ​​the instance buffer includes: comparing the dynamic data to be added to the current frame with the dynamic data already existing in the previous frame in the high-frequency update area to determine the target instance that has changed in the high-frequency update area; updating the data corresponding to the target instance using the dynamic data to be added to the current frame; and recording the index of the target instance in an additional buffer, wherein the additional buffer is a region in the graphics processor's video memory.

[0008] In some optional implementations, updating the data corresponding to the target instance using the dynamic data to be added in the current frame includes: using the dynamic data to be added in the current frame, overwriting the corresponding old data in a first buffer with the new data corresponding to the target instance, wherein the state of the first buffer represents the buffer to be written in the current frame in the high-frequency update area; determining the unchanged instance data that has not changed relative to the previous frame from the second buffer, and referencing the unchanged instance data to the first buffer, wherein the state of the second buffer represents the buffer that existed in the previous frame in the high-frequency update area; and swapping the states of the first buffer and the second buffer when the writing of the first buffer is completed.

[0009] In some optional implementations, recording the index of the target instance in the supplementary buffer includes: assigning a unique row number to each computation thread using a counter, the unique row number representing a row position in the supplementary buffer; and invoking the computation thread responsible for the target instance to record the index of the target instance in the supplementary buffer using the corresponding unique row number.

[0010] In some optional implementations, before storing the dynamic data into the high-frequency update zone in the instance buffer, the method further includes: determining the level of detail for each object based on the distance between each object and the virtual eye position in the dynamic data, wherein the level of detail decreases as the distance between the virtual eye position and the object increases, the level of detail being used to represent the coarseness of the object model, and the lower the level of detail, the coarser the object model; the virtual eye position being used to represent the display viewpoint position of the rendered 3D scene; and determining the model data in the dynamic data that needs to be added to the high-frequency update zone based on the level of detail for each object.

[0011] In some optional implementations, before extracting the instance data to be rendered from the instance buffer and performing invisible object culling on the instance data to be rendered through a computing thread group to obtain the target instance data of visible objects, the method further includes: merging the instance data to be rendered into multiple batches based on the same model, the same material, and the same level of detail, wherein the instance data to be rendered in one batch is used for simultaneous rendering.

[0012] In some optional implementations, the step of extracting the instance data to be rendered from the instance buffer and performing invisible object culling on the instance data to be rendered through a computation thread group to obtain target instance data of visible objects includes: determining the view frustum of the virtual eye position; using the view frustum to filter the instance data to be rendered that falls outside the range of the view frustum; determining the second invisible object occluded in the instance data to be rendered through an occlusion query kernel function; determining a culling mask based on the first invisible object and the second invisible object, the culling mask being used to notify the thread to skip the rendering of the corresponding invisible object; and compressing the culling mask and storing it in an additional buffer.

[0013] In some alternative implementations, the method further includes adding a visibility marker to the header of each instance data to be rendered in the instance buffer based on the culling mask.

[0014] In some alternative implementations, the culling mask is also used to be read by the central processing unit, and the central processing unit and the graphics processing unit transfer the culling mask and the instance attribute data respectively through different DMA channels.

[0015] Secondly, the present invention provides a 3D scene rendering device based on a graphics processor, applied to a graphics processor, the device comprising: an instance attribute data receiving module, used to receive instance attribute data sent by a central processing unit, the instance attribute data being data processed by the central processing unit using object metadata in an instantiation format, the instantiation format being a data format that the graphics processor can recognize and process, the object metadata being used to describe object attributes in a 3D scene; an instance processing thread allocation module, used to allocate a computation thread group by calling a computation shader according to the number of objects in the instance attribute data; an instantiation parallel computation module, used to compute the corresponding transformation matrix for each object in parallel through the computation thread group, the transformation matrix being used to describe the pose of each object; an instance data generation module, used to add the instance attribute data and the transformation matrix to an instance buffer to obtain the instance data to be rendered for each object, the instance buffer being a region in the graphics processor's video memory; an invisible culling module, used to extract the instance data to be rendered from the instance buffer and perform invisible object culling processing on the instance data to be rendered through the computation thread group to obtain target instance data of visible objects; and a rendering module, used to render the target instance data.

[0016] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0017] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment thereof.

[0018] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment thereof.

[0019] The technical solution provided by this invention has the following advantages: (1) Based on the above technical means, the entire process of 3D scene rendering is dominated by the graphics processor, breaking the performance bottleneck of the traditional CPU-dominated mode. The CPU only needs to send the preprocessed instance attribute data, and the GPU autonomously allocates computing thread groups to calculate the transformation matrix in parallel, thereby improving the computational efficiency of the transformation matrix. The use of instance buffers enables centralized data management, and the culling of invisible objects and final rendering are carried out based on the instance data in the instance buffers, which greatly reduces the data interaction latency between the CPU and the GPU. This method significantly improves the real-time rendering of high-density dynamic scenes (such as vehicle traffic flow), improves the single-frame rendering efficiency by several times, reduces the CPU utilization rate to below 3%, and reduces the peak memory bandwidth by 65%, meeting the requirements of automotive-grade 3D rendering for low latency and high stability.

[0020] (2) Based on the above technical means, the allocation of computing thread groups is optimized. The default 128 thread groups are adapted to the mainstream GPU hardware architecture to maximize the utilization of computing units. When the hardware capacity is insufficient, the number of threads can be flexibly reduced to avoid thread group startup failure and ensure rendering stability. In addition, the thread groups are evenly distributed according to the number of objects to solve the load imbalance problem caused by uneven object density. This makes the allocation of GPU computing resources more reasonable, significantly reduces the thread idle rate, and improves the single-frame thread scheduling efficiency. Even in complex in-vehicle scenes, it can still maintain efficient parallel computing and avoid slowing down the overall rendering speed due to uneven load.

[0021] (3) Based on the above technical means, the instance buffer is divided into a high-frequency update area and a static data area to accurately distinguish between dynamic and static data. Static data usually only needs to be stored during initialization to avoid repeated uploading in each frame. The high-frequency update area centrally stores volatile data to reduce invalid data transmission. This division reduces the video memory bandwidth usage by 50%-70% and increases the video memory utilization rate by 200%-300%. In scenarios such as vehicle navigation, static data such as model structure and material basic parameters do not need to be repeatedly transmitted. Only dynamic data such as vehicle position and attitude are updated, which significantly reduces the video memory pressure and ensures the data processing efficiency and stability during multi-frame rendering.

[0022] (4) Based on the above technical means, target instances in the high-frequency update area are located by data comparison, and only changed data is updated. Combined with the additional buffer recording the target instance index, the instance buffer is avoided from being fully overwritten. This further reduces the amount of video memory data updates, shortening the data update latency per frame to within 0.3ms. At the same time, the updated objects are accurately tracked by index recording, allowing for more targeted operations such as coloring and shadow calculation of the rendered instances in the subsequent rasterization and fragment shading stages. In high-density dynamic scenes in vehicles, it can quickly respond to changes in vehicle position and attitude, reduce the impact of invalid data transmission on the real-time rendering, and ensure smoothness of the image.

[0023] (5) Based on the above technical means, the high-frequency update area adopts a double-buffering (first buffer and second buffer) mechanism to handle dynamic data updates. The first buffer writes the new data of the current frame, and the unchanged instance data in the second buffer is extracted synchronously to realize incremental data updates and reuse. When a new frame needs to be rendered, the first buffer and the second buffer are updated alternately to avoid rendering stuttering caused by data updates, ensure that the data is stable and available when the current frame is rendered, and reduce redundant calculations and data transmission. In the scene of rapid changes in vehicle perspective, the continuity and timeliness of dynamic data updates can be guaranteed, so that the rendering transition is smooth and there is no delay or screen tearing.

[0024] (6) Based on the above technical means, a unique row number is assigned by a counter, and the target instance index is recorded by the calculation thread. The atomic addition operation is used to avoid multi-threaded write conflicts. This ensures that the instance index records in the additional buffer are accurate and orderly, with no duplicate or missing indexes, and significantly improves the efficiency of thread collaboration. When processing a large number of dynamic instances in parallel by multiple threads, the consistency of the index records can be guaranteed, providing support for the accurate extraction of target instance data in the subsequent rendering stage and avoiding rendering errors caused by index chaos.

[0025] (7) Based on the above technical means, the Level of Detail (LOD) is determined according to the distance between the object and the virtual eye position, and model data in the high-frequency update area is filtered to achieve dynamic data management of "fine detail for near objects and simplified detail for distant objects". The farther the distance, the lower the level of detail and the less model data, reducing the time and processing pressure of subsequent rendering. This further reduces the memory bandwidth usage, while ensuring a balance between the rendering accuracy of near objects and the rendering efficiency of far objects. In scenarios such as in-vehicle augmented reality head-up displays and 3D navigation, it can clearly display the details of nearby vehicles and road signs, and efficiently render the outline of distant cities, improving the accuracy and smoothness of the overall scene rendering.

[0026] (8) Based on the above technical means, the data of instances to be rendered are merged into batches according to "same model, same material and same level of detail" to achieve batch rendering. Processing multiple instances in a single batch reduces the number of GPU drawing command calls and improves drawing efficiency by 3-5 times, especially in scenes with a large number of similar instances (such as highways with many identical vehicle models and streetlights), the effect is significant. Batch rendering can also reduce the idle rate of GPU shader cores, make full use of hardware resources, and quickly process a large number of similar instances in high-density in-vehicle scene rendering, avoiding the low efficiency caused by rendering a single instance independently, and ensuring high frame rate output of the image.

[0027] (9) Based on the above technical means, the first invisible object outside the view frustum is filtered by view frustum culling, and the second invisible object that is occluded is determined by the occlusion query kernel function. The double culling greatly reduces redundant rendering. The culling mask is compressed and stored to reduce the use of video memory, and the use of the additional buffer facilitates subsequent fast reading. In complex road conditions in vehicles (such as congested road sections and multiple building occlusions), invisible objects can be efficiently filtered out, avoiding the GPU from wasting computing power to render instances outside the view or occluded, and improving the utilization rate and real-time performance of rendering resources.

[0028] (10) Based on the above technical means, a visibility marker is added to the instance data header according to the culling mask, enabling the GPU to quickly identify the instance visibility status during the rendering process without additional querying of the culling mask, thus reducing memory addressing overhead. The visibility marker is closely related to the instance data, improving reading efficiency by 50% and avoiding processing delays caused by data separation. In the geometry shader and vertex shader stages of the rendering pipeline, subsequent operations on invisible instances can be quickly skipped, further reducing invalid calculations and ensuring high frame rate rendering in automotive scenes. Especially when instances change frequently in dynamic scenes, visible instances can still be efficiently filtered.

[0029] (11) Based on the above technical means, the CPU and GPU can share the reading of the culling mask, providing a basis for the CPU to dynamically load and unload instances and reclaim memory, thereby realizing resource optimization between the GPU and the CPU. At the same time, the culling mask and instance attribute data are transmitted in parallel through different DMA channels to avoid data transmission congestion and further improve transmission efficiency. This makes the division of labor between the CPU and the GPU clearer, allowing the CPU to accurately manage instance resources and avoid memory waste, while the GPU focuses on rendering processing. When the vehicle system is running in a multi-tasking manner, the resource usage of the CPU and GPU can be balanced to ensure the stable operation of rendering performance and other system functions, meeting the low power consumption and high reliability requirements of automotive-grade systems. Attached Figure Description

[0030] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0031] Figure 1 This is a flowchart illustrating a three-dimensional scene rendering method based on a graphics processor according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a graphics processor-based three-dimensional scene rendering device according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] With the rapid growth in demand for multimodal interaction and high-precision 3D navigation in intelligent cockpits, in-vehicle systems are placing increasingly stringent requirements on real-time rendering capabilities for high-density dynamic 3D scenes. Current mainstream 3D rendering architectures generally employ instantiation and static culling strategies based on the Central Processing Unit (CPU). The CPU traverses the scene graph to determine the visibility of objects, then performs instantiation calculations on visible objects, submitting the generated instantiation data to the Graphics Processing Unit (GPU) for rendering. However, in highly dynamic scenarios such as traffic flow simulation and dense urban model rendering, this architecture faces significant performance bottlenecks. The CPU needs to traverse the visibility state of dynamic objects (such as vehicles and pedestrians) frame by frame and reorganize the instantiation data, resulting in a single-frame instantiation buffer update delay exceeding 3ms. Furthermore, frequently updated moving objects can easily cause GPU batch processing breaks. The decoupling of CPU-side instantiation logic from the GPU-side rendering pipeline leads to wasted memory bandwidth (e.g., repeatedly uploading the same model matrix for each frame). Traditional rendering methods suffer from rigid culling strategies. Traditional frustum culling relies on pre-calculated static spatial segmentation, making it difficult to adapt to high-speed changes in the vehicle's perspective (such as entering and exiting tunnels or sharp turns), resulting in redundant rendering rates of up to 30%-40%. Therefore, improving hardware performance during 3D scene rendering, thereby enhancing rendering quality and efficiency, is a worthwhile research topic.

[0034] According to an embodiment of the present invention, a method for rendering a three-dimensional scene based on a graphics processor is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] This embodiment provides a graphics processor-based 3D scene rendering method, which can be used with graphics processors. Figure 1 This is a flowchart of a graphics processor-based 3D scene rendering method according to an embodiment of the present invention. The process includes the following steps: Step S101: Receive instance attribute data sent by the central processing unit. The instance attribute data is data processed by the central processing unit using object metadata in an instantiation format. The instantiation format is a data format that the graphics processor can recognize and process. The object metadata is used to describe the object attributes in the 3D scene. Step S102: Based on the number of objects in the instance attribute data, call the compute shader to allocate compute thread groups; Step S103: The transformation matrix corresponding to each object is calculated in parallel by the calculation thread group. The transformation matrix is ​​used to describe the pose of each object. Step S104: Add the instance attribute data and transformation matrix to the instance buffer to obtain the instance data to be rendered for each object. The instance buffer is a region in the graphics processor's video memory. Step S105: Extract the instance data to be rendered from the instance buffer, and perform invisible object culling on the instance data to be rendered through the computing thread group to obtain the target instance data of visible objects. Step S106: Render the target instance data.

[0036] Specifically, current automotive 3D rendering architectures generally rely on the central processing unit (CPU) to lead instantiation batch processing and static culling. The CPU needs to traverse the visibility state of dynamic objects (such as vehicles and pedestrians) frame by frame and reorganize the instantiation data, resulting in a single-frame instantiation buffer update delay of more than 3ms. High-frequency moving objects are prone to causing GPU batch processing to break down, resulting in an imbalance between CPU and GPU hardware resource utilization, and problems such as wasted video memory bandwidth and idle shader cores.

[0037] In this embodiment of the invention, the CPU first needs to load the object metadata (structured information used to fully describe the attributes of objects in the 3D scene, covering various key parameters from model structure to behavioral characteristics) of all instantiable dynamic objects in the 3D scene, specifically including four types of core information: Model structure information, used to describe the object's geometry and basic pose, specifically includes: 1. A vertex buffer storing the object's vertex coordinates (each object model is composed of a large number of vertices); 2. An index buffer recording the vertex connection order (by restricting the connection method and order of vertices, the corresponding model is generated); 3. Bounding box information used for fast collision detection and visibility judgment (referring to the smallest geometric shape that encloses the object, usually an axis-aligned bounding box, abbreviated as AABB); 4. The default pose matrix of the object's initial placement pose.

[0038] Material parameter information, which determines the appearance and texture of an object, such as the base color texture ID associated with the base color texture file, the normal map ID that reflects the surface bumps and details, the metallicity parameter that controls the metallic texture, and the roughness parameter that reflects the surface roughness.

[0039] Behavioral description attributes are used to define the dynamic characteristics of an object, including whether the object is movable (e.g., vehicles are movable objects, road signs are immovable objects), whether it supports LOD switching, and whether it participates in animation-driven activities (e.g., pedestrian walking animation, vehicle wheel rotation animation). Type and category labels are used to identify the type of an object, such as "Vehicle" or "Human" as object type IDs and label names.

[0040] The CPU converts the aforementioned object metadata into an instance format (a data format that the GPU can directly recognize and process without additional format conversion, such as structured data formats conforming to the Vulkan / OpenGLES standard). The resulting instance attribute data includes the object's geometric index, position, orientation, scale, material, and other attribute information. After generating the instance attribute data, it is sent to the GPU. The GPU receives this instance attribute data and completes the data initialization input before rendering.

[0041] For example, in a 3D scene for in-vehicle navigation, the CPU loads metadata for 500 instantiable objects. The metadata for the 500 "Vehicle" objects includes: a vertex buffer (storing the coordinates of each vertex of the vehicle body), bounding box information (a cuboid 5m long × 1.8m wide × 1.5m high), a base color texture ID (associated with the red paint texture file), and movable behavior attributes that support LOD switching. The CPU converts this metadata into a structured format that the GPU can recognize, generates instance attribute data, and sends it to the GPU.

[0042] After receiving instance attribute data, the GPU first counts the total number of objects contained within it, denoted as N. Then, it calls the compute shader (a programmable unit in the GPU, independent of the traditional graphics pipeline, used to perform general-purpose parallel computing tasks, and capable of flexibly scheduling threads to process data), and dynamically calculates the required number of compute thread groups based on the total number of objects N, and allocates the compute thread groups accordingly.

[0043] In this embodiment of the invention, thread group allocation follows a core principle: ensuring that all instance objects can be processed by threads, while adapting to the GPU hardware architecture to improve computational efficiency. The specific allocation logic is as follows: first, the basic thread group size is determined based on the scheduling characteristics of the GPU hardware computing units; then, the total number of thread groups is calculated in conjunction with the total number of objects N; finally, thread group allocation is completed, enabling each thread group to process one or more instance objects.

[0044] For example, if the total number of objects in the instance attribute data is N=1000, after the GPU calls the compute shader, based on hardware characteristics, each thread group can efficiently process 128 threads by default (adapting to the 32 / 64 thread scheduling granularity of mainstream GPUs; 128 is the least common multiple of 32 and 64, enabling the compute units to run at full capacity). Using the formula "Number of thread groups = ceil(N / 128)", where ceil represents the floor function, the number of thread groups is calculated to be 8. The GPU allocates computing resources to these 8 thread groups, with the first 7 thread groups each processing 128 objects, and the 8th thread group processing 1000 - 7 × 128 = 104 objects, ensuring that all 1000 objects are covered.

[0045] After the GPU allocates the computing thread groups, it starts all thread groups. The threads in each thread group execute the model matrix generation kernel function (a special function for calculating the object's pose transformation, which can integrate translation, rotation, and scaling operations) in parallel for the assigned instance object. It calculates the corresponding transformation matrix for each object (a 4×4 matrix for describing the object's pose in 3D space, containing translation, rotation, and scaling information. Because each object has a different pose in the 3D scene, matrix multiplication can be used to transform the object from the initial default pose to the pose required for the current frame. For example, all objects that are facing forward by default can be transformed into different orientations in the actual scene).

[0046] The specific calculation process is as follows: 1. Each thread reads the initial pose (i.e., the default pose matrix in the object's metadata) and behavioral parameters (such as whether it is movable and the dynamic data update frequency) of the corresponding instance object from the GPU's structured buffer (referring to the GPU buffer that stores data according to a fixed data structure, which facilitates the thread to quickly locate and read the target data); 2. Combined with the scene dynamic data of the current frame (referring to data describing the changes in the object's state in the current frame, such as the object's displacement vector, rotation angle, and scaling factor), the initial pose is adjusted; 3. According to the mathematical transformation logic, the translation transformation matrix T (describing the object's state changes) is first calculated. The transformation matrix consists of a matrix representing the object's position and movement in 3D space (generated from the object's displacement vector), a rotation transformation matrix R (generated from the rotation angle to describe the object's rotation around the coordinate axes; for 3D rotations, it can be converted to a matrix using quaternions to avoid gimbal lock issues), and a scaling transformation matrix S (generated from the scaling factor to describe the object's size scaling). Finally, the transformation matrix M is generated by matrix multiplication M = T•R•S (the order of matrix multiplication cannot be changed; scaling must be performed first, then rotation, and finally translation to ensure the correctness of the pose transformation logic). This matrix fully describes the object's pose (position, orientation, and size) in the current frame.

[0047] After the GPU calculates the transformation matrices for all objects, it integrates the instance attribute data (containing structured information after object metadata transformation) with the corresponding transformation matrices and adds them together to the instance buffer (a contiguous storage area in GPU memory specifically used to store data required for instance rendering, enabling centralized data management and fast access, avoiding addressing latency caused by scattered data storage). The integrated data is the instance data to be rendered for each object, containing the object's geometric information (such as vertices and indices), appearance information (such as material parameters), and pose information (transformation matrix), providing complete data support for subsequent culling and rendering. This embodiment of the invention achieves centralized storage of instance data through the instance buffer, reducing the number of addressing operations the GPU performs when reading data in subsequent steps, while also avoiding duplicate data transmission.

[0048] Afterwards, the GPU extracts the rendering instance data of all objects from the instance buffer, calls the computing thread group again, and performs invisible object culling (refers to filtering out objects that cannot be observed in the 3D scene through a specific algorithm to avoid invalid rendering and reduce GPU computing power waste). In this embodiment of the invention, invisible object culling may include view frustum culling and occlusion culling to filter out invisible objects and obtain the target instance data of visible objects.

[0049] After culling occluded objects, objects marked as "visible" are finally selected, and their instance data to be rendered is the target instance data. After the GPU obtains the target instance data of the visible objects, it starts the graphics rendering pipeline, binds the target instance data directly to the rendering pipeline through the graphics processor, and renders multiple object instances in batches using a single draw call, completing the final rendering in stages. The specific process is described below.

[0050] The geometry shader and vertex shader processing stages: The GPU passes the target instance data to the geometry shader, a programmable unit in the graphics pipeline located after the vertex shader, used to process primitives (such as triangles), and can adjust the number and shape of primitives. The target instance data is then passed to the vertex shader (a programmable unit in the graphics pipeline responsible for vertex coordinate transformation and attribute interpolation). In this stage, the GPU loads the visibility marker corresponding to each target instance data, performs an MVP transformation on visible instances, and converts the object's local coordinates to screen coordinates using a cubic matrix transformation. M is the model matrix (i.e., the transformation matrix from the previous steps), V is the view matrix (the matrix describing the virtual eye pose), and P is the projection matrix (the matrix that projects 3D space onto the 2D screen). Simultaneously, material parameters (such as texture and metallicity) are bound, and the processed vertex data is passed to the next stage.

[0051] Rasterization stage: The GPU converts the vertex data processed by the geometry / vertex shader into fragments (candidates for individual pixels on the screen, containing information such as color and depth), completing the rasterization transformation of the primitives (discretizing continuous 3D primitives into pixels on the screen).

[0052] Fragment shader processing stage: The fragment shader refers to the programmable unit in the graphics pipeline used to process fragment data. It is responsible for calculating the final color of the fragment, combining material textures and lighting models (such as diffuse reflection and specular reflection) to perform color calculation and depth calculation for each fragment (determining the depth value of the fragment in screen space), and completing the depth writing and color writing.

[0053] In the instantiation and rendering execution phase: The GPU binds the vertex buffer and index buffer of the target instance data, and executes InstanceDraw based on the instance ID (a unique identifier in the target instance data). This method involves the GPU batch-drawing multiple identical instances, reducing the number of drawing command calls. Finally, the image data in the color buffer is output to the display device (such as a vehicle head-up display or a smart cockpit display), completing the rendering. The rendering result is then output to the frame buffer for subsequent display or further image processing.

[0054] By employing the aforementioned techniques, the GPU dominates the entire rendering process, while the CPU is only responsible for initial metadata format conversion and data transmission, significantly reducing the interaction latency between the CPU and GPU. Instantiation data update latency is reduced from over 3ms in traditional solutions to within 0.3ms, improving single-frame rendering efficiency by over 3 times. Even in high-density dynamic scenes within vehicles, rendering performance exceeding 120 FPS at 3840×1600 resolution can still be achieved, meeting the low latency and high frame rate requirements of automotive-grade 3D rendering. Through dynamic allocation of computing thread groups (e.g., determining thread group size based on the number of objects), GPU computing unit utilization is increased by over 40%, thread idle rate is reduced to below 10%, and CPU utilization can be reduced to below 3%, preventing excessive CPU resource consumption by rendering tasks and ensuring the stable operation of other functions of the vehicle system (such as navigation route calculation and voice interaction). Furthermore, the thread group allocation logic adapts to automotive GPUs with different computing power, eliminating the need to modify the core process for specific hardware, making thread group allocation more flexible.

[0055] In some alternative implementations, step S102 includes: Step a1: Each computing thread group is configured by default to contain 128 computing threads; Step a2: When the thread group of 128 computing threads exceeds the capacity of the graphics processor, reduce the number of computing threads in the thread group. Step a3: Divide the 3D scene into evenly distributed partitions according to the number of objects in the 3D scene, and assign a corresponding computing thread group to each partition.

[0056] Specifically, when utilizing compute shaders, traditional compute thread configurations often employ a fixed number of threads (e.g., 32 or 64), which fails to adapt to the varying hardware capabilities of GPUs and the distribution characteristics of objects in 3D scenes. If the fixed number of threads exceeds the hardware resource limits of low-end GPUs, such as registers and shared memory, it can lead to thread group startup failures or rendering crashes. On the other hand, if the "clustered" distribution of objects in the scene (e.g., densely packed vehicles at urban intersections and sparsely packed vehicles in suburban areas) is ignored, and thread groups are allocated in a fixed manner, a load imbalance problem will occur, where "some thread groups process too many objects and consume a lot of time, while some thread groups process too few objects and are idle." This results in low utilization of GPU computing resources, making it difficult to meet the real-time rendering requirements of high-density dynamic scenes in vehicles.

[0057] In this embodiment of the invention, when the GPU calls the compute shader to allocate thread groups, it first executes the default thread configuration, allocating 128 compute threads to each compute thread group by default (referring to the smallest execution unit in the GPU compute shader used for parallel data processing; each thread can independently process data from one or more instance objects). This default configuration is compatible with the mainstream GPU's SIMT / SIMD hardware architecture (SIMT stands for Single Instruction Multiple Threads, meaning the GPU uses the same instruction to control multiple threads to execute in parallel; SIMD stands for Single Instruction Multiple Data, meaning the GPU uses the same instruction to process multiple data; both require threads to be scheduled in "groups" to achieve efficient parallelism). The basic unit for scheduling threads in mainstream automotive GPUs typically contains 32 threads and 64 threads. 128 is the least common multiple of 32 and 64. A thread group of 128 threads can be precisely divided into four basic units of 32 threads or two units of 64 threads, enabling the GPU compute units to run at full capacity with "no idle time," avoiding resource waste caused by the number of threads not being an integer multiple of the scheduling unit.

[0058] After executing the default configuration, the GPU uses a hardware resource detection module to determine whether the 128-thread thread group exceeds the current GPU's capacity (referring to the maximum support limit of GPU hardware resources for the thread group; core limitations include, but are not limited to, register capacity and shared memory size). When the capacity is exceeded, the GPU will calculate the maximum number of threads it can support by using the formula "Number of threads = Hardware resource limit / Resource requirement per thread," and reduce the number of threads in the thread group to ensure that the thread group can start stably.

[0059] After the GPU completes the thread group size adaptation, this embodiment of the invention analyzes the distribution of the number of instance objects in the 3D scene (referring to the density of objects in 3D space). It then uses a spatial partitioning algorithm (such as mesh indexing, octree, etc., to divide the 3D scene into multiple rectangular partitions of fixed size) to perform "average partitioning" of the scene, ensuring that the number of objects in each partition is as close as possible, avoiding extreme differences such as "one partition containing 200 objects, another containing only 10 objects." Subsequently, one or more thread groups are allocated to each partition, and the difference in the number of objects processed by each thread group is controlled within a preset threshold (e.g., 30), significantly improving the thread load balancing rate.

[0060] Based on the aforementioned technical methods, the logic of "default configuration, hardware detection, and thread count adjustment" allows the thread group size to be adapted to various automotive GPUs from low-end to high-end, avoiding thread group startup failures or rendering crashes due to insufficient hardware resources. On low-end GPUs, the reduced number of threads can still stably process instance objects; on high-end GPUs, the default 128-thread configuration can fully utilize hardware resources and reduce cross-hardware adaptation costs. A partitioning strategy based on the average distribution of object quantity solves the problem of "uneven thread workload" caused by traditional fixed partitioning. The small difference in the number of objects processed by each thread group avoids "slow threads dragging down the entire process," indirectly improving the rendering frame rate.

[0061] In some optional implementations, step S104 above includes: Step b1: Identify dynamic and static data in the instance data to be rendered. Dynamic data represents data that is likely to be updated as the frame changes, while static data represents data that does not update as the frame changes. Step b2: Store the dynamic data in the high-frequency update area of ​​the instance buffer; Step b3: Store the static data in the static data area of ​​the instance buffer.

[0062] Specifically, in traditional 3D rendering technology, the CPU needs to transfer the processed instance data of each frame to the GPU, resulting in excessive GPU memory bandwidth consumption and increased transmission pressure. In high-density dynamic scenes in vehicles, the data transmission volume of a single frame exceeds 100MB, and repeated uploading of static data causes more than 50% of invalid bandwidth waste; at the same time, full updates are prone to GPU data processing latency, and the update time of a single frame buffer exceeds 3ms, which is difficult to meet the requirements of automotive-grade 3D rendering for low latency and high bandwidth utilization.

[0063] In this embodiment of the invention, after the GPU integrates instance attribute data and transformation matrix into instance data to be rendered, it first performs data classification and identification, distinguishing between dynamic data and static data based on the core standard of "whether the data changes with the frame".

[0064] For example, dynamic data refers to data that is likely to be updated as the frame changes. This type of data directly reflects the real-time state changes of the instance object in the 3D scene. It mainly includes "transformation matrix" (which describes the position, orientation, and scaling changes of the object in each frame, such as the displacement matrix of a vehicle moving along the road in each frame), "LOD state" (the level of detail that dynamically switches according to the distance between the object and the virtual eye position, such as the vehicle switching from LOD0 at 50m to LOD1 at 100m), and the dynamic behavior parameters of the object (such as the frame index of pedestrian walking animation and the on / off state of vehicle turn signals).

[0065] For example, static data refers to data that does not update with changes in the frame rate of the image. This type of data is determined during the initialization of the 3D scene and remains stable throughout the entire rendering cycle. It mainly includes "model structure information" (such as vertex buffers, index buffers, and basic bounding box dimensions, such as the vertex coordinates of the vehicle body and the fixed length / width / height values ​​of the cuboid bounding box), "material parameter information" (such as basic color texture IDs, normal map IDs, and fixed parameters for metallicity and roughness), and "type and classification labels" (such as fixed type IDs for "Vehicle" and "Human").

[0066] The recognition process is implemented through the data feature detection module built into the GPU. The module reads the "update frequency label" of the instance data to be rendered. The "update frequency label" records the update frequency of each object. Combined with the historical update records of the data (such as data that has not been updated for 10 consecutive frames is judged as static data), the module automatically completes the classification and labeling of dynamic data and static data.

[0067] After the GPU completes dynamic data identification, it stores it in a pre-defined high-frequency update area within the instance buffer. This area is a core component of the "memory reuse pool" and is specifically designed to store high-frequency data that updates with each frame. The GPU stores static data in a static data area within the instance buffer, which is independent of the high-frequency update area. This area is specifically designed to store data that is not updated throughout the entire rendering cycle and employs a "initialization write + full-cycle reuse" storage strategy. If subsequent frames do not change the data in the static data area, there is no need to upload it again; the initially stored data can be reused directly.

[0068] Based on the aforementioned technical methods, by distinguishing between dynamic and static data, static data is only written to the static data area during initialization, and subsequent frames do not need to upload it repeatedly. Dynamic data is stored in a high-frequency update area, with only the changed parts being updated. Combined with a memory reuse pool design, this reduces memory bandwidth usage by 50%-70%. In a scenario with 1000 objects in an automotive system, the data transfer volume per frame is reduced from 100MB to 30-50MB, and memory utilization is increased by 200%-300%, avoiding bandwidth waste caused by traditional full updates and adapting to the limited memory resources of automotive systems. Full-cycle reuse of static data and updating only the changed parts of dynamic data significantly shortens the update time of the single-frame instance buffer, greatly improving data processing efficiency. In high-density dynamic automotive scenes, it can quickly respond to the data update needs of each frame, avoiding screen stuttering caused by buffer update delays and ensuring a stable rendering frame rate of over 120FPS, meeting automotive-grade real-time requirements.

[0069] In some alternative implementations, step b2 above includes: Step c1: Compare the dynamic data to be added to the current frame with the dynamic data that already exists in the previous frame in the high-frequency update area to determine the target instance that has changed in the high-frequency update area. Step c2: Update the data corresponding to the target instance using the dynamic data to be added in the current frame; Step c3 records the index of the target instance in the additional buffer, which is a region in the graphics processor's video memory.

[0070] Specifically, for data updates in the high-frequency update zone, the GPU first activates a data comparison module. This module compares the dynamic data to be added to the current frame (such as the transformation matrix of the vehicle's latest position and the updated LOD state) with the dynamic data retained from the previous frame in the high-frequency update zone according to the principle of "one-to-one correspondence between instance IDs" to determine whether the instance object's state has changed (such as position change or LOD switching). For example, it calculates the Euclidean distance between the transformation matrices of the current frame and the previous frame. If the distance is greater than a preset threshold, it is determined to be a change in position or attitude. Through the above comparison, all instance objects whose states have changed are selected as target instances; instance objects that have not changed are marked as "unchanged instances" and do not require subsequent data updates. After the GPU determines the target instance, based on the incremental update mechanism of the memory reuse pool, it only updates the dynamic data of the target instance and does not touch the data of the unchanged instance.

[0071] After the GPU completes the target instance data update, it writes the IDs of all target instances to the append buffer (a thread-safe buffer in GPU memory specifically used for sequentially recording instance indices, supporting multi-threaded parallel append writing). The writing process uses GPU atomic operations, specifically including the following steps: 1. Assign a unique row number to each computation thread using a counter. The unique row number is used to indicate the position of a row in the additional buffer. 2. Call the computation thread responsible for the target instance, and record the index of the target instance in the additional buffer using the corresponding unique row number of the target instance.

[0072] Specifically, during the initialization of the additional buffer, an "update counter" is set, with an initial value of 0. Each thread processing a target instance calls an atomic increment function before writing the index, using the counter value as the write position for the current target instance index, and automatically incrementing the counter by 1 (e.g., the counter changes from 0 to 1, corresponding to the first target instance index being written at position 0). Afterward, each thread writes the target instance ID it is responsible for to the corresponding position, ensuring that when multiple threads write in parallel, the index records are not duplicated or omitted, forming a complete "instance update list." Using the index list in the additional buffer, the geometry shader and fragment shader in the rendering pipeline can then directly read it for precise location of the target instances to be processed.

[0073] Based on the aforementioned technical methods, target instances in high-frequency update areas are located through data comparison, and only changed data is updated. Combined with an additional buffer recording the target instance index, this avoids full overwriting of the instance buffer. This further reduces the amount of video memory data updates, shortening the data update latency per frame to within 0.3ms. Simultaneously, by accurately tracking updated objects through index recording, more targeted operations such as coloring and shadow calculation of rendered instances can be performed in subsequent rasterization and fragment shading stages. In high-density dynamic scenes in vehicles, it can quickly respond to changes in vehicle position and attitude, reducing the impact of invalid data transmission on rendering real-time performance and ensuring smooth visuals.

[0074] In some alternative implementations, step c2 above includes: Step d1: Using the dynamic data to be added to the current frame, the new data corresponding to the target instance is used to overwrite the old data in the first buffer. The state of the first buffer represents the buffer to be written to by the current frame in the high-frequency update area.

[0075] Step d2: Determine the invariant instance data that has not changed relative to the previous frame from the second buffer, and reference the invariant instance data to the first buffer. The state of the second buffer represents the buffer in the high-frequency update area where the previous frame exists.

[0076] Step d3: When the first buffer is finished being written, the states of the first buffer and the second buffer are swapped.

[0077] Specifically, traditional buffering mechanisms require the entire data from the previous frame to overwrite the target instance data in the current buffer during updates. If a single buffer is used to store dynamic data, a "data write and rendering read conflict" problem may occur. That is, while the GPU is writing dynamic data for the current frame, the rendering pipeline needs to read the data from that buffer for the output of the previous frame, resulting in "write overwrite read," causing screen tearing and stuttering, which makes it difficult to meet the automotive-grade requirements for the continuity and stability of screen output in automotive 3D scenes.

[0078] In this embodiment of the invention, the high-frequency update area adopts a dual-buffer structure. The two buffers are independent storage areas in the GPU memory. Their functions are strictly divided. At the same time, only one buffer is in the "write state" and the other buffer is in the "read state". The two buffers are alternated by "pointer swapping" to ensure that "writing data does not affect reading data, and reading data does not wait for writing data".

[0079] When a GPU thread writes data, it first checks the current working state of the double buffer. Assuming the frame being rendered is "frame N", the second buffer is in "read state" and the first buffer is in "write state". The two states are mutually exclusive to avoid read-write conflicts.

[0080] The GPU reads the dynamic data of the target instance to be added in the (N+1)th frame and writes the new data of the target instance (such as the updated 4×4 transformation matrix) directly into the corresponding slot of the first buffer, overwriting the old data of the target instance. During this process, the first buffer only processes "changed target instances", and the slots corresponding to unchanging instances remain initially empty. Since the first buffer is in a "write state" and no rendering operation reads its data, the new data can be written safely without worrying about the problem of "being read halfway through writing".

[0081] After the first buffer finishes writing new data to the target instance, it needs to be replenished with "invariant instance data". At this time, since the second buffer is still in the "read state", the GPU does not directly copy its data. Instead, it uses "address pointer mapping" to "associate" the data of the invariant instance in the second buffer with the data of the first buffer. That is, the empty slots of the invariant instance in the first buffer only store "pointers to the address of the corresponding instance data in the second buffer", instead of copying the full data. Thus, the invariant instance data in the second buffer is added to the first buffer. When the first buffer has completely stored the dynamic data of the N+1th frame, the rendering pipeline of the Nth frame has just completed the output of the image. The GPU immediately performs a "pointer swap" operation, switching the state of the first buffer from "write state" to "read state" and the state of the second buffer from "read state" to "write state", completing one "rendering swap".

[0082] According to the above technical means, through the dual-buffer division of labor of "mutual exclusion between write state / read state", it is realized that "writing data without reading and reading data without writing", solving the problems of screen tearing and stuttering caused by the traditional single buffer's "write-over-read", and ensuring that the output screen is smooth without breakpoints. When the rendering pipeline reads the data in the second buffer, the GPU can write new data into the first buffer in parallel, and there is no waiting time between the two, further reducing the instantiated data update latency compared with the traditional single buffer's "write first then read". By "address pointer mapping", the unchanged instance data is reused without full replication, and the amount of data written per frame is less. In the scenario where the on-vehicle GPU video memory bandwidth is limited, it can avoid the instantaneous bandwidth peak and reduce the GPU data processing power consumption at the same time, meeting the requirements of vehicle-grade low power consumption.

[0083] In some optional implementation manners, before the above step b2, it further includes: Step e1, according to the distance between each object in the dynamic data and the virtual eye position, determine the detail level corresponding to each object. The detail level becomes higher as the distance between the virtual eye position and the object increases. The detail level is used to represent the roughness of the object model. When the detail level is higher, the object model is rougher. The virtual eye position is used to represent the display perspective position of the rendered three-dimensional scene; Step e2, determine the model data that needs to be added to the high-frequency update area in the dynamic data according to the detail level corresponding to each object.

[0084] Specifically, usually the visual effects of distant objects in the scene are not clear and do not require rendering of too many details. If the model detail level is not dynamically adjusted according to the distance between the object and the observation perspective, even distant objects still load high-precision models, resulting in too large storage capacity of the dynamic data.

[0085] The virtual eye position refers to the display perspective position of the rendered three-dimensional scene. By analogy with a camera, such as the virtual observation point in an on-vehicle scene and the center of the screen perspective of the intelligent cockpit display, its spatial coordinates will be synchronized in real time by the on-vehicle system according to the vehicle driving position and the driver's perspective adjustment. The detail level is the "multi-level detail level LOD", which is used to represent the roughness of the object model. The lower the LOD level, the more vertices the model has and the more detailed it is. For example, the vehicle model of LOD0 contains 50,000 vertices and can display details such as window panes and door handles. The higher the LOD level, the rougher the model. For example, the vehicle model of LOD2 only contains 500 vertices and is simplified to a cuboid outline. In the initialization stage of the three-dimensional scene, the GPU completes the registration of the LOD switching rule and presets the distance threshold and the corresponding LOD level. For example, when the distance d between the object and the virtual eye position is less than D1, the LOD level = 0 (highest precision); when D1 ≤ d < D2, the LOD level = 1 (medium precision); when d ≥ D2, the LOD level = 2 (lowest precision), as shown in the following formula:

[0086] D1 and D2 are preset distance thresholds, and their values ​​are set according to the needs of the vehicle scenario. For example, in the urban navigation scenario, D1=50m and D2=100m are set, and in the highway scenario, D1=100m and D2=200m are set. Each object is also pre-associated with model resources of 3 LOD levels.

[0087] The GPU then calculates the distance between each object and the virtual smoke and determines the LOD level. It first reads the real-time spatial coordinates of each object in the dynamic data and the coordinates of the virtual eye position in the current frame, and then calculates the straight-line distance d between the object and the virtual eye position using the Euclidean distance formula.

[0088] Based on the LOD level determined in the above steps, the GPU selects model data in dynamic data that needs to be added to the high-frequency update region according to the principle that "the lower the LOD level, the more refined the model data and the more data needs to be added to the high-frequency update region; the higher the LOD level, the simpler the model data and the less data needs to be added." This avoids redundant data of unused LOD level objects occupying high-frequency update region resources. For example: LOD0 (assuming a high-precision model) requires the addition of model data for high-frequency updates, including "complete transformation matrix (describing position, orientation, and scaling), incremental data of fine-scale model vertices (such as local pose adjustment data for car windows and door handles), and LOD status markers," because high-precision models need to synchronize detailed pose changes in real time and require high-frequency updates of complete data; LOD1 (medium-precision model) requires the addition of model data including "simplified transformation matrix (describing only overall position and orientation, ignoring local detail scaling), core data of medium-precision model vertices (such as pose data of the car body outline), and LOD status markers," by simplifying local detail data and retaining only key data that affects the overall appearance; LOD2 (low-precision model) requires the addition of model data including only "basic transformation matrix (describing only overall position, ignoring minor changes in orientation and scaling) and LOD status markers," because low-precision models simplify the outline and do not need to update local vertex data, only need to synchronize position changes.

[0089] After filtering, the GPU writes the model data to the high-frequency update area in groups according to "Instance ID-LOD level". This embodiment of the invention has significant advantages by dynamically determining the LOD level and filtering model data based on distance. On the one hand, it reduces the amount of dynamic data and lowers the memory bandwidth usage. By filtering model data by LOD level, only the core data of low LOD level objects is retained, further reducing the amount of dynamic data in the high-frequency update area and reducing redundant data, thus adapting to the limited bandwidth resources of automotive GPUs. On the other hand, it shortens the data update latency and improves real-time performance. The high-frequency update area only processes model data that is adapted to the LOD level, avoiding invalid updates of redundant data of low LOD objects. At the same time, it adapts to changes in the vehicle's perspective, ensuring a balance between rendering accuracy and efficiency. The LOD level is dynamically adjusted according to the distance between the object and the virtual eye position, ensuring the rendering accuracy of near-distance objects while improving rendering efficiency by simplifying the model data of far-distance objects. In scenarios with rapidly changing vehicle perspectives, the LOD level and high-frequency update data can be adjusted in real time to avoid the problem of "near-distance blurring and far-distance redundancy", balancing image quality and rendering speed.

[0090] In some optional implementations, prior to step S105, the following step is also included: Step f1: Merge the instance data to be rendered into multiple batches based on the same model, the same material, and the same level of detail. The instance data to be rendered in one batch is used for simultaneous rendering.

[0091] Specifically, if a rendering command is issued separately for each instance of data to be rendered, the GPU rendering interface needs to be called repeatedly, resulting in an excessive number of rendering commands per frame. The time spent on command scheduling accounts for a larger portion of the single-frame rendering latency, making it difficult to meet the rendering requirements of "few commands and high parallelism" for high-density dynamic scenes in vehicles. This embodiment of the invention effectively solves the above problems by merging the instance data to be rendered into batches according to "same model, same material, and same level of detail".

[0092] First, the core basis and data preprocessing for batch merging are clarified. The instance data to be rendered already includes each instance's "Model ID" (identifying the corresponding 3D model resource, such as car model ID=001, pedestrian model ID=002), "Material ID" (identifying the instance's appearance material parameters, such as red car paint material ID=101, gray clothing material ID=102), and "Level of Detail." This embodiment of the invention uses these three pieces of information as the key dimensions for batch merging, ensuring that all instances within the same batch have completely consistent information in these three aspects.

[0093] Before the merging operation, the GPU sorts all the data to be rendered in the order of "Model ID → Material ID → LOD Level". Then, it performs batch merging and data integration. For each unit with the same "Model ID + Material ID + LOD Level" determined by sorting, the GPU checks whether the number of instances in the unit meets the batch processing threshold (e.g., ≥32 instances). If the threshold is met, the data to be rendered for all instances in the unit is directly merged into one batch. If the threshold is not met (e.g., only 15 instances), the unit is temporarily stored. After all instances have been traversed, multiple smaller units with the same "Model ID + Material ID + LOD Level and less than the threshold" are further merged (e.g., merging three units with 15 instances each, "Model ID=001 + Material ID=101 + LOD1", into one batch with 45 instances), to avoid redundant rendering instructions due to too many small batches.

[0094] During the data integration phase, the GPU creates a unique "batch descriptor" for each batch, recording the core information of that batch, including the total number of instances within the batch, model ID, material ID, and LOD level. The merged batch descriptor is then written to an additional buffer for each batch.

[0095] In the subsequent rendering stage, the GPU reads the batch descriptor and calls the "instantiation drawing instruction," such as `DrawInstancedIndirect`, in one go to render all instances within a batch simultaneously. Based on the above techniques, instance data to be rendered is merged into batches according to the same model, material, and level of detail, achieving batch rendering. Processing multiple instances in a single batch reduces the number of GPU drawing instruction calls, improving rendering efficiency by 3-5 times, especially in scenes with a large number of similar instances (such as multiple identical vehicle models and streetlights on a highway). Batch rendering also reduces GPU shader core idle rate, fully utilizing hardware resources. In high-density automotive scene rendering, it can quickly process massive numbers of similar instances, avoiding the inefficiency caused by rendering individual instances independently, and ensuring high frame rate output.

[0096] In some optional implementations, step S105 above includes: Step g1: Determine the cone of the virtual eye position; Step g2: Use the view frustum to filter the first invisible object in the instance data to be rendered that falls outside the view frustum's range; Step g3: Determine the second occluded invisible object in the instance data to be rendered by using the occlusion query kernel function; Step g4: Determine the culling mask based on the first invisible object and the second invisible object. The culling mask is used to notify the thread to skip the rendering of the corresponding invisible object. Step g5: Compress the removal mask and store it in the additional buffer.

[0097] Specifically, in the visibility determination of traditional automotive 3D rendering, if the entire rendering process is performed directly on all instances to be rendered without first filtering out invisible objects, it will result in 30%-40% redundant rendering. For example, distant vehicles outside the view frustum and pedestrians completely obscured by buildings in front will still consume GPU computing power for invalid operations such as vertex transformation and fragment shading, resulting in serious waste of video memory bandwidth and making it difficult to meet the rendering requirements of "low redundancy and high computing power utilization" for high-density dynamic scenes in vehicles.

[0098] In this embodiment of the invention, the viewing frustum of the virtual eye position is determined. The viewing frustum is a hexahedral structure with the virtual eye position as its vertex, covering the currently observable three-dimensional space. It includes a near plane, a far plane, and four sides (left, right, top, and bottom). These six sides collectively define the "area visible to the virtual eye position." The near plane is the plane closest to the virtual eye position (e.g., 1m away, to avoid rendering invalid models that are too close), and the far plane is the plane furthest from the virtual eye position (e.g., 500m away, objects beyond this distance do not need to be rendered). The four sides are determined by the field of view angle of the virtual eye position (e.g., 90° horizontal field of view and 60° vertical field of view in a vehicle scene). The GPU reads the coordinates of the virtual eye position in the current frame, the field of view angle, and the distance between the near and far planes, and calls the "view frustum generation function" to calculate the plane equations of the six sides, thereby determining the complete viewing frustum structure and providing a basis for subsequent filtering of invisible objects.

[0099] Next, the first invisible object is filtered using the view frustum. In this embodiment of the invention, the bounding box data of all instances to be rendered is first scheduled through the computation shader. The bounding box is the smallest axis-aligned cuboid that encloses the instance object. The bounding box data of each instance contains the coordinates of the smallest and largest vertices of the cuboid, stored in a preset field in the instance buffer. Subsequently, an "intersection test between the bounding box and the view frustum" is performed on each instance. The core judgment logic includes: 1. Determining whether all vertices of the bounding box are behind the near plane of the view frustum. If the z-coordinates of all vertices are less than the z-coordinate of the near plane, the instance is completely behind the near plane and is determined to be invisible; 2. Determining whether the bounding box is completely outside one side of the view frustum. If the bounding box is completely outside one side of the view frustum, the instance is completely outside the left side of the view frustum and is determined to be invisible; 3. Determining whether the bounding box intersects with the view frustum. If some vertices of the bounding box are inside the view frustum, some are outside, or completely inside the view frustum, the bounding box and the view frustum intersect, and the view frustum is determined to be visible. Through the above test, the GPU filters out all instances that fall outside the view frustum, which are the first invisible objects.

[0100] Meanwhile, the occlusion query kernel function can further identify the second invisible object. For the visible frustum instances selected in the above steps, the GPU starts the occlusion query kernel function and schedules threads to traverse all visible frustum instances. For each instance, its projection depth and screen space position are calculated. There are two methods for occlusion determination. The first is depth map occlusion detection, which compares the instance's projection center point or bounding box projection area with the GPU's current frame depth map. If the instance depth is greater than the existing pixel value, it is determined to be occluded. The second is Hierarchical Z-Buffer (HZB) query optimization, which combines multi-level Z-maps to quickly perform occlusion determination, improving culling efficiency in large scenes.

[0101] For example, when the scene is determined not to belong to a large scene based on the number of objects (the number of objects in the scene is less than a preset object number threshold), the center point coordinates of the instance bounding box can be converted to screen space coordinates using a view projection matrix (a matrix that converts 3D world coordinates to 2D screen coordinates). Simultaneously, the projection depth of this center point in screen space (i.e., the depth value in the depth buffer, which is positively correlated with the distance from the instance to the virtual eye position) is calculated. Subsequently, the "depth map occlusion detection" method is used to perform occlusion judgment. The GPU reads the depth map rendered in the current frame (the depth map stores the minimum depth value of each pixel on the screen, generated from previously rendered nearby instances), compares the depth value of the pixel in the depth map corresponding to the instance bounding box projection area with the instance's projection depth. If the instance's projection depth is greater than the corresponding pixel's depth value, it means that the instance is behind a rendered nearby instance and is completely occluded, thus being determined as the second invisible object; if at least one pixel's depth value is greater than the instance's projection depth, the instance is not completely occluded and is determined to be visible.

[0102] For example, when a scene is determined to be large based on the number of objects (the number of objects in the scene is greater than or equal to a preset object count threshold), the GPU employs hierarchical Z-buffer lookup optimization for large-scale scenes, quickly batch-judging occlusion through multi-level Z-maps. Specifically, it first determines the maximum depth value of the instance's projection region in the higher-level Z-map. If the maximum depth value in the higher-level Z-map is less than the instance's projection depth, the instance is completely occluded in that region, eliminating the need to traverse lower-level pixels and significantly improving judgment efficiency. Through this process, the GPU filters out occluded instances, which are then designated as the second invisible objects.

[0103] Subsequently, this embodiment of the invention determines a culling mask based on the first invisible object and the second invisible object. The culling mask is a dataset stored in binary bits, with each instance corresponding to a Boolean bit (1 bit). The specific rule is as follows: if the instance is the first invisible object (view frustum visibility = 0) or the second invisible object (occlusion visibility = 0), then the mask bit corresponding to that instance is set to "0", indicating that rendering should be skipped; if the instance is neither the first nor the second invisible object (view frustum visibility = 1 and occlusion visibility = 1), then the mask bit is set to "1", indicating that rendering should be retained. The length of the culling mask is consistent with the total number of instances to be rendered. For example, if there are 1000 instances to be rendered, then the culling mask is 1000 bits of binary data, and the position of each bit corresponds one-to-one with the instance ID (e.g., the 0th bit corresponds to the instance with ID = 0, and the 1st bit corresponds to the instance with ID = 1).

[0104] Considering that the mask can be very long (tens of thousands of instances), direct storage would consume a large amount of memory or GPU memory. Graph compression algorithms compress the binary mask to reduce space usage. Finally, the compressed mask, after being discarded, is stored in an additional buffer.

[0105] Based on the aforementioned technical methods, the first invisible object outside the view frustum is filtered by frustum culling, and the second invisible object that is occluded is determined by the occlusion query kernel function. This dual culling significantly reduces redundant rendering. The culling mask is compressed and stored to reduce GPU memory usage, and the use of an additional buffer facilitates subsequent fast retrieval. In complex vehicular traffic conditions (such as congested roads and multiple building occlusions), invisible objects can be efficiently filtered out, avoiding wasted GPU computing power rendering instances outside the view or occluded, thus improving rendering resource utilization and real-time performance.

[0106] In some optional implementations, to further enhance the flexibility of the culling strategy in vehicle scenarios and the rendering adaptability to complex road conditions, embodiments of the present invention also additionally design a programmable culling strategy interface and a vehicle semantic fusion mechanism.

[0107] I. Programmable Expulsion Strategy Interface To meet the diverse rejection requirements in vehicle scenarios (such as differentiated visibility determination under different weather and lighting conditions), this invention presents a programmable rejection strategy interface. By providing standardized rejection algorithm slots, it supports developers in injecting custom rejection logic according to actual business scenarios, breaking the adaptation limitations of traditional fixed rejection algorithms.

[0108] This interface is implemented based on a programmable framework of GPU computing shaders, and its core consists of three parts: an "algorithm registration module," a "parameter configuration module," and a "logic execution module." The algorithm registration module uses pre-defined standardized culling algorithm slots. Developers can register their custom algorithms to the specified slots via interface functions without modifying the existing rendering pipeline code.

[0109] The parameter configuration module allows developers to configure dynamic parameters for custom culling logic (such as "visibility threshold" in fog culling and "light intensity threshold" in nighttime light culling). The parameters are stored in a read-write configuration buffer in the GPU memory, enabling dynamic adjustment of the culling logic.

[0110] In the "semantic-aware culling" stage of the dynamic culling process, the logic execution module calls the custom algorithms in each slot to further filter the instance data after frustum culling and occlusion culling (for example, culling objects below the "visibility threshold" in the fog algorithm, and culling objects below the "light intensity threshold" at night). Finally, the custom visibility identifier is merged with the original culling mask to generate the final instance visibility result.

[0111] II. In-vehicle semantic fusion mechanism To address the issue of judgment bias caused by the lack of prior scene information in traditional culling algorithms under complex road conditions (such as tunnels and urban canyons), this invention proposes an in-vehicle semantic fusion mechanism. By integrating prior information from high-precision maps, it guides occlusion culling, thereby improving rendering stability and accuracy.

[0112] This mechanism first establishes a data interaction channel between the GPU and the vehicle-mounted high-precision map system to acquire semantic prior information from the high-precision map in real time. This includes 3D structural data of tunnels, building occlusion information on urban roads, lane line types, and traffic sign locations. In the "occlusion removal" stage of the dynamic removal process, this mechanism integrates the high-precision map prior information with traditional occlusion removal logic to perform semantic occlusion determination. For example, for instances inside a tunnel, since the tunnel wall is a fixed occlusion, the occlusion status can be quickly determined directly based on the relative position of the instance and the tunnel wall, without relying on depth map comparison, reducing computation time. For instances near tall buildings on both sides of the road, the mechanism combines the building outline bounding boxes to prioritize instances located directly behind the buildings as "occluded," improving the accuracy of occlusion removal.

[0113] Through the aforementioned programmable culling strategy interface and vehicle semantic fusion mechanism, this invention can flexibly adapt to the diverse needs of vehicle scenarios in optional implementations. Even in special environments such as foggy days and nighttime, as well as complex road conditions such as tunnels and urban canyons, it can still maintain efficient and accurate dynamic culling effects, further improving the practicality and reliability of vehicle 3D scene rendering.

[0114] In some alternative implementations, the method further includes: Step h1: Add a visibility marker to the header of each instance data to be rendered in the instance buffer based on the culling mask.

[0115] Specifically, the embodiments of the present invention conform to the design of "mask-data shared storage", adjust the storage structure of the instance buffer, reserve a 1-byte visibility flag bit in the header of each instance data block to be rendered (including model, material, LOD data), and extend the data block length (for example, from 64 bytes to 65 bytes). The flag bit is encoded in binary, with "1" indicating visibility and "0" indicating invisibility, which is consistent with the corresponding bit of the culling mask.

[0116] Next, the GPU uses a parallel write kernel function to map the culling mask to the flag bits, locates the header of the corresponding data block in the instance buffer by instance ID, and writes the mask binary value. During subsequent rendering, the GPU can read the instance data block and first determine the header flag: "1" means continue reading and rendering subsequent data, "0" means skip directly. This allows the GPU to quickly identify the instance visibility status during the rendering process without additional lookup of the culling mask, reducing memory addressing overhead. The visibility flag is closely associated with the instance data, improving read efficiency by 50% and avoiding processing delays caused by data separation. In the geometry shader and vertex shader stages of the rendering pipeline, subsequent operations on invisible instances can be quickly skipped, further reducing invalid computations and ensuring high frame rate rendering in automotive scenes, especially when instances change frequently in dynamic scenes, still efficiently filtering visible instances.

[0117] In some alternative implementations, the culling mask is also used to be read by the central processing unit (CPU), and the CPU and the graphics processing unit (GPU) transfer the culling mask and instance attribute data separately via different DMA channels.

[0118] Specifically, in an in-vehicle 3D rendering scene, the CPU needs to dynamically manage scene resources based on instance visibility status (such as unloading long-term invisible instances to free up memory), and at the same time, it needs to transmit instance attribute data to the GPU. Therefore, after generating the culling mask, the GPU, in addition to using it for its own rendering filtering, will also store it in a shared storage area accessible to the CPU in the video memory, ensuring that the CPU can read it through the memory mapping mechanism.

[0119] In addition, two independent DMA (Direct Memory Access) channels are configured between the CPU and GPU. DMA channels refer to "high-speed dedicated lines" that do not rely on the CPU and are managed by a hardware-level DMA controller, enabling independent data transfer between different storage units such as CPU memory and GPU memory. Channel 1 is dedicated to transmitting culling masks, and channel 2 is dedicated to transmitting instance attribute data. Throughout the process, the CPU does not need to wait for data transfer to complete and can simultaneously perform resource management (e.g., unloading invisible instances with IDs 201-500 based on the read culling mask, freeing up 20MB of memory). The GPU can also process the received instance attribute data in parallel. Compared to single-channel serial transmission, dual DMA channels significantly reduce the total transmission time and reduce memory bandwidth usage by 30%, ensuring the collaborative efficiency of the CPU and GPU in high-density automotive scenarios.

[0120] In the subsequent rendering process, if the rendering flow of this embodiment of the invention adopts indirect drawing technology (i.e., drawing is initiated autonomously by the GPU through Indirect Draw Buffer drawing instructions), the GPU will clear the drawing names corresponding to invisible instances in DrawIndirectBuffer (an indirect drawing buffer, a data buffer that stores drawing instructions). It iterates through the "instance ID range" of each drawing command in DrawIndirectBuffer. If an instance ID contained in a command corresponds to an "invisible" flag in the final visibility mask, the drawing parameters of the corresponding instance in that command are deleted, and only the drawing commands for visible instances are retained, thus reducing invalid rendering calls at the drawing instruction level.

[0121] After the GPU starts the graphics rendering pipeline, it executes the filtering logic for invisible instances in the geometry shader stage or vertex shader to further filter out invalid instance data.

[0122] First, the geometry shader uses an explicit check buffer (a read-only buffer bound to the final visibility mask) to precisely read the visibility flag of the currently processed instance based on its gl_InstanceID (a built-in variable automatically generated by the system and passed to the shader, specifically used for instantiating the rendering scene, identifying the unique index of the currently processed instance within the instantiation batch). For example, when the geometry shader processes an instance with gl_InstanceID=50, it reads the flag "0" from the culling mask and determines that the instance is invisible; when processing an instance with gl_InstanceID=100, it reads the flag "1" and determines that it is visible. For instances determined to be invisible, the geometry shader skips the subsequent vertex assembly (the operation of combining vertex data into primitives) and vertex transformation (such as the conversion from local coordinates to world coordinates) processes, and does not output any data to the subsequent rendering stage. For instances determined to be visible, the geometry shader continues to execute the complete processing logic. First, it performs the MVP transformation on the instance vertex data (i.e., the combined transformation of the model matrix (M), view matrix (V), and projection matrix (P) to convert the vertices from local space to screen space coordinates), then binds the material parameters corresponding to the instance, and passes the processed vertex data to the fragment shader stage of the graphics pipeline.

[0123] After filtering by the geometry shader, only valid geometric data of visible instances is output to the rasterization stage of the graphics pipeline. In this stage, the GPU first converts the processed vertex data of the visible instances into screen-space fragments (containing attributes such as color, depth, and texture coordinates), completing the discretization transformation of the primitives. For example, the body model of a visible vehicle instance consists of 1000 triangular primitives; the rasterization stage will convert these triangular primitives into 10000 fragments corresponding to the screen area. Simultaneously, the GPU binds the vertex buffer and index buffer of the instance and performs instantiation drawing operations based on gl_InstanceID, ensuring that the fragment data of each visible instance can be accurately associated with its corresponding instance information.

[0124] Subsequently, the fragment shader performs color and depth calculations on each fragment, and writes the results to the color buffer and depth buffer respectively. Finally, the image data in the color buffer is output to the in-vehicle display device, completing the rendering output of the entire 3D scene.

[0125] The technical solution provided by this invention proposes an architecture for collaborative rendering of instantiation and dynamic culling driven by the graphics processor. It achieves, for the first time, a closed-loop GPU-side processing of the entire process, from instantiation data generation and visibility determination to culling logic. Through a compute shader-driven dynamic batch generation mechanism, a multi-level semantic fusion culling algorithm, and a memory-computation resource collaborative optimization strategy, it significantly reduces the CPU's intervention frequency and memory bandwidth pressure. Its designed instantiation-culling joint buffer supports synchronous updates of LOD and visibility states, overcoming the resource duplication problem caused by the separation of instantiation data generation and culling processes in traditional solutions. Furthermore, this architecture, through a programmable culling interface and cross-platform instantiation backend encapsulation, adapts to heterogeneous automotive hardware environments, supporting real-time high-precision rendering of dynamic traffic scenes, thus forming a 3D graphics rendering solution that combines high efficiency, flexibility, and automotive-grade reliability.

[0126] This embodiment also provides a graphics processor-based 3D scene rendering apparatus, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0127] This embodiment provides a graphics processor-based 3D scene rendering device, such as... Figure 2 As shown, the device, applied to a graphics processor, includes: The instance attribute data receiving module 201 is used to receive instance attribute data sent by the central processing unit. The instance attribute data is data processed by the central processing unit using object metadata in an instantiation format. The instantiation format is a data format that the graphics processor can recognize and process. The object metadata is used to describe the object attributes in the 3D scene. The instance processing thread allocation module 202 is used to call the compute shader to allocate compute thread groups based on the number of objects in the instance attribute data. Instantiate the parallel computing module 203, which is used to compute the corresponding transformation matrix for each object in parallel through the computing thread group. The transformation matrix is ​​used to describe the pose of each object. The instantiation data generation module 204 is used to add instance attribute data and transformation matrix to the instance buffer to obtain the instance data to be rendered for each object. The instance buffer is a region in the graphics processor's video memory. The invisible culling module 205 is used to extract the data of the instance to be rendered from the instance buffer, and perform invisible object culling on the data of the instance to be rendered through the computing thread group to obtain the target instance data of the visible objects. Rendering module 206 is used to render the target instance data.

[0128] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0129] This invention also provides a computer device; please refer to [link / reference]. Figure 3 , Figure 3 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 3 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 3 Take a processor 10 as an example.

[0130] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0131] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0132] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0133] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0134] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0135] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0136] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0137] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A three-dimensional scene rendering method based on a graphics processor, characterized in that, Applied to a graphics processor, the method includes: The system receives instance attribute data sent by the central processing unit (CPU). The instance attribute data is data processed by the CPU using object metadata in an instantiation format. The instantiation format is a data format that the graphics processor can recognize and process. The object metadata is used to describe object attributes in a 3D scene. Based on the number of objects in the instance attribute data, the compute shader is invoked to allocate compute thread groups; The computation thread group calculates the corresponding transformation matrix for each object in parallel, and the transformation matrix is ​​used to describe the pose of each object. The instance attribute data and the transformation matrix are added to the instance buffer to obtain the instance data to be rendered for each object. The instance buffer is a region in the graphics processor's video memory. Extract the instance data to be rendered from the instance buffer, and perform invisible object culling on the instance data to be rendered through the computing thread group to obtain the target instance data of visible objects; The target instance data is rendered.

2. The method according to claim 1, characterized in that, The step of allocating a computation thread group by calling the computation shader based on the number of objects in the instance attribute data includes: Each computing thread group is configured by default to contain 128 computing threads; When a thread group of 128 computing threads exceeds the capacity of the graphics processor, reduce the number of computing threads in the thread group. The 3D scene is divided into even partitions based on the distribution of the number of objects in the 3D scene, and a corresponding computing thread group is assigned to each partition.

3. The method according to claim 1, characterized in that, The step of adding the instance attribute data and the transformation matrix to the instance buffer to obtain the renderable instance data for each object includes: Identify dynamic and static data in the instance data to be rendered. The dynamic data represents data that is likely to be updated as the frame changes, and the static data represents data that does not update as the frame changes. The dynamic data is stored in the high-frequency update area of ​​the instance buffer; The static data is stored in the static data area of ​​the instance buffer.

4. The method according to claim 3, characterized in that, The step of storing the dynamic data into the high-frequency update area of ​​the instance buffer includes: The dynamic data to be added to the current frame is compared with the dynamic data that already exists in the previous frame in the high-frequency update area to determine the target instance that has changed in the high-frequency update area. Update the data corresponding to the target instance using the dynamic data to be added in the current frame; The index of the target instance is recorded in an additional buffer, which is a region in the graphics processor's video memory.

5. The method according to claim 4, characterized in that, The step of updating the data corresponding to the target instance using the dynamic data to be added in the current frame includes: Using the dynamic data to be added to the current frame, the new data corresponding to the target instance is used to overwrite the corresponding old data in the first buffer. The state of the first buffer represents the buffer to be written to in the high-frequency update area for the current frame. The invariant instance data that has not changed relative to the previous frame is determined from the second buffer and referenced to the first buffer. The state of the second buffer represents the buffer in the high-frequency update area where the previous frame exists. When the first buffer is finished being written, the states of the first buffer and the second buffer are swapped.

6. The method according to claim 4, characterized in that, The step of recording the index of the target instance in the additional buffer includes: A unique row number is assigned to each computation thread using a counter, and the unique row number is used to indicate the position of a row in the additional buffer; The computation thread responsible for the target instance is invoked to record the index of the target instance in the additional buffer using the corresponding unique row number of the target instance.

7. The method according to claim 3, characterized in that, Before storing the dynamic data into the high-frequency update area of ​​the instance buffer, the method further includes: Based on the distance between each object and the virtual eye position in the dynamic data, the level of detail corresponding to each object is determined. The level of detail increases as the distance between the virtual eye position and the object increases. The level of detail is used to represent the roughness of the object model. When the level of detail is higher, the object model is rougher. The virtual eye position is used to represent the display viewpoint position of the rendered 3D scene. The model data that needs to be added to the high-frequency update zone in the dynamic data is determined based on the level of detail corresponding to each object.

8. The method according to claim 7, characterized in that, Before extracting the instance data to be rendered from the instance buffer and performing invisible object culling on the instance data to be rendered through a computing thread group to obtain the target instance data of visible objects, the method further includes: The data of instances to be rendered are merged into multiple batches based on the same model, material, and level of detail, with the data of instances to be rendered in one batch being rendered simultaneously.

9. The method according to claim 1, characterized in that, The step of extracting the instance data to be rendered from the instance buffer and performing invisible object culling on the instance data to be rendered through a computing thread group to obtain the target instance data of visible objects includes: The cone that determines the virtual eye position; The first invisible object falling outside the range of the view frustum in the instance data to be rendered is selected using the view frustum. The second invisible object occluded in the instance data to be rendered is determined by the occlusion query kernel function; A culling mask is determined based on the first invisible object and the second invisible object, and the culling mask is used to notify the thread to skip the rendering of the corresponding invisible object; The culling mask is compressed and stored in an additional buffer.

10. The method according to claim 9, characterized in that, The method further includes: A visibility marker is added to the header of each instance data to be rendered in the instance buffer based on the culling mask.

11. The method according to claim 10, characterized in that, The culling mask is also used to be read by the central processing unit, and the central processing unit and the graphics processing unit transfer the culling mask and the instance attribute data respectively through different DMA channels.

12. A three-dimensional scene rendering device based on a graphics processor, characterized in that, The device, applied to a graphics processor, includes: The instance attribute data receiving module is used to receive instance attribute data sent by the central processing unit. The instance attribute data is data processed by the central processing unit using object metadata in an instantiation format. The instantiation format is a data format that the graphics processor can recognize and process. The object metadata is used to describe the object attributes in the 3D scene. The instance processing thread allocation module is used to call the compute shader to allocate compute thread groups based on the number of objects in the instance attribute data. Instantiate a parallel computing module to compute the corresponding transformation matrix for each object in parallel through the computing thread group. The transformation matrix is ​​used to describe the pose of each object. An instantiation data generation module is used to add the instance attribute data and the transformation matrix to the instance buffer to obtain the rendering instance data of each object. The instance buffer is a region in the graphics processor's video memory. The invisible culling module is used to extract the instance data to be rendered from the instance buffer, and perform invisible object culling on the instance data to be rendered through the computing thread group to obtain the target instance data of visible objects. The rendering module is used to render the target instance data.

13. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method of any one of claims 1 to 11.

Images