Method and system for batch rendering optimization of super large scale model based on key-value pair mapping

Abstract

The application provides a large-scale model batch rendering optimization method and system based on key-value mapping, belonging to the technical field of computer graphics rendering. The application establishes the geometric vertex and texture coordinate of the key-value binding dynamic object in the GPU lock-free hash table. When multiple dynamic object proxies concurrently submit binding updates, the version identification values are compared. The key-value pairs to be updated with inconsistent versions are recorded as conflict nodes. Starting from the conflict node, the hash table is traversed downward to collect all key-value pairs directly or indirectly dependent on the conflict node to form a repair set. The predecessor dependency pointers and version time stamps are updated from low to high according to the dependency level. The current frame version snapshot is generated, and the geometric vertex coordinates and texture atlas coordinates in the snapshot are merged and written into the same vertex buffer object for batch rendering. The application guarantees the data causal consistency and rendering correctness of large-scale model batch rendering in a high-concurrency scenario.

Description

Technical Field

[0001] This application belongs to the field of computer graphics rendering technology, and in particular relates to a method and system for optimizing batch rendering of ultra-large-scale models based on key-value pair mapping. Background Technology

[0002] With the rapid development of applications such as digital twins and smart cities, the demand for real-time rendering of ultra-large-scale 3D scenes is increasing daily, with the number of dynamic objects that need to be rendered in a single frame reaching tens or even hundreds of thousands. Batch rendering technology, by merging the geometric vertex data and texture coordinates of multiple objects into a unified vertex buffer object, can significantly reduce the number of GPU drawing calls and is a key means to improve the rendering performance of large-scale scenes. The key-value pair mapping-based data management method can efficiently maintain the vertex and texture binding relationship of dynamic objects, providing a data foundation for batch rendering.

[0003] In existing technologies, some batch rendering solutions use texture atlas technology to merge multiple textures into a single atlas, achieving batch rendering through pre-computed texture coordinate mapping. Other solutions utilize GPU instantiation rendering or indirect rendering instructions to reduce communication overhead between the CPU and GPU. Some dynamic scene rendering systems employ caching mechanisms to manage the geometric and texture data of objects, triggering local reconstruction by marking invalid regions when data is updated.

[0004] However, existing technologies lack effective version conflict detection and dependency tracking mechanisms when handling multiple concurrent proxies updating dynamic object mappings simultaneously. When the mapping of an object is rolled back due to a concurrent conflict, the mappings of other objects that depend on that object cannot be automatically detected and repaired, leading to a break in the cross-frame causal dependency chain and ultimately rendering incorrect batched images. Furthermore, existing solutions often use global locks or segmented locks to ensure data consistency, which suffers from severe performance bottlenecks in high-concurrency write scenarios, making it difficult to support the real-time rendering needs of ultra-large-scale scenes. Therefore, existing technologies suffer from technical problems such as dependency breakage due to concurrent write conflicts, inability to guarantee cross-frame causal consistency, and performance limitations in high-concurrency scenarios. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for optimizing batch rendering of ultra-large-scale models based on key-value pair mapping, so as to solve the problems of concurrent write conflicts causing the breakage of dependency relationships, the inability to guarantee cross-frame causal consistency, and the performance limitations in high-concurrency scenarios in the prior art.

[0006] To address the aforementioned technical problems, in a first aspect, this application provides a method for optimizing batch rendering of ultra-large-scale models based on key-value pair mapping, comprising: In the GPU lock-free hash table, key-value pairs of dynamic objects are created. The key-value pairs are used to bind geometric vertex coordinates and texture atlas coordinates and include a key identifier, a version timestamp field for storing version identifier values, and a predecessor dependency pointer field. The predecessor dependency pointer field is used to record the key identifier of the predecessor key-value pair and the version identifier value of the version timestamp field. Multiple dynamic object proxies concurrently submit key-value pair binding updates. If the version identifier value of the predecessor key-value pair recorded in the predecessor dependency pointer field of the key-value pair to be updated is inconsistent with the current version identifier value of the version timestamp field of the corresponding predecessor key-value pair in the lock-free hash table, the key-value pair binding update is rejected, and the key-value pair to be updated is written as a conflict node into the conflict buffer. Starting with each conflict node in the conflict buffer, traverse downwards in the lock-free hash table to determine key-value pairs that directly or indirectly depend on the conflict node, thus obtaining a set of key-value pairs to be repaired. According to the order of dependency hierarchy of each key-value pair in the set of key-value pairs to be repaired from smallest to largest, update the predecessor dependency pointer field and version timestamp field of each key-value pair to obtain the updated key-value pair set; Generate a version snapshot of the current frame based on the updated key-value pair set, and merge the geometric vertex coordinates and texture atlas coordinates of each key-value pair in the version snapshot into the same vertex buffer object for batch rendering.

[0007] Optionally, the version identifier value is a monotonically increasing identifier value formed by the frame number of the current frame and the update number of the key-value pair, where the current frame is one rendering submission cycle; The predecessor dependency pointer field includes a predecessor key identifier and a predecessor version identifier value. The predecessor key identifier is used to locate the predecessor key-value pair, and the predecessor version identifier value is used to record the version identifier value of the version timestamp field when the predecessor key-value pair is depended upon.

[0008] Optionally, a conflicting node is a record formed by binding the key-value pair to be updated that was rejected for write with the key-value pair to be updated that was committed for update. The conflict buffer is a queue of preset length in the GPU memory. Writing to the conflict buffer involves atomically appending the key identifier of the conflict node, the predecessor key identifier and the predecessor version identifier value included in the predecessor dependency pointer field of the conflict node to the conflict buffer.

[0009] Optionally, starting from each conflict node in the conflict buffer, the key-value pairs that directly or indirectly depend on the conflict node are determined by traversing downwards in the lock-free hash table, resulting in a set of key-value pairs to be repaired, including: Using each conflict node in the conflict buffer as the first key-value pair, search the lock-free hash table for key-value pairs where the predecessor key identifier in the predecessor dependency pointer field is the same as the key identifier in the first key-value pair, and the predecessor version identifier value in the predecessor dependency pointer field is the same as the version identifier value in the version timestamp field of the first key-value pair. The search continues with the first key-value pair found as the first key-value pair to be updated, until no new key-value pairs are found. All the key-value pairs found are then identified as the set of key-value pairs to be repaired.

[0010] Optionally, before updating the predecessor dependency pointer field and version timestamp field of each key-value pair in the set of key-value pairs to be repaired in ascending order of dependency hierarchy, and obtaining the updated key-value pair set, the method further includes: Each key-value pair in the set of key-value pairs to be repaired is taken as the second key-value pair. The predecessor key identifier and predecessor version identifier values ​​included in the predecessor dependency pointer field of the second key-value pair are read. The lock-free hash table is searched for key-value pairs whose key identifier is the same as the predecessor key identifier and whose version identifier value included in the version timestamp field is the same as the predecessor version identifier value. The search continues with the found key-value pair as the updated second key-value pair until the predecessor dependency pointer field of the updated second key-value pair is empty. The number of key-value pairs that the updated second key-value pair with the empty predecessor dependency pointer field passes through to reach the key-value pair in the set of key-value pairs to be repaired is calculated, and the dependency hierarchy of each key-value pair is obtained.

[0011] Optionally, according to the ascending order of dependency hierarchy of each key-value pair in the set of key-value pairs to be repaired, update the predecessor dependency pointer field and version timestamp field of each key-value pair to obtain the updated key-value pair set, including: When multiple key-value pairs with the same key identifier exist in the set of key-value pairs to be repaired, retain the key-value pair with the latest version identifier value in the version timestamp field of the current frame to obtain the adjusted set of key-value pairs to be repaired; When multiple key-value pairs with the same dependency level exist, update the predecessor dependency pointer field and version timestamp field of each key-value pair in the adjusted set of key-value pairs to be repaired in parallel. Otherwise, update the predecessor dependency pointer field and version timestamp field of each key-value pair in the adjusted key-value pair set to be repaired in ascending order of dependency hierarchy to obtain the updated key-value pair set.

[0012] Optionally, update the predecessor dependency pointer field and version timestamp field of each key-value pair in the adjusted set of key-value pairs to be repaired, including: Read the version identifier value of the current key identifier and version timestamp field of each key-value pair in the adjusted key-value pair set to be repaired from the lock-free hash table; Write the key identifier and version identifier values ​​to the predecessor dependency pointer field of the key-value pair; Write the new version identifier value generated in the current frame into the version timestamp field of the key-value pair.

[0013] Optionally, the version snapshot is a read-only copy of the current frame that is independent of the lock-free hash table; Generate a version snapshot of the current frame based on the updated key-value pair set, including: During the current frame rendering submission phase, the version identifier values ​​of the key identifier, geometric vertex coordinates, texture atlas coordinates, and version timestamp fields of all key-value pairs are read from the updated key-value pair set. The key identifier, geometric vertex coordinates, texture atlas coordinates, and version identifier value are copied to the storage area of ​​the GPU memory to obtain a version snapshot, and the version snapshot is released after the current frame rendering is completed.

[0014] Secondly, this application provides a batch rendering optimization system for ultra-large-scale models based on key-value pair mapping, including: The module is used to create key-value pairs for dynamic objects in the GPU lock-free hash table. The key-value pairs are used to bind geometric vertex coordinates and texture atlas coordinates and include a key identifier, a version timestamp field for storing version identifier values, and a predecessor dependency pointer field. The predecessor dependency pointer field is used to record the key identifier and version identifier value of the version timestamp field of the predecessor key-value pair. The write module is used for multiple dynamic object proxies to concurrently submit key-value pair binding updates. If the version identifier value of the predecessor key-value pair recorded in the predecessor dependency pointer field of the key-value pair to be updated is inconsistent with the current version identifier value of the version timestamp field of the corresponding predecessor key-value pair in the lock-free hash table, the key-value pair binding update is rejected, and the key-value pair to be updated is written as a conflict node into the conflict buffer. The generation module is used to determine the key-value pairs that directly or indirectly depend on the conflicting nodes by traversing down the lock-free hash table, starting from each conflicting node in the conflict buffer, and to obtain the set of key-value pairs to be repaired. The generation module is also used to update the predecessor dependency pointer field and version timestamp field of each key-value pair in the set of key-value pairs to be repaired in ascending order of dependency hierarchy, so as to obtain the updated key-value pair set. The rendering module generates a version snapshot of the current frame based on the updated key-value pair set, and merges the geometric vertex coordinates and texture atlas coordinates of each key-value pair in the version snapshot into the same vertex buffer object for batch rendering.

[0015] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor, configured to implement the steps of the key-value pair mapping-based batch rendering optimization method for ultra-large-scale models as described in the first aspect above, when executing the computer program.

[0016] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps of the large-scale model batch rendering optimization method based on key-value pair mapping described in the first aspect above.

[0017] The batch rendering optimization method for ultra-large-scale models based on key-value pair mapping provided in this application establishes a version tracking and causal dependency recording mechanism for dynamic object mapping relationships by configuring a version timestamp field and a predecessor dependency pointer field for each key-value pair in the GPU lock-free hash table. When multiple dynamic object proxies concurrently submit binding updates, by comparing the predecessor version identifier value of the key-value pair to be updated with the current version identifier value of the corresponding predecessor key-value pair in the lock-free hash table, version conflicts caused by concurrent contention can be accurately identified, and conflicting nodes are written to a buffer instead of being directly discarded.

[0018] Starting from the conflict node, the algorithm traverses downwards through the lock-free hash table, automatically discovering all downstream key-value pairs that directly or indirectly depend on the conflict node along the dependency graph formed by the predecessor dependency pointer field. It then updates the predecessor dependency pointer field and version timestamp field layer by layer from low to high dependency level, ensuring that version consistency across the entire dependency chain is restored. Finally, by generating a snapshot of the current frame version and merging the geometric vertex coordinates and texture atlas coordinates from the snapshot into a unified vertex buffer object, it ensures that the data used for batch rendering comes from a causally consistent mapping version.

[0019] Compared with existing technologies, this application achieves high-concurrency writing based on lock-free hash tables. At the same time, through automatic detection of version conflicts, complete tracking of dependency chains, and cascading repair, it solves the technical problems of cross-frame causal dependency chain breakage, rendering result errors, and performance limitations in high-concurrency scenarios caused by concurrent write conflicts, significantly improving the correctness and concurrent processing capabilities of real-time rendering of ultra-large-scale dynamic scenes.

[0020] Furthermore, this application achieves precise location of downstream dependent nodes during downward traversal by using conflicting nodes as the first key-value pair and searching in a lock-free hash table for all key-value pairs whose predecessor dependency pointer field points to the first key-value pair.

[0021] Specifically, by matching the predecessor key identifier and predecessor version identifier recorded in the predecessor dependency pointer field, it is possible to accurately identify which key-value pairs logically depend on a specific version of the current conflicting node, avoiding misjudgments or omissions. The searched key-value pairs are then used as new first key-value pairs to continue the recursive search until no new key-value pairs are found, ensuring complete coverage of the dependency chain.

[0022] Compared to existing technologies that only handle direct dependencies or rely on manually marking invalid regions, this application, through chain-like tracing of predecessor dependency pointer fields, can automatically discover indirect dependencies without pre-constructing a global dependency graph or maintaining an additional index structure, thus reducing storage overhead and improving traversal efficiency. Therefore, this application, through a recursive search mechanism based on predecessor dependency pointer fields, solves the problems of incomplete dependency tracking and missing indirect dependency node repair in existing technologies, ensuring the comprehensiveness and reliability of conflict resolution. Attached Figure Description

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

[0024] Figure 1 A flowchart illustrating a method for optimizing batch rendering of ultra-large-scale models based on key-value pair mapping, provided in an embodiment of this application; Figure 2 This is a schematic diagram of a key-value pair data structure provided in an embodiment of this application; Figure 3 A schematic diagram illustrating a process for updating a set of key-value pairs, provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a large-scale model batch rendering optimization system based on key-value pair mapping provided in an embodiment of this application. Detailed Implementation

[0025] Batch optimization techniques in real-time rendering of ultra-large-scale 3D scenes face key challenges when multiple concurrent agents collaboratively update dynamic object mapping relationships: Existing solutions typically adopt simple write rejection or overwrite strategies after detecting version conflicts, but lack the ability to track dependency chains. As a result, when the vertex-texture mapping of an object is rolled back due to concurrent conflicts, other downstream objects that depend on the mapping version of that object cannot perceive this change and still hold references to the invalidated version. Ultimately, this leads to vertex and texture mismatches during the batch rendering stage, manifesting as visual errors such as texture misalignment and model artifacts.

[0026] More seriously, this chain of dependencies exhibits a cascading effect, meaning that a single conflicting node can indirectly affect dozens or even hundreds of downstream objects, without the current technology being aware of it. Furthermore, to ensure data consistency during concurrent writes, existing solutions generally rely on global locks or fine-grained segmented lock mechanisms. In high-concurrency scenarios where hundreds of dynamic object proxies simultaneously update mapping relationships, lock contention leading to performance degradation becomes the core bottleneck restricting real-time rendering frame rates, making it difficult to meet the stringent millisecond-level response requirements of applications such as digital twin cities.

[0027] To address the aforementioned issues, this application proposes an optimization method for batch rendering of ultra-large-scale models based on key-value pair mapping. Its core lies in the ability to establish version tracking and causal dependency recording capabilities for dynamic object mapping relationships in a GPU lock-free hash table through a dual mechanism of version timestamp field and predecessor dependency pointer field.

[0028] Specifically, when multiple dynamic object proxies concurrently submit key-value pair binding updates, conflicts are accurately detected by comparing the predecessor version identifier value. Rejected updates are written to the buffer as conflict nodes instead of being simply discarded. Then, starting from the conflict node, the process traverses downwards along the predecessor dependency pointer field in a lock-free hash table, automatically discovering all downstream key-value pairs that directly or indirectly depend on the conflict node, forming a set to be repaired. The predecessor dependency pointer field and version timestamp field are then updated layer by layer from low to high dependency hierarchy to ensure version consistency is restored throughout the dependency chain. Finally, a snapshot of the current frame version is generated for use by the rendering thread, ensuring that the mapping data read by batch rendering comes from a complete causal semantic version combination.

[0029] This method abandons the traditional global lock or segmented lock mechanism and achieves high-concurrency writing based on lock-free hash tables and atomic operations. At the same time, through automatic version conflict detection, recursive tracing of dependency chains and cascading repair, it solves the problems of cross-frame causal dependency chain breakage, rendering result errors and lock contention performance bottleneck in high-concurrency scenarios caused by concurrent writing in existing technologies. It significantly improves the correctness, concurrency processing capability and frame rate stability of real-time rendering of ultra-large-scale dynamic scenes.

[0030] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0031] To address the problems of existing technologies, embodiments of this application provide a method, apparatus, device, computer storage medium, and computer program product for optimizing batch rendering of ultra-large-scale models based on key-value pair mapping. The method for optimizing batch rendering of ultra-large-scale models based on key-value pair mapping provided in this application embodiment will be described first below.

[0032] Figure 1 This illustration shows a flowchart of a batch rendering optimization method for ultra-large-scale models based on key-value pair mapping, provided in one embodiment of this application. Figure 1 As shown, the method includes: S101. Establish key-value pairs for dynamic objects in the GPU lock-free hash table. The key-value pairs are used to bind geometric vertex coordinates and texture atlas coordinates and include a key identifier, a version timestamp field for storing version identifier values, and a predecessor dependency pointer field. The predecessor dependency pointer field is used to record the key identifier of the predecessor key-value pair and the version identifier value of the version timestamp field.

[0033] Optionally, in step S101, the version identifier value is a monotonically increasing identifier value formed by the frame number of the current frame and the update sequence number of the key-value pair, where the current frame is a rendering submission cycle.

[0034] In step S101, the predecessor dependency pointer field includes a predecessor key identifier and a predecessor version identifier value. The predecessor key identifier is used to locate the predecessor key-value pair, and the predecessor version identifier value is used to record the version identifier value of the version timestamp field when the predecessor key-value pair is depended upon.

[0035] A GPU lock-free hash table is a hash table data structure deployed in GPU memory that uses atomic operations rather than mutex locks to control concurrent writes. Multiple dynamic object proxies can submit read and write operations to it concurrently without blocking each other. Figure 2 This is a schematic diagram of a key-value pair data structure provided in an embodiment of this application. For example... Figure 2 As shown, a key-value pair is a data record unit used to bind the geometric vertex coordinates and texture atlas coordinates of a single dynamic object, and each key-value pair corresponds to the rendering binding state of a dynamic object in the scene at the current moment.

[0036] Combination Figure 2 The key-value pair data structure is specifically divided into several subfields: the key identifier is used to uniquely identify the number of a key-value pair and can be a combination of object type code and object sequence number; the version timestamp field is used to store the version identifier value and the data format of this field can be an unsigned 64-bit integer; the version identifier value is a monotonically increasing value composed of the frame sequence number of the current frame and the update sequence number of the key-value pair in the current frame, and its update rule is to increment every time a new frame is added or a valid binding update occurs; the current frame refers to a complete rendering submission cycle from the start of receiving dynamic object binding updates to the completion of rendering submission.

[0037] The geometric vertex coordinates and texture atlas coordinates are used to independently record the rendering space and texture mapping data required by the object. The predecessor dependency pointer field is a data field used to record the reference information of the predecessor key-value pair it depends on, and includes two parts: the predecessor key identifier and the predecessor version identifier. The predecessor key identifier refers to the key identifier of the predecessor key-value pair that the current key-value pair depends on, and is used to locate the predecessor key-value pair in the GPU lock-free hash table. The predecessor version identifier refers to the version identifier value stored in the version timestamp field of the predecessor key-value pair when it is depended on by the current key-value pair.

[0038] A lock-free hash table is initialized in GPU memory, allocating contiguous storage space and pre-setting the hash table capacity to accommodate key-value pairs of all dynamic objects in the scene. For each dynamic object in the scene, its geometric vertex coordinate data and texture atlas coordinate data are collected. The geometric vertex coordinate data comes from the model vertex data exported during the scene modeling stage, and the texture atlas coordinate data comes from the atlas coordinate mapping table generated during the texture packaging stage. Together, they describe the geometric shape and appearance texture of the dynamic object during rendering.

[0039] Next, a unique key identifier is generated for the dynamic object. A version identifier value is generated based on the current frame sequence number and the update sequence number of the object in the current frame. The update sequence number is obtained concurrently by multiple dynamic object proxies sending hardware-level atomic addition instructions to a global update counter deployed in GPU memory, and the boundary constraints of the update sequence number are set to ensure that its value is strictly less than 1. This ensures that the version identifier value remains strictly monotonically increasing throughout the entire high-concurrency rendering frame sequence, avoiding data overflow conflicts between frames.

[0040] If the dynamic object logically depends on another dynamic object, the predecessor key identifier and its current version identifier value of the dependent object are recorded in the predecessor dependency pointer field; if the dynamic object does not depend on any other object, the predecessor dependency pointer field is set to null. Finally, the complete key-value pair is written to the corresponding storage slot in the GPU lock-free hash table.

[0041] Specifically, taking a digital twin city scenario as an example, such as Figure 2 The identifiers within each subfield are shown below. The scenario includes dynamic vehicle objects and building component objects. For a running bus object, the key identifier of its corresponding key-value pair is denoted as... Collect the geometric vertex coordinates of the current frame, and denote them as the vertex set. , where each vertex Three-dimensional coordinates Simultaneously, the corresponding texture atlas coordinate data is collected and denoted as... Each texture coordinate Two-dimensional coordinates .

[0042] Assuming the current frame number is The update sequence number of the bus object in the current frame is The version identifier value stored in the version timestamp field is then generated as... This bus object does not depend on any other objects, and the predecessor dependency pointer field is set to null. The key-value pairs that fully include the corresponding field data will be... Write to the GPU lock-free hash table.

[0043] S102. Multiple dynamic object proxies concurrently submit key-value pair binding updates. If the version identifier value of the predecessor key-value pair recorded in the predecessor dependency pointer field of the key-value pair to be updated is inconsistent with the current version identifier value of the version timestamp field of the corresponding predecessor key-value pair in the lock-free hash table, the key-value pair binding update is rejected, and the key-value pair to be updated is written as a conflict node into the conflict buffer.

[0044] Optionally, in step S102, the conflicting node is the record formed by binding the key-value pair to be updated, which was rejected for writing, with the key-value pair to be updated submitted for updating.

[0045] In step S102, the conflict buffer is a queue of a preset length in the GPU memory. Writing to the conflict buffer includes writing the key identifier of the conflict node, the predecessor key identifier and the predecessor version identifier value included in the predecessor dependency pointer field of the conflict node to the conflict buffer in an atomic append manner.

[0046] Dynamic object proxies are concurrent execution units within the rendering pipeline responsible for driving key-value pair binding updates for single or groups of dynamic objects. In real-time rendering applications of 3D scenes such as digital twins and smart cities, each dynamic object proxy can be implemented by a single thread or a group of threads in the GPU compute shader. Multiple dynamic object proxies can simultaneously submit binding update requests to the GPU's lock-free hash table within the same rendering frame.

[0047] Key-value pair binding update refers to the operation request submitted by the dynamic object proxy to the GPU lock-free hash table to update the geometric vertex coordinates, texture atlas coordinates, and version timestamp fields of a certain key-value pair. Each binding update carries the key identifier of the key-value pair to be updated, the new geometric vertex coordinates, the new texture atlas coordinates, and the predecessor version identifier value recorded in the predecessor dependency pointer field.

[0048] A conflict node is a record formed by the rejected key-value pair to be updated and the submitted key-value pair bound to it for update. Its data structure includes three fields: the key identifier of the key-value pair to be updated, the predecessor key identifier, and the predecessor version identifier. A conflict buffer is a pre-defined queue (such as a FIFO) allocated in a specific contiguous area of ​​GPU memory. It uses a circular queue mechanism for capacity management and temporarily stores all conflict node records that have been rejected for write within the current frame.

[0049] During the current frame rendering cycle, multiple dynamic object proxies concurrently submit key-value pair binding updates to the GPU lock-free hash table. When submitting a binding update, each dynamic object proxy first reads the predecessor version identifier value from the predecessor dependency pointer field of the key-value pair to be updated, then locates the corresponding predecessor key-value pair in the GPU lock-free hash table, and reads the version identifier value currently stored in the predecessor key-value pair version timestamp field.

[0050] Next, the two version identifier values ​​are compared to determine whether the predecessor key-value pair has undergone a version change since being depended upon. If they match, it means that the predecessor key-value pair has not changed since being depended upon, and the binding update passes the version verification. At this point, the normal execution flow branch is directly entered, and the new geometric vertex coordinates, texture atlas coordinates, and newly generated version identifier value are successfully written to the storage slots of the corresponding key-value pairs in the GPU lock-free hash table through atomic comparison and exchange operations.

[0051] If the two are inconsistent, it means that the predecessor key-value pair has been updated by other dynamic object proxies in the current frame, and the version that the current key-value pair to be updated depends on has become invalid. The write of this binding update is rejected. The key identifier, predecessor key identifier and predecessor version identifier of the key-value pair to be updated are combined into a conflict node record and written to the tail of the conflict buffer queue through an atomic append operation to ensure that no data is overwritten when multiple dynamic object proxies write to the conflict buffer concurrently.

[0052] Specifically, in the current frame sequence number is The starting value of the updated sequence number is During the rendering cycle, multiple dynamic object proxies concurrently submit key-value pair binding updates. The scene contains architectural window component objects and their dependent wall component objects. First, key-value pairs are created for the window components in a GPU lock-free hash table, with the key identifier denoted as [key identifier]. The geometric vertex coordinates are denoted as The texture atlas coordinates are as follows The version identifier value is generated as The key identifier of the wall component is marked as The version identifier value is generated as The predecessor dependency pointer field of the window component records the predecessor key identifier. and front-wheel drive version identifier value key-value pairs Write to the GPU lock-free hash table.

[0053] Next, a dynamic object proxy needs to update the binding relationship of the window component in the current frame, and reads the predecessor key identifier from the predecessor dependency pointer field of the window component. and front-wheel drive version identifier value Locate the key-value pair of the wall component in the GPU lock-free hash table, and read the currently stored version identifier value in its version timestamp field, denoted as . .

[0054] like This indicates that the wall component has not undergone version changes since being depended upon by the window component, and the binding update passed version verification. The new geometric vertex coordinates of the window component in the current frame are collected. and new texture atlas coordinates Generate a new version identifier value The updated key-value pairs are obtained through atomic comparison swap operations. Write to the GPU lock-free hash table Complete the binding update for the corresponding storage slot.

[0055] like This indicates that the wall component has been updated by another dynamic object proxy, and the version identifier value has changed from... Become If the versions are inconsistent, the current binding update write is rejected. Finally, the conflict node is recorded. Write to the collision buffer queue via an atomic append operation. Assume the current frame's collision buffer already contains... 1 record, queue status is Each record This includes three data items: the key identifier of the conflicting key-value pair, the predecessor key identifier, and the predecessor version identifier. After appending, the queue state is updated to... .

[0056] The atomic append operation increments the tail pointer of the queue using atomic addition instructions provided by the GPU hardware, ensuring that each conflict node record occupies an independent storage location in the queue when multiple dynamic object proxies are concurrently written to the conflict buffer. After all the binding updates of dynamic object proxies within the same rendering frame have been committed, the conflict buffer stores all conflict node records that were rejected from being written to in that frame.

[0057] This embodiment accurately identifies version failures caused by concurrent contention by comparing the predecessor version identifier of the key-value pair to be updated with the current version identifier of the predecessor key-value pair in the GPU's lock-free hash table. It then atomically appends the conflicting nodes to the conflict buffer instead of discarding them directly. This preserves the complete information of the conflict situation while avoiding data overwriting during concurrent writes by multiple dynamic object proxies, effectively preventing rendering data errors caused by version failures while ensuring high-concurrency write performance.

[0058] S103. Starting from each conflict node in the conflict buffer, traverse downwards in the lock-free hash table to determine the key-value pairs that directly or indirectly depend on the conflict nodes, and obtain the set of key-value pairs to be repaired.

[0059] Optionally, step S103, starting with each conflict node in the conflict buffer, involves traversing downwards in the lock-free hash table to determine key-value pairs that directly or indirectly depend on the conflict nodes, thus obtaining a set of key-value pairs to be repaired. This process may specifically include: S1031. Using each conflict node in the conflict buffer as the first key-value pair, search in the lock-free hash table for key-value pairs where the predecessor key identifier in the predecessor dependency pointer field is the same as the key identifier in the first key-value pair, and the predecessor version identifier value in the predecessor dependency pointer field is the same as the version identifier value in the version timestamp field of the first key-value pair.

[0060] The first key-value pair refers to the baseline key-value pair currently used to search for downstream key-value pairs during the downward traversal process. Its initial value is the conflict node in the conflict buffer, and it is updated to the key-value pair found in the current round after each round of search. Downward traversal refers to the traversal process that starts from the conflict node and expands the search layer by layer in the GPU lock-free hash table along the direction pointed to by the predecessor dependency pointer field, and advances level by level from upstream to downstream of the dependency chain.

[0061] First, a conflict node record is read from the conflict buffer queue, and the key-value pair to be updated corresponding to this conflict node is taken as the first key-value pair. Next, using a concurrent reverse dependency index table maintained synchronously with the lock-free hash table in GPU memory, the GPU compute shader locates the reverse index block corresponding to the first key-value pair as the traversal data block. This block is allocated to multiple thread groups for high-concurrency local traversal, searching for key-value pairs that satisfy the following two conditions: the predecessor key identifier recorded in its predecessor dependency pointer field is the same as the key identifier of the first key-value pair, and the predecessor version identifier recorded in its predecessor dependency pointer field is the same as the version timestamp value currently stored in the first key-value pair. If both conditions are met, it indicates that the key-value pair logically depends on the specific version of the first key-value pair at the time it was depended upon, and belongs to a direct downstream key-value pair.

[0062] Specifically, in S102, the window component binding update was rejected due to inconsistencies in the wall component versions, and the conflict node was recorded. It has been written to the collision buffer queue via atomic append operations, forming a queue. First from the queue The conflict node record is read, and the key-value pair of the window component corresponding to the conflict node is used as the first key-value pair. The key identifier of the first key-value pair is... Since the key-value pair was rejected from being written to during this binding update, the version timestamp field currently stores the version identifier value from when it was created in S101. Right now .

[0063] Next, by querying the reverse dependency index table, a partial traversal of the associated key-value pairs is performed in the GPU lock-free hash table to search for the predecessor key identifier equal to... And the front-wheel drive version identifier value is equal to The key-value pairs. Assume there exists a window sill component object in the scene that depends on the window component, and its predecessor key is recorded as... The front-wheel drive version identifier value is recorded as follows: If both conditions are met, the key-value pair of the window sill component is denoted as... Confirmed as the first key-value pair The direct downstream key-value pairs.

[0064] S1032. Continue searching with the searched key-value pairs as the first updated key-value pairs until no new key-value pairs are found. Then, determine all the searched key-value pairs as the set of key-value pairs to be repaired.

[0065] The updated first key-value pair refers to the result of replacing the first key-value pair of the previous round with the key-value pair found in the current round after each round of search. The set of key-value pairs to be repaired refers to the set of all key-value pairs in the current frame whose predecessor dependency pointer fields directly or indirectly point to conflicting nodes, and may include all downstream key-value pairs whose predecessor dependency pointer field records have become invalid due to the version failure of the conflicting node.

[0066] First, the direct downstream key-value pairs found in S1031 are used as the first updated key-value pairs. The search continues in the GPU lock-free hash table to find their downstream key-value pairs, maintaining the same search criteria as S1031: the predecessor key identifier equals the key identifier of the current first key-value pair, and the predecessor version identifier equals the version identifier currently stored in the version timestamp field of the current first key-value pair. Next, the newly found key-value pairs are added to the list of discovered key-value pairs, and the search continues downwards using these newly found key-value pairs as the first key-value pairs. This process is repeated until no new key-value pairs are found in a certain round, at which point the traversal terminates. Finally, all key-value pairs found in all rounds are aggregated to obtain the set of key-value pairs to be repaired.

[0067] Specifically, the window sill component key-value pairs have been found in S1031. As the first round of direct downstream key-value pairs. First with For the first key-value pair to be updated, search the GPU lock-free hash table for the predecessor key identifier, which is equal to... And the front-wheel drive version identifier value is equal to The key-value pairs are then processed. If no key-value pair satisfying this condition exists in the GPU lock-free hash table, the search terminates as no new key-value pairs are found in this round. Finally, S1031 and all key-value pairs found in this round are aggregated into a set of key-value pairs to be repaired. ,in .

[0068] This embodiment searches the GPU's lock-free hash table layer by layer, starting with the key-value pair corresponding to the conflicting node and following the pointer relationship of the predecessor dependency pointer field, for key-value pairs that directly or indirectly depend on the conflicting node. This can completely discover all downstream key-value pairs affected by the rejection of a single key-value pair binding update, thus avoiding the problem that the mapping error of downstream key-value pairs after the dependency chain breaks goes undetected and leads to the problem of geometric vertex and texture mismatch in the rendered image.

[0069] S104. According to the order of dependency hierarchy of each key-value pair in the set of key-value pairs to be repaired from smallest to largest, update the predecessor dependency pointer field and version timestamp field of each key-value pair to obtain the updated key-value pair set.

[0070] Optionally, before updating the predecessor dependency pointer field and version timestamp field of each key-value pair in step S104 according to the ascending order of dependency hierarchy of each key-value pair in the set of key-value pairs to be repaired, and obtaining the updated key-value pair set, the method further includes: Each key-value pair in the set of key-value pairs to be repaired is taken as the second key-value pair. The predecessor key identifier and predecessor version identifier values ​​included in the predecessor dependency pointer field of the second key-value pair are read. The lock-free hash table is searched for key-value pairs whose key identifier is the same as the predecessor key identifier and whose version timestamp field includes the same version identifier value as the predecessor version identifier value.

[0071] The search continues with the found key-value pair as the updated second key-value pair until the predecessor dependency pointer field of the updated second key-value pair is empty. The number of key-value pairs that the updated second key-value pair with the empty predecessor dependency pointer field passes through to reach the key-value pair in the set of key-value pairs to be repaired is calculated, and the dependency hierarchy of each key-value pair is obtained.

[0072] The second key-value pair refers to the baseline key-value pair currently used to trace the predecessor chain upwards during the dependency hierarchy calculation process. Its initial value is a key-value pair from the set of key-value pairs to be repaired, and it is updated to the predecessor key-value pair found in each round of search. The dependency hierarchy refers to the number of key-value pairs traversed from the predecessor dependency pointer field (which is empty) to the target key-value pair in the set of key-value pairs to be repaired. It measures the relative position of the key-value pair in the dependency chain; the smaller the value, the closer the key-value pair is to the source of the dependency chain.

[0073] First, taking a key-value pair from the set of key-value pairs to be repaired as the second key-value pair, read the predecessor key identifier and predecessor version identifier values ​​recorded in its predecessor dependency pointer field. Search in the GPU lock-free hash table for key-value pairs whose key identifier is the same as the predecessor key identifier and whose version timestamp field currently stores the same version identifier value as the predecessor version identifier value. Next, using the searched key-value pair as the updated second key-value pair, continue reading its own predecessor dependency pointer field and repeating the above search process, tracing upwards level by level until the predecessor dependency pointer field of the updated second key-value pair is empty, indicating that the source of the dependency chain has been traced.

[0074] If a cycle is detected in the dependency graph during the tracing process (i.e., the currently found predecessor key identifier already exists in the current tracing path), the dependency level of the latest node causing the cycle will be assigned the maximum value of an unsigned 32-bit integer. To break the infinite loop. Finally, the statistics are based on the predecessor dependency pointer field identifier value being a preset null constant, such as... The number of forward dependency hops traced between the source key-value pair and the original key-value pair in the set of key-value pairs to be repaired is used as the dependency level of the key-value pair.

[0075] Specifically, continuing the embodiment in S103. The set of key-value pairs to be repaired. ,in Firstly, with The second key-value pair is denoted as Read the predecessor key identifier recorded in its predecessor dependency pointer field. and front-wheel drive version identifier value Searching for the key identifier in the GPU lock-free hash table. And the version timestamp field currently stores a version identifier value equal to The key-value pairs were searched, and the key-value pairs of the window component itself were found, denoted as .

[0076] Next, with For the updated second key-value pair, read the predecessor key identifier recorded in its predecessor dependency pointer field. and front-wheel drive version identifier value Searching for the key identifier in the GPU lock-free hash table. And the version timestamp field currently stores a version identifier value equal to The key-value pairs were searched, and the key-value pairs of wall components were found, denoted as... Since the wall components do not depend on any other objects when the scene is initially created, The identifier value of the predecessor dependency pointer field is a preset null constant. The tracing process ends. Finally, statistics are compiled from... arrive The number of forward dependency hops traced between them, the path is The number of hops to trace is ,get The dependency hierarchy is denoted as .

[0077] Optionally, step S104, which updates the predecessor dependency pointer field and version timestamp field of each key-value pair in the set of key-value pairs to be repaired in ascending order of dependency hierarchy, may specifically include: Figure 3 A schematic diagram of a process for updating a set of key-value pairs according to an embodiment of this application is shown. Figure 3 As shown, the method includes: S1041. Determine whether there are multiple key-value pairs with the same key identifier in the set of key-value pairs to be repaired.

[0078] S1042. When there are multiple key-value pairs with the same key identifier in the set of key-value pairs to be repaired, retain the key-value pair with the latest version identifier value of the version timestamp field in the current frame to obtain the adjusted set of key-value pairs to be repaired.

[0079] S1043. Otherwise, the original set of key-value pairs to be repaired will be used directly as the adjusted set of key-value pairs to be repaired.

[0080] The adjusted set of key-value pairs to be repaired refers to the set obtained after deduplication of key-value pairs with the same key identifier in the set of key-value pairs to be repaired.

[0081] First, iterate through the set of key-value pairs to be repaired. All key-value pairs in the dataset are grouped according to their key identifiers. Next, for each group, it is determined whether multiple key-value pairs exist. If multiple key-value pairs exist, it indicates that the same dynamic object has been repeatedly collected due to multiple dependency paths. The version timestamp field of each key-value pair within that group is compared, and the key-value pair with the largest value (i.e., the most recently generated key-value pair in the current frame) is retained. The remaining key-value pairs are removed from the set of key-value pairs to be repaired. Finally, all key-value pairs after deduplication are summarized to obtain the adjusted set of key-value pairs to be repaired. .

[0082] S1044. Determine whether there are multiple key-value pairs with the same dependency level in the adjusted set of key-value pairs to be repaired.

[0083] S1045. When multiple key-value pairs with the same dependency level exist, update the predecessor dependency pointer field and version timestamp field of each key-value pair in the adjusted set of key-value pairs to be repaired in parallel.

[0084] Multiple key-value pairs with the same dependency level refer to key-value pairs with equal dependency level values ​​in the adjusted set of key-value pairs to be repaired. These key-value pairs are at the same level in the dependency chain and have no direct predecessor dependency relationship with each other. Theoretically, they can be updated simultaneously without interfering with each other.

[0085] First, all key-value pairs in the adjusted set of key-value pairs to be repaired are grouped according to the calculated dependency hierarchy, and the number of key-value pairs in each dependency hierarchy group is counted. Next, for cases where the dependency hierarchy values ​​are the same and the number of key-value pairs in a group is greater than one, update threads are started simultaneously for all key-value pairs in that group. These threads read the current key identifier and version identifier values ​​of the corresponding predecessor key-value pair for each key-value pair in parallel and write them to their respective predecessor dependency pointer field and version timestamp field. Since key-value pairs within the same group do not have dependencies on each other, parallel processing will not cause data races.

[0086] S1046. Otherwise, update the predecessor dependency pointer field and version timestamp field of each key-value pair in the adjusted set of key-value pairs to be repaired in ascending order of dependency hierarchy.

[0087] S1047. Obtain the updated key-value pair set.

[0088] First, the adjusted set of key-value pairs to be repaired is strictly divided and arranged into multiple hierarchical groups according to the dependency hierarchy value from smallest to largest. The algorithm processes the data layer by layer globally according to the dependency hierarchy from smallest to largest. When processing each level group: if there are multiple key-value pairs in the group, a parallel update branch is executed to update each key-value pair in the same layer in parallel; otherwise, if there is only one key-value pair in the group, the key-value pair is updated sequentially in a single thread.

[0089] After processing all operations within the current group, the system moves on to the next group with a higher dependency level value to continue updating, until all groups have been processed. Finally, all key-value pairs that have completed dependency level repair are merged with all normal key-value pairs that have not conflicted in the current frame and all static key-value pairs that have not changed, to obtain the updated key-value pair set.

[0090] Optionally, the process of updating the predecessor dependency pointer field and version timestamp field of each key-value pair in the adjusted key-value pair set to be repaired may specifically include: Read the version identifier value of the current key identifier and version timestamp fields of the corresponding predecessor key-value pair for each key-value pair in the adjusted set of key-value pairs to be repaired from the lock-free hash table. Write the key identifier and version identifier values ​​to the predecessor dependency pointer field of the key-value pair. Write the new version identifier value generated in the current frame to the version timestamp field of the key-value pair.

[0091] First, for each key-value pair in the adjusted set of key-value pairs to be repaired, the predecessor key identifier recorded in its predecessor dependency pointer field is read. The corresponding predecessor key-value pair is located in the GPU lock-free hash table, and the key identifier and version timestamp field of the predecessor key-value pair are read. Next, the read key identifier and version identifier values ​​are written to the predecessor dependency pointer field of the current key-value pair, so that the predecessor dependency pointer field reflects the latest state of the predecessor key-value pair in this frame. Finally, a new version identifier value for the current frame is generated and written to the version timestamp field of the current key-value pair, marking that the key-value pair has completed causal consistency repair in this frame.

[0092] Specifically, for key-value pairs First, read the predecessor key identifier recorded in its predecessor dependency pointer field. Locate the window component key-value pair in the GPU lock-free hash table and read its key identifier. The version identifier value currently stored in the version timestamp field remains unchanged because the window component's binding update was rejected for write in S102. .

[0093] Next, and Write The predecessor dependency pointer field, the predecessor dependency pointer field is maintained as Finally, a new version identifier value for the current frame is generated. Write The version timestamp field is used to obtain the updated key-value pairs. The entire set of repaired key-value pairs is then merged with all conflict-free normal key-value pairs to obtain the updated key-value pair set. .

[0094] This embodiment calculates the dependency hierarchy of each key-value pair in the set of key-value pairs to be repaired before updating, and updates the predecessor dependency pointer field and version timestamp field of each key-value pair in ascending order of dependency hierarchy and in parallel processing within the same hierarchy. This ensures that upstream key-value pairs in the dependency chain are refreshed before downstream key-value pairs, avoiding downstream key-value pairs from being repaired based on upstream version information that has not yet been updated. At the same time, it improves repair efficiency by using parallel processing within the same layer, achieving complete and consistent repair of cross-frame causal dependency chains while ensuring high-concurrency write performance in ultra-large-scale scenarios.

[0095] S105. Generate a version snapshot of the current frame based on the updated key-value pair set, and merge the geometric vertex coordinates and texture atlas coordinates of each key-value pair in the version snapshot into the same vertex buffer object for batch rendering.

[0096] Optionally, the version snapshot in step S105 is a read-only copy that is independent of the lock-free hash table within the current frame.

[0097] Step S105, which generates a version snapshot of the current frame based on the updated key-value pair set, may specifically include: S1051. During the current frame rendering submission phase, read the version identifier values ​​of the key identifier, geometric vertex coordinates, texture atlas coordinates, and version timestamp fields of all key-value pairs from the updated key-value pair set.

[0098] The current frame rendering submission stage refers to the processing stage in the current frame rendering pipeline used to generate batch rendering data after the dependency hierarchy of the set of key-value pairs to be repaired is completed and the updated set of key-value pairs is obtained. During this stage, no new key-value pair binding update requests are accepted to ensure that the state of the read updated set of key-value pairs is stable.

[0099] First, after updating the predecessor dependency pointer field and version timestamp field of all key-value pairs in S104, the current frame rendering submission stage begins. Next, all key-value pairs in the updated key-value pair set are traversed, and the key identifier, geometric vertex coordinates, texture atlas coordinates, and the currently stored version identifier value in the version timestamp field of each key-value pair are read one by one. These four data items are then summarized into corresponding data lists, which serve as input for generating a complete batch of frame version snapshots.

[0100] Specifically, update the key-value pair set. ,in After entering the current frame rendering and submission stage, read... Key identifier Geometric vertex coordinates Texture atlas coordinates and the version identifier value currently stored in the version timestamp field. Suppose the updated key-value pair set also includes another key-value pair that has already been repaired. Read its key identifier together Geometric vertex coordinates Texture atlas coordinates and version identifier value All the read data will be aggregated into a dataset to be copied. .

[0101] S1052. Copy the key identifier, geometric vertex coordinates, texture atlas coordinates, and version identifier value to the storage area of ​​the GPU video memory to obtain a version snapshot, and release the version snapshot after the current frame rendering ends.

[0102] The GPU memory storage area refers to a contiguous storage space within the GPU memory used to hold version snapshot data. This storage area is only available for reading by the rendering thread during the current frame rendering submission phase and does not accept write operations. A version snapshot is a consistent copy of data generated before the current frame rendering, independent of the lock-free hash table. Its lifecycle is dynamically generated each frame and automatically released or overwritten after the current frame rendering ends to ensure that the rendering thread does not obtain incomplete or inconsistent data due to concurrent writes during the reading process.

[0103] First, a storage region matching the size of the data set to be copied is allocated in the GPU memory. Next, the key identifier, geometric vertex coordinates, texture atlas coordinates, and version identifier value of each key-value pair read from S1051 are sequentially copied to the corresponding location in this storage region. Once the copying is complete, a version snapshot is obtained. This version snapshot exists independently of the GPU's lock-free hash table, and subsequent write operations to the GPU's lock-free hash table will not affect the copied data content in the version snapshot.

[0104] Finally, the rendering module reads the version snapshot and writes the geometric vertex coordinates and texture atlas coordinates of each key-value pair into the same vertex buffer object in a contiguous and compact manner. This allows for the rendering of all objects within the set to be completed in a single draw call, achieving a significantly reduced CPU overhead through batch rendering. This storage area is released after the current frame rendering is finished and the batch rendering command is output, making it reusable for the next frame when a new version snapshot is generated.

[0105] Specifically, the data set to be copied The two records in the database are copied sequentially to a storage area allocated in the GPU memory to obtain a version snapshot, denoted as . The rendering thread starts from the version snapshot within the current frame. The system reads the geometric vertex coordinates and texture atlas coordinates of the window sill component and its downstream components, and uses this information to merge and write to the vertex buffer object without directly accessing the GPU's lock-free hash table. This avoids data contention between the rendering read process and concurrent writes to the GPU's lock-free hash table by other dynamic object proxies. After the current frame rendering is complete and the batch rendering command is output, the version snapshot is released. The storage area occupied.

[0106] This embodiment generates a version snapshot by uniformly copying the key identifier, geometric vertex coordinates, texture atlas coordinates, and version identifier values ​​from the updated key-value pair set to a storage area in GPU memory independent of the lock-free hash table during the rendering submission phase. This prevents the rendering thread from directly accessing the lock-free hash table that continuously accepts concurrent writes when reading rendering data, avoiding data competition between the rendering reading process and subsequent frame dynamic object proxy write operations, and ensuring that the geometric vertex coordinates and texture atlas coordinates used in batch rendering always come from causally consistent key-value pair version combinations.

[0107] Figure 4 This is a schematic diagram illustrating a specific implementation of a batch rendering optimization system for ultra-large-scale models based on key-value pair mapping, as provided in this application. (Refer to...) Figure 4 The system may include: Module 410 is established to create key-value pairs of dynamic objects in the GPU lock-free hash table. The key-value pairs are used to bind geometric vertex coordinates and texture atlas coordinates and include a key identifier, a version timestamp field for storing version identifier values, and a predecessor dependency pointer field. The predecessor dependency pointer field is used to record the key identifier of the predecessor key-value pair and the version identifier value of the version timestamp field. The write module 420 is used for concurrent submission of key-value pair binding updates by multiple dynamic object proxies. If the version identifier value of the predecessor key-value pair recorded in the predecessor dependency pointer field of the key-value pair to be updated is inconsistent with the current version identifier value of the version timestamp field of the corresponding predecessor key-value pair in the lock-free hash table, the key-value pair binding update is rejected and the key-value pair to be updated is written as a conflict node into the conflict buffer. The generation module 430 is used to determine the key-value pairs that directly or indirectly depend on the conflicting nodes by traversing downwards in the lock-free hash table, starting from each conflicting node in the conflict buffer, and to obtain a set of key-value pairs to be repaired. The generation module 430 is also used to update the predecessor dependency pointer field and version timestamp field of each key-value pair in the set of key-value pairs to be repaired in ascending order of dependency hierarchy, so as to obtain the updated key-value pair set. Rendering module 440 is used to generate a version snapshot of the current frame based on the updated key-value pair set, and to merge the geometric vertex coordinates and texture atlas coordinates of each key-value pair in the version snapshot into the same vertex buffer object for batch rendering.

[0108] The batch rendering optimization system for ultra-large-scale models based on key-value pair mapping in this application is used to implement the aforementioned batch rendering optimization method for ultra-large-scale models based on key-value pair mapping. Therefore, the specific implementation of the batch rendering optimization system for ultra-large-scale models based on key-value pair mapping can be found in the embodiment section of the batch rendering optimization method for ultra-large-scale models based on key-value pair mapping mentioned above. The specific implementation can be referred to the description of the corresponding embodiments, which will not be repeated here.

[0109] Electronic devices may include processors and memory storing computer program instructions.

[0110] Specifically, the processor may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0111] The memory may include a large-capacity storage device for data or instructions. For example, and not limitingly, the memory may include a hard disk drive (HDD), a floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory may include removable or non-removable (or fixed) media. Where appropriate, the memory may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, the memory is non-volatile solid-state memory.

[0112] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of this disclosure.

[0113] The processor reads and executes computer program instructions stored in memory to implement any of the key-value pair mapping-based batch rendering optimization methods for ultra-large-scale models in the above embodiments.

[0114] In one example, the electronic device may also include a communication interface and a bus. The processor, memory, and communication interface are connected via the bus and communicate with each other.

[0115] The communication interface is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0116] A bus, including hardware, software, or both, couples components of an online data traffic metering device together. For example, and not limitingly, a bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, a bus may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0117] The electronic device can execute the batch rendering optimization method for ultra-large-scale models based on key-value pair mapping in the embodiments of this application, thereby realizing the batch rendering optimization method for ultra-large-scale models based on key-value pair mapping described in conjunction with the accompanying drawings.

[0118] Furthermore, in conjunction with the key-value pair mapping-based batch rendering optimization method for ultra-large-scale models in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the key-value pair mapping-based batch rendering optimization methods for ultra-large-scale models in the above embodiments.

[0119] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0120] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0121] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0122] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0123] The above provides a detailed description of the batch rendering optimization method and system for ultra-large-scale models based on key-value pair mapping provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for optimizing batch rendering of ultra-large-scale models based on key-value pair mapping, characterized in that, include: In a GPU lock-free hash table, key-value pairs of dynamic objects are established. These key-value pairs are used to bind geometric vertex coordinates and texture atlas coordinates and include a key identifier, a version timestamp field for storing version identifier values, and a predecessor dependency pointer field. The predecessor dependency pointer field is used to record the key identifier of the predecessor key-value pair and the version identifier value of the version timestamp field. Multiple dynamic object proxies concurrently submit key-value pair binding updates. If the version identifier value of the predecessor key-value pair recorded in the predecessor dependency pointer field of the key-value pair to be updated is inconsistent with the current version identifier value of the version timestamp field of the corresponding predecessor key-value pair in the lock-free hash table, the key-value pair binding update is rejected, and the key-value pair to be updated is written as a conflict node into the conflict buffer. Starting with each conflict node in the conflict buffer, the key-value pairs that are directly or indirectly dependent on the conflict node are determined by traversing downwards in the lock-free hash table to obtain a set of key-value pairs to be repaired. According to the order of the dependency hierarchy of each key-value pair in the set of key-value pairs to be repaired from smallest to largest, update the predecessor dependency pointer field and version timestamp field of each key-value pair to obtain the updated key-value pair set; Generate a version snapshot of the current frame based on the updated key-value pair set, and merge the geometric vertex coordinates and texture atlas coordinates of each key-value pair in the version snapshot into the same vertex buffer object for batch rendering.

2. The method according to claim 1, characterized in that, The version identifier value is a monotonically increasing identifier value formed by the frame number of the current frame and the update sequence number of the key value pair, where the current frame is one rendering submission cycle; The predecessor dependency pointer field includes a predecessor key identifier and a predecessor version identifier value. The predecessor key identifier is used to locate the predecessor key-value pair, and the predecessor version identifier value is used to record the version identifier value of the version timestamp field when the predecessor key-value pair is depended upon.

3. The method according to claim 1, characterized in that, The conflict node is a record formed by binding the key-value pair to be updated, which was rejected from being written, with the key-value pair to be updated submitted for updating; The conflict buffer is a queue of preset length in the GPU memory. Writing to the conflict buffer includes writing the key identifier of the conflict node, the predecessor key identifier and the predecessor version identifier value included in the predecessor dependency pointer field of the conflict node into the conflict buffer in an atomic append manner.

4. The method according to claim 1, characterized in that, Starting with each conflict node in the conflict buffer, the key-value pairs that directly or indirectly depend on the conflict node are determined by traversing downwards in the lock-free hash table, resulting in a set of key-value pairs to be repaired, including: Using each conflict node in the conflict buffer as the first key-value pair, search the lock-free hash table for key-value pairs where the predecessor key identifier in the predecessor dependency pointer field is the same as the key identifier in the first key-value pair, and the predecessor version identifier value in the predecessor dependency pointer field is the same as the version identifier value in the version timestamp field of the first key-value pair. The search continues with the first key-value pair as the updated key-value pair, until no new key-value pairs are found. All the key-value pairs found are then identified as the set of key-value pairs to be repaired.

5. The method according to claim 1, characterized in that, Before updating the predecessor dependency pointer field and version timestamp field of each key-value pair in the set of key-value pairs to be repaired in ascending order of dependency hierarchy, the method further includes: Each key-value pair in the set of key-value pairs to be repaired is taken as the second key-value pair. The predecessor key identifier and predecessor version identifier values ​​included in the predecessor dependency pointer field of the second key-value pair are read. The lock-free hash table is searched for key-value pairs whose key identifier is the same as the predecessor key identifier and whose version identifier value included in the version timestamp field is the same as the predecessor version identifier value. The search continues with the found key-value pair as the updated second key-value pair until the predecessor dependency pointer field of the updated second key-value pair is empty. The number of key-value pairs that the updated second key-value pair with the empty predecessor dependency pointer field passes through to reach the key-value pair in the set of key-value pairs to be repaired is calculated to obtain the dependency hierarchy of each key-value pair.

6. The method according to claim 1, characterized in that, The step involves updating the predecessor dependency pointer field and version timestamp field of each key-value pair in the set of key-value pairs to be repaired, in ascending order of dependency hierarchy, to obtain the updated key-value pair set, including: When multiple key-value pairs with the same key identifier exist in the set of key-value pairs to be repaired, retain the key-value pair with the latest version identifier value in the version timestamp field of the current frame to obtain the adjusted set of key-value pairs to be repaired. When multiple key-value pairs with the same dependency level exist, the predecessor dependency pointer field and version timestamp field of each key-value pair in the adjusted set of key-value pairs to be repaired are updated in parallel. Otherwise, update the predecessor dependency pointer field and version timestamp field of each key-value pair in the adjusted key-value pair set to be repaired in ascending order of dependency hierarchy to obtain the updated key-value pair set.

7. The method according to claim 6, characterized in that, The updated and adjusted predecessor dependency pointer field and version timestamp field of each key-value pair in the set of key-value pairs to be repaired include: Read the version identifier value of the current key identifier and version timestamp field of each key-value pair in the adjusted key-value pair set to be repaired from the lock-free hash table; Write the key identifier and the version identifier value into the predecessor dependency pointer field of the key-value pair; Write the new version identifier value generated in the current frame into the version timestamp field of the key-value pair.

8. The method according to claim 1, characterized in that, The version snapshot is a read-only copy of the lock-free hash table that is independent of the current frame. The step of generating a version snapshot of the current frame based on the updated key-value pair set includes: During the current frame rendering submission phase, the version identifier values ​​of the key identifier, geometric vertex coordinates, texture atlas coordinates, and version timestamp fields of all key-value pairs are read from the updated key-value pair set. The key identifier, the geometric vertex coordinates, the texture atlas coordinates, and the version identifier value are copied to the storage area of ​​the GPU video memory to obtain the version snapshot, and the version snapshot is released after the current frame rendering is completed.

9. A batch rendering optimization system for ultra-large-scale models based on key-value pair mapping, characterized in that, include: A module is established to create key-value pairs of dynamic objects in a GPU lock-free hash table. The key-value pairs are used to bind geometric vertex coordinates and texture atlas coordinates and include a key identifier, a version timestamp field for storing version identifier values, and a predecessor dependency pointer field. The predecessor dependency pointer field is used to record the key identifier of the predecessor key-value pair and the version identifier value of the version timestamp field. The write module is used for multiple dynamic object proxies to concurrently submit key-value pair binding updates. If the version identifier value of the predecessor key-value pair recorded in the predecessor dependency pointer field of the key-value pair to be updated is inconsistent with the current version identifier value of the version timestamp field of the corresponding predecessor key-value pair in the lock-free hash table, the key-value pair binding update is rejected, and the key-value pair to be updated is written as a conflict node into the conflict buffer. The generation module is used to determine key-value pairs that directly or indirectly depend on the conflicting nodes by traversing downwards in the lock-free hash table, starting from each conflicting node in the conflict buffer, to obtain a set of key-value pairs to be repaired. The generation module is also used to update the predecessor dependency pointer field and version timestamp field of each key-value pair in the set of key-value pairs to be repaired in ascending order of dependency hierarchy, so as to obtain the updated key-value pair set. The rendering module is used to generate a version snapshot of the current frame based on the updated key-value pair set, and to merge the geometric vertex coordinates and texture atlas coordinates of each key-value pair in the version snapshot into the same vertex buffer object for batch rendering.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the batch rendering optimization method for ultra-large-scale models based on key-value pair mapping as described in any one of claims 1 to 8 when executing the computer program.

Images