Data processing method, system, apparatus, device, and program product

Abstract

Embodiments of the present disclosure disclose a data processing method, system, device, equipment and storage medium, wherein the data processing method comprises: in a geometry stage of a graphics rendering performed by a graphics processing unit, in response to a read application initiated by a geometry data processing module, allocating an interface for accessing a local storage system of the graphics processing unit to the read application; obtaining geometry data corresponding to the read application from the local storage system through an interface corresponding to the read application; caching the geometry data to a shared memory space of a geometry cache controller; and returning the geometry data in the shared memory space to the geometry data processing module.

Description

Technical Field

[0001] This disclosure relates to, but is not limited to, the field of graphics rendering technology, and in particular to a data processing method, system, apparatus, device, and program product. Background Technology

[0002] In graphics processing systems, the graphics rendering process is typically handled by the Graphics Processing Unit (GPU), whose core tasks include geometry processing, rasterization, and pixel shading. The geometry stage is responsible for transforming and processing vertex data and passing the results to subsequent pipeline modules. As graphics applications increasingly demand real-time performance and data bandwidth, efficiently caching and managing the data generated during the geometry stage has become a key factor in improving GPU performance.

[0003] In existing technologies, registers are typically used to temporarily store vertex data processed by the shader during the geometry stage of graphics rendering. However, in high-concurrency or large-data-volume scenarios, register resources are limited, difficult to expand effectively, and cannot flexibly adapt to the needs of different access modes, resulting in low chip area utilization and low data access efficiency. Summary of the Invention

[0004] In view of the above, the present disclosure provides at least one data processing method, system, apparatus, device, and program product.

[0005] The technical solution of this disclosure embodiment is implemented as follows:

[0006] On one hand, this disclosure provides a data processing method applied to a geometry cache controller. The data processing method includes: during the geometry stage of graphics rendering by a graphics processing unit, responding to a read request initiated by a geometry data processing module, allocating an interface for the read request to access the local storage system of the graphics processing unit; obtaining the geometry data corresponding to the read request from the local storage system through the interface corresponding to the read request; caching the geometry data in the shared memory space of the geometry data processing module; and returning the geometry data in the shared memory space to the geometry data processing module when the geometry data is valid.

[0007] On the other hand, embodiments of this disclosure provide a data processing system, which includes: a geometry cache controller and a local storage system, wherein the geometry cache controller includes a shared memory space;

[0008] A local storage system is used to store geometric data from multiple geometric data processing modules;

[0009] The geometry cache controller is used to respond to read requests initiated by the geometry data processing module, allocate an interface for the read request to access the local storage system of the graphics processing unit; obtain the geometry data corresponding to the read request from the local storage system through the interface corresponding to the read request; cache the geometry data in the shared memory space of the geometry cache controller; and return the geometry data in the shared memory space to the geometry data processing module.

[0010] In another aspect, embodiments of this disclosure provide a data processing apparatus, which includes:

[0011] The allocation unit is configured to respond to read requests initiated by the geometry data processing module during the geometry phase of graphics rendering in the graphics processing unit, and allocate an interface for the read request to access the local storage system of the graphics processing unit.

[0012] The acquisition unit is configured to acquire the geometric data corresponding to the read request from the local storage system through the interface corresponding to the read request;

[0013] The storage unit is configured to cache geometric data in the shared memory space of the geometric data processing module;

[0014] The transmission unit is configured to return geometric data from the shared memory space to the geometric data processing module.

[0015] In another aspect, embodiments of this disclosure provide a computer device including a memory and a geometry cache controller, wherein the memory stores a computer program executable on a processor, and the geometry cache controller executes the program to implement some or all of the steps in the above-described method.

[0016] In another aspect, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described method.

[0017] In another aspect, embodiments of this disclosure provide a computer program including computer-readable code, which, when executed in a computer device, causes a processor in the computer device to perform some or all of the steps in the above-described method.

[0018] In another aspect, embodiments of this disclosure provide a computer program product, the computer program product including a non-transitory computer-readable storage medium storing a computer program, wherein when the computer program is read and executed by a computer, it implements some or all of the steps in the above method.

[0019] In this embodiment, a shared memory space is introduced to optimize the caching strategy for geometric data during the GPU geometry phase. This method not only reduces register resource consumption but also enhances the system's scalability, enabling it to better adapt to future demands for high-bandwidth access to vertex data.

[0020] In addition, by performing intelligent arbitration and resource management on the interface, the data transmission efficiency and stability under concurrent access of multiple modules are improved, and the graphics rendering performance is significantly optimized.

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

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the specification, serve to illustrate the technical solutions of this disclosure.

[0023] Figure 1 A schematic diagram illustrating the implementation flow of a data processing method provided in an embodiment of this disclosure;

[0024] Figure 2 This is a schematic diagram illustrating the composition of each module in a data processing method provided in an embodiment of the present disclosure.

[0025] Figure 3 This is a schematic diagram of the composition structure of a data processing device provided in an embodiment of the present disclosure;

[0026] Figure 4 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this disclosure. Detailed Implementation

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

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

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

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this disclosure.

[0031] Before providing a further detailed description of the embodiments of this disclosure, the core terms and concepts involved in the embodiments of this disclosure will be explained, and the core terms and concepts involved in the embodiments of this disclosure are subject to the following interpretations.

[0032] 1) Geometry Stage: In the GPU graphics rendering pipeline, the geometry stage typically follows the shader and is responsible for handling operations such as vertex data transformation, clipping, and culling. This stage is a crucial step in the graphics pipeline for processing 3D geometric data.

[0033] 2) Vertex Data: This refers to the basic geometric information that constitutes a 3D graphics model, including but not limited to: coordinates (x, y, z), normal vectors, texture coordinates, color attributes, etc. This data is usually output by the shader and used by subsequent geometry processing modules.

[0034] 3) Local Memory System (LMS): This refers to the internal storage structure of the GPU used to cache vertex data. It is usually a cache or RAM, used to improve the efficiency of vertex data access and reduce the dependence on external memory.

[0035] 4) Shared Memory Space: This refers to a memory area managed uniformly by the geometry cache controller. It is used to centrally cache vertex data from multiple geometry data processing modules, replacing the traditional method of configuring register groups independently for each module.

[0036] 5) Read Request: This refers to a request initiated by the geometry data processing module to the geometry cache controller to obtain the required vertex data. Each read request may contain information such as module identifier, request path, and execution timing.

[0037] 6) Geometric Data Processing Module: This refers to the various sub-modules involved in the geometric processing stage, such as the Primitive Processing Pipeline (PPP) and the Vertex Cache Controller (VCC). Each module is responsible for different geometric processing tasks and needs to access vertex data. PPP assembles vertex data into basic primitives (such as points, lines, and triangles) and performs early culling (such as backface culling). VCC is used for caching and controlling vertex data.

[0038] 7) Interface allocation: This refers to the process of dynamically allocating corresponding local storage system access interfaces to different read requests based on factors such as the source, order, and identifier of the read requests. This process ensures data order preservation and rational resource utilization during concurrent access by multiple modules.

[0039] In existing technologies, during the geometry phase of graphics rendering in a GPU, each geometry data processing module uses a register set to cache vertex data obtained from the shader, resulting in wasted chip area and difficulty in adapting to future high-bandwidth access demands. To address this issue, embodiments of this disclosure provide a data processing method that introduces shared memory space into the geometry cache controller to replace the registers of each geometry data processing module. This solves the problem of limited register resources in high-concurrency or large-data-volume scenarios, which cannot flexibly adapt to different access modes, leading to low chip area utilization and inefficient data access. This method can be executed by the geometry cache controller of a computer device. Figure 1 As shown, the method includes the following steps 101 to 104:

[0040] Step 101: In the geometric stage of graphics rendering performed by the graphics processing unit, in response to a read request initiated by the geometry data processing module, an interface for accessing the local storage system of the graphics processing unit is allocated to the read request.

[0041] Read requests are used to retrieve corresponding geometric data. A read request may contain information such as module identifier, request path, and execution timing. The request path refers to the number of paths the geometric data processing module can issue read requests simultaneously; the request path number is equal to the number of read requests. For example, if the request path number is 3, the geometric data processing module can issue 3 read requests simultaneously through these 3 request paths. Geometric data is used to represent the model's shape, position, and topological structure. Geometric data includes, but is not limited to: vertex data (the coordinates of points in the model, such as position, normals, texture coordinates, etc.), primitive connectivity information (how vertices connect to form basic primitives), and topological structure (the relationships between primitives, such as adjacency, hierarchy, etc.). The local storage system refers to the high-speed storage structure inside the GPU used to cache vertex data; it can be RAM or other forms of high-speed cache. The purpose of the local storage system is to reduce dependence on external memory and improve vertex data access efficiency.

[0042] In the graphics rendering process, the geometry phase follows the shader and is responsible for handling operations such as vertex data transformation, clipping, and culling. This phase involves multiple geometry data processing modules, such as PPP and VCC. When processing vertex data, these modules initiate read requests to the geometry cache controller to obtain the required data. To avoid wasting chip area due to each module independently configuring its register set, this embodiment of the disclosure uses a unified resource management mechanism to dynamically allocate a corresponding LMS (Local Storage System) access interface for each read request. This interface allocation strategy ensures data order preservation and rational resource utilization during concurrent access by multiple modules.

[0043] In some implementations, the local storage system includes multiple interfaces. Interface allocation can be intelligently arbitrated based on factors such as the source, order, and identifier of read requests to ensure the stability and efficiency of data transmission.

[0044] Step 102: Obtain the geometric data corresponding to the read request from the local storage system through the interface corresponding to the read request.

[0045] Once a read request is assigned to the corresponding LMS interface, the geometry cache controller will send the read request to the local storage system through this interface to obtain the required geometry data. This geometry data is the foundation for subsequent geometry processing modules to perform viewport transformations, clipping, and other operations. To improve access efficiency, the geometry cache controller centrally manages this data and quickly locates and returns the corresponding geometry data based on the read request's requirements.

[0046] In some implementations, the data in the local storage system may be shader output and cached, or it may be intermediate results retained from previous geometry stage processing. Since the data types and formats accessed by different geometry data processing modules may differ, it is necessary to ensure the integrity and accuracy of the data when acquiring it.

[0047] In some implementations, the geometry cache controller can preload some of the vertex data that may be needed through a prefetch strategy, thereby reducing latency and improving overall performance. The prefetch strategy refers to the timing at which the geometry cache controller initiates a read request; this timing should be set before the geometry data is used.

[0048] Step 103: Cache the vertex data in the shared memory space of the geometry cache controller.

[0049] After receiving vertex data from the local storage system, the geometry cache controller stores this data in its shared memory space. This shared memory space is managed centrally by the geometry cache controller, and all geometry data processing modules can access the data within it by specifying an address or identifier. The shared memory space is one of the core technologies of this disclosure, replacing the register sets used internally by each geometry data processing module in traditional solutions.

[0050] Compared to traditional register set caching, shared memory offers higher integration and a smaller chip footprint. Furthermore, shared memory can be flexibly resized to accommodate future demands for high-bandwidth vertex data access. For example, when multiple modules such as PPP and VCC access vertex data simultaneously, shared memory provides a unified caching strategy, avoiding redundant storage and resource waste.

[0051] In some implementations, the capacity of the shared memory space can be determined based on the register capacity of each geometric data processing module, but its total capacity can be less than the sum of the register capacities of multiple modules. This is because the medium characteristics of the shared memory space result in higher storage density and shorter data paths, reducing unnecessary cache latency, and thus reducing the required cache capacity accordingly.

[0052] In some implementations, the shared memory space can be divided into dedicated memory spaces for multiple geometry data processing modules. In this case, the geometry cache controller stores the geometry data of each geometry data processing module in its corresponding dedicated memory space within the shared memory space. Alternatively, the geometry data of each geometry data processing module can be directly stored in the shared memory space according to the request order. The former improves the determinism of data access and avoids deadlock issues; the latter is more flexible but requires additional resource management mechanisms to ensure data consistency. Regardless of the approach used, the shared memory space significantly reduces chip area footprint and improves system scalability.

[0053] Step 104: Return the geometric data in the shared memory space to the geometric data processing module.

[0054] In some implementations, if the vertex data is determined to be valid, the geometric data in the shared memory space is returned to the geometric data processing module.

[0055] After confirming the validity of the acquired geometric data, the data is returned to the corresponding geometric data processing module. This ensures that the geometric data received by the processing module is valid, thus guaranteeing the continuity and stability of subsequent processing.

[0056] In some implementations, the validity of geometric data can be determined based on whether the data has been correctly written to the shared memory space, whether there are data conflicts, and whether the data is erroneous. If the data has been correctly written to the shared memory space, there are no data conflicts, and the data is erroneous, then the geometric data is determined to be valid; if at least one of the following exists: the data has not been correctly written to the shared memory space, there are data conflicts, and the data is erroneous, then the geometric data is determined to be invalid.

[0057] In some implementations, the data before writing can be compared with the data in the shared memory space; if the data before writing is the same as the data in the shared memory space, it is determined that the data was correctly written to the shared memory space; if the data before writing is different from the data in the shared memory space, it is determined that the data was not correctly written to the shared memory space.

[0058] In some implementations, the existence of geometric data conflicts can be determined based on the index of the geometric data; if the index of the geometric data is not unique, then a geometric data conflict is determined; if the index of the geometric data is unique, then a geometric data conflict is determined. Alternatively, if the geometric data written to the shared memory space is different from the geometric data in the local storage system (e.g., the geometric data in the local storage system has been modified during the write process), then a geometric data conflict is determined; if the geometric data written to the shared memory space is the same as the geometric data in the local storage system, then a geometric data conflict is determined.

[0059] In some implementations, if the geometric data does not conform to the data specifications (e.g., garbled text, misalignment, presence of abnormal characters, etc.), the geometric data is determined to be erroneous; if the geometric data conforms to the data specifications, the geometric data is determined to be error-free.

[0060] In some implementations, geometric data can be returned to the corresponding geometric data processing module in the order of application; or, it can be read directly from the shared memory space when the geometric data processing module needs geometric data.

[0061] In some implementations, the geometric data processing module, the read request, and the acquired geometric data are continuously linked throughout the processing. This allows the other two pieces of information to be obtained at any time based on one piece of information.

[0062] The geometric data processing module includes PPP, VCC, and others, each responsible for different geometric processing tasks. For example, PPP is used to read the coordinates of vertices (x, y, z, w), while VCC is used to cache and control the vertex data. Through unified management of shared memory space, these modules can efficiently obtain the required data without each maintaining independent cache resources.

[0063] In some implementations, steps 101 to 104 in the entire data processing flow are closely coordinated: First, the geometry cache controller receives read requests from the geometry data processing module and allocates a suitable local storage system access interface for each request through an interface arbitration mechanism (step 101). Next, the corresponding vertex data is extracted from the local storage system using this interface (step 102), and the data is temporarily stored in shared memory space (step 103). Finally, after verifying that the data is correct, it is returned to the original request module (step 104). This series of steps collectively achieves efficient caching and management of vertex data, thereby improving the overall performance of graphics rendering.

[0064] In this embodiment, by introducing a shared memory space, the caching strategy for vertex data in the GPU geometry stage is optimized, meeting the needs of different access modes and improving data transmission efficiency. Since the area occupied by the shared memory space in the chip is smaller than the area occupied by the registers of multiple geometry data processing modules, maximum resource utilization can be achieved with a smaller chip area. Intelligent arbitration and resource management of the interface of this storage system by the geometry cache controller improves the stability of data transmission and the effectiveness of resource management. This method not only reduces register resource consumption but also enhances the system's scalability, enabling it to better adapt to future demands for high-bandwidth access to vertex data. Furthermore, intelligent arbitration and resource management of the interface improves the data transmission efficiency and stability under concurrent access by multiple modules, significantly optimizing graphics rendering performance.

[0065] In some embodiments, the data processing method provided in this disclosure may further include the following steps 201 to 202:

[0066] Step 201: Determine the data storage requirements and data transmission paths of each of the multiple geometric data processing modules.

[0067] Each geometry data processing module has specific data storage requirements to ensure efficient caching of the necessary data volume. The data transmission path refers to the path along which geometric data flows between geometry data processing modules, such as the path from the geometry data processing module to the geometry cache controller, then to the local storage system, and back to the geometry cache controller. Since different geometry data processing modules have different processing capabilities and task requirements, their data storage requirements and data transmission paths also differ, and therefore need to be determined individually.

[0068] By clearly defining the data storage requirements and data transmission paths of each geometric data processing module, the cache structure can be designed more precisely, thereby optimizing the overall system's resource allocation and performance. This avoids resource waste, improves data access efficiency, reduces chip footprint, and enhances system scalability and adaptability to future high-bandwidth access demands.

[0069] Step 202: In the geometry cache controller, configure a shared memory space that matches the data storage requirements and the data transmission path; the data transmission path is the path of data from the geometry data processing module to the geometry cache controller, from the geometry cache controller to the local storage system, and from the local storage system to the geometry cache controller.

[0070] The shared memory space is a RAM storage area set up inside the geometry cache controller to centrally cache geometric data from multiple geometry data processing modules. The design of the shared memory space is based on the data storage requirements and data transmission paths of each geometry data processing module, ensuring that its capacity is sufficient to accommodate the cached data required by all geometry data processing modules when processing vertex data.

[0071] Specifically, the data transmission path refers to the flow path of vertex data between the geometry data processing module, the geometry cache controller, and the local storage system. For example, the path from the vertex transform module (PPP) to the geometry cache controller (VCC), then to the local storage system (LMS), and then back to the geometry cache controller (VCC). This path reduces redundant paths (such as the path between the geometry cache controller (VCC) and the vertex transform module (PPP)) compared to traditional register caching methods, thereby reducing data latency and cache capacity requirements.

[0072] By configuring a shared memory space in the geometry cache controller, register sets that were originally scattered within various geometry data processing modules can be integrated into a unified cache structure, thereby reducing chip area footprint. This improves cache efficiency, enabling higher data throughput and supporting higher-performance graphics rendering and more complex application scenarios.

[0073] In some implementations, step 202 can be specifically implemented as follows: when the data storage requirement indicates that each of the multiple geometric data processing modules has its own space, in the geometric cache controller, a dedicated memory space matching the data transmission path is configured for each of the geometric data processing modules; the shared memory space includes the dedicated memory space of each of the multiple geometric data processing modules; when the data storage requirement indicates that the multiple geometric data processing modules correspond to the same space, in the geometric cache controller, a shared memory space matching the data transmission path is configured.

[0074] Dedicated memory space is used to store the geometric data of the corresponding geometric data processing module. Shared memory space is used for the geometric data of multiple geometric data processing modules.

[0075] A dedicated memory space matching the data transmission path means that data stored in the dedicated memory space is transmitted according to that data transmission path. If data stored in the dedicated memory space is not transmitted according to that data transmission path, it is considered a mismatch. For example, data accessed by the Vertex Transformer Module (PPP) needs to be stored first from the Local Storage System (LMS) to a dedicated memory space in the Geometry Cache Controller (VCC) specifically configured for the Vertex Transformer Module (PPP) (which can only store data from the Vertex Transformer Module and not data from other modules), and then transferred from the dedicated memory space in the Geometry Cache Controller (VCC) specifically configured for the Vertex Transformer Module to the Vertex Transformer Module (PPP). If the data accessed by the Vertex Transformer Module (PPP) is not transmitted according to that data transmission path, it is considered an anomaly.

[0076] A shared memory space that matches a data transmission path means that data stored in the shared memory space is transmitted according to that data transmission path. If data stored in the shared memory space is not transmitted according to that data transmission path, it is considered a mismatch. For example, data accessed by the Vertex Transformation Module (PPP) needs to be stored from the Local Storage System (LMS) to the shared memory space in the Geometry Cache Controller (VCC) (which can cache data from multiple geometry data processing modules), and then transmitted from the shared memory space in the Geometry Cache Controller (VCC) to the Vertex Transformation Module (PPP); if the data accessed by the Vertex Transformation Module (PPP) is not transmitted according to that data transmission path, an anomaly is considered to have occurred.

[0077] In this embodiment, if the data storage requirement indicates that multiple geometric data processing modules each have their own space, then in the geometric cache controller, each geometric data processing module is configured with a dedicated memory space. In this case, the shared memory space is divided into multiple spaces based on the geometric data processing modules. If the data storage requirement indicates that multiple geometric data processing modules correspond to the same space, then a shared memory space is configured in the geometric cache controller. In this case, the shared memory space is not divided and simultaneously corresponds to multiple geometric data processing modules. Regardless of whether the shared memory space is divided, its capacity must meet the data storage requirements of multiple geometric data processing modules. Thus, by analyzing the data storage requirements and data transmission paths of each geometric data processing module, the capacity and structure of the shared memory space are determined. Subsequently, this shared memory space is configured in the geometric cache controller to efficiently support the caching and transmission of vertex data. The entire process achieves centralized management and optimization of cache resources, thereby reducing chip area usage while ensuring performance and enhancing the system's scalability and adaptability.

[0078] In some embodiments, the step 101 of "allocating an interface for accessing the local storage system to the read request" can be implemented through the following steps 301 to 302:

[0079] Step 301: If the read application is multiple first read applications sent by a single geometric data processing module, then, based on the identifiers and application order of the multiple first read applications, assign corresponding interfaces to the multiple first read applications in sequence.

[0080] In some implementations, when any geometric data processing module (such as PPP or VCC) initiates multiple read requests to the system, the identifiers of each read request can be determined based on the module identifier and a preset identifier generation logic. The module identifier is used to uniquely identify each geometric data processing module. The identifier of the read request is used to uniquely identify the read request; multiple read requests issued by the same geometric data processing module have different identifiers. The preset identifier generation logic refers to a pre-defined identifier generation logic. For example, the preset identifier generation logic can be based on the module identifier of a certain geometric data processing module, and then re-encodes it using Arabic numerals to obtain the identifiers of each read request initiated by that geometric data processing module.

[0081] In some implementations, the module identifier can be determined based on the function settings of the geometric data processing module, or it can be determined based on both the function of the geometric data processing module and the execution order of the geometric data processing modules.

[0082] Since the read request identifier is determined based on the module identifier and the request order, the module identifier in the read request identifier can distinguish which geometric data processing module issued the read request (i.e., the source of the read request is known). Based on the request order, the order in which the read requests were issued can be known, enabling the system to identify the source and order of different read requests. This ensures that each request is correctly assigned to the corresponding interface, avoids conflicts or out-of-order issues between multiple read requests, improves the scheduling efficiency and stability of the system, and also guarantees the ordered processing of read requests, improving the efficiency of accessing geometric data during graphics rendering and reducing errors and delays in the data transmission process.

[0083] Step 302: In the case that the read application is a plurality of second read applications sent by the plurality of geometric data processing modules, based on the identifier, application order and execution timing of the plurality of second read applications, the plurality of second read applications are assigned corresponding interfaces in sequence; the execution timing represents the processing order of the corresponding read application in the graphics rendering.

[0084] When multiple geometric data processing modules (such as PPP and VCC) simultaneously initiate read requests, these requests may originate from different modules and have different priorities and processing orders. Therefore, in this situation, the system needs to comprehensively consider three factors: request order, execution timing, and identifier. Execution timing refers to the point in the graphics rendering process when the request should be processed. For example, if the processing of some modules depends on the data results of other modules, then the request from that module should be scheduled for execution at a later stage. By comprehensively judging these three dimensions, the system can reasonably allocate appropriate interface resources to each request, thereby optimizing overall performance and avoiding resource contention issues.

[0085] For example, if there are two read requests, they can be distinguished by their identifiers (read request 1 and read request 2). Based on the request order, it can be determined which read request was the first (read request 1 is the first) and which was the second (read request 2 is the second). If there are no restrictions on the execution timing of these two read requests, an interface can be allocated to read request 1 first, followed by read request 2. If read request 1 needs to be executed after read request 2, an interface can be allocated to read request 2 first, followed by read request 1.

[0086] By combining information from three aspects—application order, execution timing, and identifier—interfaces can be allocated, enabling efficient and orderly resource management when multiple modules concurrently read vertex data, thereby improving the stability and throughput of graphics rendering.

[0087] In practical implementation, when a single module initiates multiple read requests through multiple channels, it means that the same geometric data processing module may initiate multiple read requests through multiple channels or paths. Although these requests originate from the same module, they may involve different data blocks or operation types. Therefore, to accurately identify and schedule these requests, the system assigns a unique identifier to each read request and allocates interfaces accordingly, thereby ensuring that each read request is processed in sequence and avoiding confusion.

[0088] In practical implementation, the scenario where multiple modules can initiate read requests simultaneously indicates that during graphics rendering, multiple geometric data processing modules may submit read requests concurrently. However, due to the different responsibilities of each module in the graphics pipeline, their processing order will also differ. Therefore, execution timing, as a key parameter, reflects when a module's read request should be processed to meet the overall workflow requirements of graphics rendering. For example, if the processing of one module depends on the output of another module, the former should be executed later than the latter.

[0089] In summary, by assigning an interface to each read request, the read operations of multiple modules during graphics rendering can be effectively coordinated, avoiding data conflicts and resource contention caused by concurrent requests. In actual implementation, the system first determines whether the read request originates from a single module or multiple modules, and then uses different strategies for interface allocation: for multiple read requests from a single module, orderly scheduling is performed based on identifiers; while for concurrent read requests from multiple modules, a comprehensive judgment is made based on the request order, execution timing, and identifiers, thereby achieving efficient and stable resource management.

[0090] In this embodiment of the disclosure, by allocating an interface to read requests based on identifiers and execution timing, access to vertex data during graphics rendering can be effectively managed, thereby avoiding data conflicts and resource contention, and thus improving the caching efficiency and system scalability of the GPU geometry stage.

[0091] In some embodiments, step 301 above can be implemented by the following steps 3011 to 3012:

[0092] Step 3011: Determine the correspondence between multiple geometric data processing modules with different functions and the interfaces of the local storage system, and the idle status of multiple interfaces in the local storage system.

[0093] Multiple geometric data processing modules each undertake different types of geometric data processing tasks, such as coordinate transformation, clipping, and cache management. Each geometric data processing module has independent and non-overlapping functions, therefore, these geometric data processing modules also have different access requirements for geometric data.

[0094] An interface refers to the communication channel connecting the geometry data processing module and the local storage system. Since multiple geometry data processing modules need to access the same storage system concurrently, one or more interfaces need to be configured for each module. These interfaces not only determine how the geometry data processing modules access the local storage system but also affect the throughput and resource utilization of the entire system.

[0095] Interface idle status refers to whether an interface is currently unoccupied. By monitoring the idle status of each interface, more efficient resource scheduling and conflict avoidance can be achieved. For example, if an interface is already occupied by another geometric data processing module at a certain moment, the interface is temporarily unavailable and must wait until it is released before it can be used again.

[0096] In some implementations, the system can dynamically assess the availability of interfaces, thereby improving the overall system's resource utilization and response speed, while reducing data access latency caused by interface conflicts.

[0097] Step 3012: According to the identifiers and application order of the multiple first read applications, and based on the correspondence and the idle status of the multiple interfaces, assign corresponding interfaces to the multiple first read applications in sequence.

[0098] Each read request can include the address information of the target data, its length, and the identifier of the module that initiated the read request. This information is used to determine which interface should handle the request. The identifier of the read request can include the name or identifier of the module that initiated the read request. Therefore, the source of the read request can be distinguished by the module name or identifier, and different read requests can be routed to the interface corresponding to the module, ensuring the correctness and order of data access.

[0099] Interface allocation refers to selecting a suitable interface for each read request to access data, based on the read request's identifier, the interface's availability, and the correspondence between the interface and the module. This process requires comprehensive consideration of factors such as interface load balancing, priority strategies, and data ordering requirements to achieve optimal resource scheduling. For example, based on the module identifiers corresponding to multiple first read requests, one or more interfaces corresponding to the module identifiers can be identified, the available interfaces can be determined, and these available interfaces can be traversed and allocated to the first read requests sequentially according to their request order.

[0100] In traditional solutions, each geometry data processing module independently manages its own register set, unable to share interface resources, leading to resource waste and inefficiency. However, in this embodiment, all geometry data processing modules share the same local storage system and coordinate access through a unified interface management mechanism. When a geometry data processing module needs to initiate multiple read requests, the most suitable interface can be dynamically allocated based on the identifier of each request, the availability of the interface, and the predefined mapping relationship between the geometry data processing module and the interface. This design not only improves the utilization rate of interface resources but also enhances the system's flexibility and scalability. This optimizes the caching and access methods of vertex data in the GPU geometry stage, significantly reduces chip area footprint, and adapts to future high-bandwidth access demands, thus flexibly responding to the ever-increasing demands of graphics processing performance.

[0101] In this embodiment of the disclosure, by unifying the management and dynamically allocating interface resources, the problem of resource waste under the traditional register group approach can be effectively solved, thereby improving the efficiency of vertex data access and enhancing the overall performance and scalability of the GPU geometry stage.

[0102] In some embodiments, step 302 above can be implemented by the following steps 3021 to 3023:

[0103] Step 3021: Determine the correspondence between multiple geometric data processing modules with different functions and the interfaces of the local storage system, and the idle status of multiple interfaces in the local storage system.

[0104] Determining the mapping between the geometric data processing modules and the local storage system interfaces ensures that each module can access data through its corresponding interface, thus avoiding conflicts and resource contention. Simultaneously, the idle status of these interfaces reflects which local storage system interfaces are currently available to handle new read requests, contributing to improved overall access efficiency and resource utilization. In this way, by establishing a mapping between modules and local storage system interfaces and assessing their idle status, resources can be rationally scheduled under multi-path parallel access conditions, improving system response speed and stability.

[0105] Step 3022: Determine the access order of each of the multiple second read requests based on their identifiers, request order, and execution timing.

[0106] The request order refers to the sequence in which each read request is initiated. The execution timing refers to the expected execution time of each read request within the geometric pipeline. The identifier is a unique marker used to distinguish different read requests from different sources or with different attributes. This information collectively determines the final access order, ensuring the orderly and ordered nature of data access. By comprehensively considering the request order, execution timing, and identifier, the sorting strategy for read requests can be optimized, allowing high-priority or time-sensitive requests to be processed first, thereby reducing latency and improving system throughput.

[0107] In some implementations, multiple second read requests can be distinguished first by their identifiers, and then the order of the requests can be used as the initial access order. The initial access order can then be adjusted according to the execution timing of the multiple second read requests (e.g., if read request A depends on the output of read request B, then read request B is earlier than read request A) to obtain the access order.

[0108] Step 3023: According to the access order, based on the correspondence and the idle status of the interfaces of the multiple local storage systems, allocate the corresponding local storage system interfaces to the multiple second read requests in sequence.

[0109] In some embodiments, the interfaces accessible by the second read request, and the idle interfaces therein, can be determined based on the module identifier corresponding to the second read request. The access order of the second read requests can be determined based on the request order and execution time, and the idle interfaces corresponding to the second read requests are allocated to the corresponding second read requests in sequence according to the access order.

[0110] Based on the access order and the availability of the local storage system's interface, a suitable local storage system interface is dynamically allocated to each read request. This process involves an arbitration mechanism to ensure that each request finds a non-conflicting and optimally performing local storage system interface path.

[0111] In some implementations, when the interfaces of the local storage system can be accessed by multiple geometric data processing modules in a known order, the system iterates through the interface list of the local storage system, checks whether each interface is idle, and then selects one interface that meets the criteria for binding. This mechanism not only improves resource utilization efficiency but also avoids deadlock problems caused by interface conflicts in the local storage system.

[0112] In some implementations, when the interfaces of the local storage system are distinguished according to the geometric data processing modules and the access order is known, the read request to be allocated is determined according to the access order; the interfaces accessible by the geometric data processing module corresponding to the read request are determined according to the correspondence between the interfaces of the local storage system and the geometric data processing modules; and an idle interface is determined from the accessible interfaces and allocated to the read request.

[0113] In this embodiment, determining the access order based on the application order, execution timing, and identifier means that the system does not blindly process requests according to their arrival order. Instead, it combines the expected execution time of each request with the identifier of its respective module for a more reasonable sorting. For example, a read request from a certain module may arrive later, but its execution timing is more urgent, so it will be scheduled for earlier execution. Then, based on the correspondence between the module and the local storage system interface and the interface's availability, a suitable local storage system interface is allocated to each read request to ensure smooth data transmission. For example, if an interface is already occupied, the system will select the next available local storage system interface to bind to, thereby avoiding conflicts and waiting. By introducing a dynamic local storage system interface allocation mechanism, this disclosure can maintain good performance in complex data access scenarios, significantly reduce chip area requirements, and improve the overall efficiency and flexibility of the geometry pipeline.

[0114] In some embodiments, step 103 can be implemented by the following steps 401 or 402:

[0115] Step 401: Cache the geometric data into the shared memory space according to the order of the read requests.

[0116] In some implementations, the order of read requests can be determined based on the timestamp of the read request. When multiple read requests occur simultaneously, the order can also be determined based on the timestamp of the read request and the execution timing of the corresponding geometric data processing module.

[0117] Step 402: Determine the dedicated memory space of the geometry data processing module from the shared memory space, and cache the geometry data in the dedicated memory space of the geometry data processing module; the shared memory space includes the dedicated memory spaces of each of the multiple geometry data processing modules.

[0118] During storage, the validity of the geometric data and the corresponding geometric data processing module are recorded simultaneously.

[0119] In some implementations, geometric data can be cached in the dedicated memory space of the geometric data processing module according to the application order, or according to the access order or data acquisition order.

[0120] In this embodiment, after geometric data is read, there are two storage methods: one is to store the data sequentially into the shared memory space according to the order of read requests; the other is to allocate a dedicated memory space within the shared memory space for each geometric data processing module based on its needs, and then store the corresponding data in that dedicated memory space. These two methods are suitable for different application scenarios: the former is suitable for systems with strict requirements on access order, while the latter improves data isolation and access efficiency. This avoids the area waste problem associated with traditional cache structures and enhances system scalability. This optimizes the cache structure, thereby reducing chip area footprint and enabling it to adapt to future demands for high-bandwidth access to geometric data. Regardless of the method used, it is necessary to record the validity of the data and the geometric data processing module in which the data resides during storage to support subsequent data scheduling and verification.

[0121] In some embodiments, the data processing method provided in this disclosure further includes the following step 501:

[0122] Step 501: The multiple geometric data processing modules with different functions have different number of application paths. Each geometric data processing module simultaneously sends the corresponding number of read applications through the corresponding number of application paths.

[0123] PPP is a submodule within the GPU geometry stage, used to handle calculations related to vertex coordinates (x, y, z, w) during graphics rendering. In some implementations, PPP can initiate read requests via 11 parallel channels, with each read request corresponding to an access request for geometry data. This multi-path concurrent request design can improve the efficiency of geometry data acquisition and meet the requirements of high-bandwidth access.

[0124] VCC is the core control module in the entire Geometry Pipeline responsible for managing the geometry data cache. In some implementations, VCC can access vertex data through two-way requests. Although this minimizes the number of concurrent requests, it is primarily responsible for coordinating access requests from other modules and uniformly scheduling read and write operations of shared RAM to ensure efficient utilization of system resources.

[0125] Each module initiates read requests using different concurrency paths based on its own functional characteristics and performance requirements. This differentiated request path design not only improves the data access efficiency of each module but also avoids resource waste or bottlenecks caused by a uniform concurrency path. Furthermore, this design enhances the system's scalability, facilitating future adjustments to the concurrency configuration of each module based on performance needs.

[0126] In actual implementation, PPP initiates read requests through 11 channels, meaning that PPP can issue 11 read instructions simultaneously within one operation cycle, each pointing to a different geometric data location, thereby achieving high-concurrency access; VCC initiates read requests through 2 channels because VCC, as a control module, is mainly responsible for scheduling rather than directly processing large amounts of data, so only a small number of concurrent requests are needed to complete the task.

[0127] In this embodiment of the disclosure, by having multiple geometric data processing modules with different functions initiate read requests concurrently using different request paths based on their respective functional characteristics and performance requirements, vertex data can be accessed more efficiently, thereby improving the overall system's data processing capabilities and flexibility, and thus better adapting to the future demand for high-bandwidth vertex data access.

[0128] This disclosure provides a data processing system, which includes a geometry cache controller and a local storage system, wherein the geometry cache controller includes a shared memory space.

[0129] The local storage system is used to store geometric data from multiple geometric data processing modules;

[0130] The geometry cache controller is configured to respond to read requests initiated by the geometry data processing module, allocate an interface for the read request to access the local storage system of the graphics processing unit, obtain the geometry data corresponding to the read request from the local storage system through the interface corresponding to the read request, cache the geometry data in the shared memory space of the geometry cache controller, and return the geometry data in the shared memory space to the geometry data processing module.

[0131] The following describes the application of the data processing method provided in the embodiments of this disclosure in real-world scenarios.

[0132] This disclosure provides a vertex data processing method, wherein the vertex data corresponds to the aforementioned geometric data. Multiple modules in the geometry pipeline (such as...) Figure 2 In the traditional approach, after obtaining the required vertex data, modules one, two, three, and four store the vertex data within each access source (i.e., each module), and the access source module uses registers to cache the data. However, this embodiment of the disclosure uses a method of merging the register resources within each access source. Figure 2 The shared random access memory (shared RAM) shown (corresponding to the shared memory space mentioned above) caches the data needed by all access sources, while using a unified resource management method to process each access source, thereby optimizing chip area and enhancing system scalability.

[0133] If registers are used to cache the required vertex data in each module, the access bandwidth for vertex data will inevitably increase when the geometry pipeline performs further performance optimizations. Therefore, the increased register area and the similar caching management method for each access source are unacceptable. Therefore, this embodiment of the disclosure removes the vertex data register set from all access sources and uses RAM to cache the vertex data required by all access sources, while increasing... Figure 2 The Memory Manager module handles all access requests from all access sources.

[0134] The following describes the specific implementation process of the vertex data processing method:

[0135] 1. Read LMS application process: Module 1 initiates read applications through 11 channels, Module 2 initiates applications through 11 channels, Module 3 initiates applications through 8 channels, and Module 4 initiates applications through 2 channels, and sends them to the Vertex Cache Controller (VCC) respectively. Each module manages resources according to the pre-allocated Local Storage System (LMS) read ports, and performs order-preserving caching of each access source of the read port at the granularity of the LMS access interface, and then sends the read application to the LMS.

[0136] 2. Write to Shared RAM process: Using the LMS access interface as the granularity, according to the address allocated by the previous resource management and the order preservation result, the data returned by the LMS read is stored in the shared random access memory (Shared RAM), and the validity status of each source data requested by the interface is marked.

[0137] 3. Shared RAM Reading Process: Based on the LMS access interface, the data is sent to the respective access source according to the validity status of the data returned by each access source and the order preservation result, as recorded previously.

[0138] This disclosure allocates shared random access memory (Shared RAM) in the vertex cache controller (VCC) for caching vertex data. The total amount of Shared RAM required is smaller than the sum of the capacities of the registers in multiple modules. Shared RAM can also be used for other memories with higher integration density than registers. The capacity of the Shared RAM is determined based on the capacity of the registers in each module.

[0139] The total capacity of shared RAM is smaller than the sum of the capacities of registers in multiple modules. This is due to: 1) the characteristics of the shared RAM medium; 2) the path for storage in shared RAM is: PPP-VCC-LMS-VCC, while the path for storage in registers is: PPP-VCC-LMS-VCC-PPP. The shared RAM path saves the VCC-PPP segment, reducing data latency and thus the required data cache capacity. (During data caching, sufficient capacity must be reserved to cover latency in the data path to prevent backpressure on the preceding stage. Therefore, a shorter data path reduces data latency and the required data cache capacity.)

[0140] In some implementations, each module initiates a read request through a corresponding path. The VCC, based on the correspondence between the LMS interface and the module, the LMS's idle status, and the order of read requests, arbitrates the LMS interface corresponding to each read request and sends the read request to the LMS through the corresponding LMS interface. The VCC receives the vertex data returned by the LMS, stores the vertex data corresponding to each module in the memory space corresponding to the module in Shared RAM, and records whether the data is valid and the module in which the data resides. If the data is valid, the vertex data is sent back to the corresponding module.

[0141] During implementation, Shared RAM can be divided into multiple modules' own dedicated memory spaces, or it can be stored directly according to the order of request without division.

[0142] Based on the foregoing embodiments, this disclosure provides a data processing device, which includes the included units and the modules included in each unit, which can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0143] Figure 3 This is a schematic diagram of the composition structure of a data processing device provided in an embodiment of the present disclosure, such as... Figure 3 As shown, the data processing device 300 includes: an allocation unit 310, an acquisition unit 320, a storage unit 330, and a transmission unit 340, wherein:

[0144] The allocation unit 310 is configured to, in the geometry stage of graphics rendering in the graphics processing unit, respond to a read request initiated by the geometry data processing module and allocate an interface for the read request to access the local storage system of the graphics processing unit.

[0145] The acquisition unit 320 is configured to acquire the geometric data corresponding to the read request from the local storage system through the interface corresponding to the read request;

[0146] Storage unit 330 is configured to cache the geometry data to the shared memory space of the geometry cache controller;

[0147] The transmission unit 340 is configured to return the geometric data in the shared memory space to the geometric data processing module.

[0148] In some embodiments, the data processing apparatus 300 further includes:

[0149] The configuration unit is configured to determine the data storage requirements and data transmission paths of each of the plurality of geometric data processing modules; and to configure a shared memory space in the geometric cache controller that matches the data storage requirements and the data transmission paths; the data transmission paths are the paths from the geometric data processing modules to the geometric cache controller, from the geometric cache controller to the local storage system, and from the local storage system to the geometric cache controller.

[0150] In some embodiments, the configuration unit is further configured to, when the data storage requirement indicates that each of the multiple geometric data processing modules has its own space, configure a dedicated memory space in the geometric cache controller for each of the geometric data processing modules that matches the data transmission path; the shared memory space includes the dedicated memory spaces of each of the multiple geometric data processing modules; and when the data storage requirement indicates that the multiple geometric data processing modules correspond to the same space, configure a shared memory space in the geometric cache controller that matches the data transmission path.

[0151] In some embodiments, the allocation unit 310 is further configured to: when the read request is a plurality of first read requests sent by a single geometry data processing module, allocate corresponding interfaces to the plurality of first read requests in sequence based on the identifiers and request order of the plurality of first read requests; when the read request is a plurality of second read requests sent by a plurality of geometry data processing modules, allocate corresponding interfaces to the plurality of second read requests in sequence based on the identifiers, request order, and execution timing of the plurality of second read requests; the execution timing characterizes the processing order of the corresponding read requests in the graphics rendering.

[0152] In some embodiments, the allocation unit 310 is further configured to: determine the correspondence between multiple geometric data processing modules with different functions and the interfaces of the local storage system, and the idle status of multiple interfaces in the local storage system; and, according to the identifiers and application order of the multiple first read applications, allocate corresponding interfaces to the multiple first read applications in sequence based on the correspondence and the idle status of the multiple interfaces.

[0153] In some embodiments, the allocation unit 310 is further configured to: determine the correspondence between multiple geometric data processing modules with different functions and the interfaces of the local storage system, and the idle status of multiple interfaces in the local storage system; determine the access order of each of the multiple second read applications based on the identifier, application order and execution time of the multiple second read applications; and allocate corresponding interfaces to the multiple second read applications in sequence according to the access order, based on the correspondence and the idle status of the multiple interfaces.

[0154] In some embodiments, the storage unit 330 is configured to: cache the geometric data in the shared memory space according to the order of the read requests; or, determine the dedicated memory space of the geometric data processing module from the shared memory space and cache the geometric data in the dedicated memory space of the geometric data processing module; the shared memory space includes the dedicated memory spaces of each of the multiple geometric data processing modules; wherein, during caching, the validity of the geometric data and the geometric data processing module corresponding to the geometric data are recorded simultaneously.

[0155] In some embodiments, multiple geometric data processing modules with different functions have different request paths, and each geometric data processing module simultaneously sends the corresponding number of read requests through the corresponding request path.

[0156] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this disclosure can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this disclosure, please refer to the descriptions of the method embodiments of this disclosure for understanding.

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

[0158] This disclosure provides a computer device including a memory and a geometry cache controller. The memory stores a computer program that can run on a processor, and the geometry cache controller executes the program to implement some or all of the steps in the above-described method.

[0159] This disclosure provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium may be transient or non-transient.

[0160] This disclosure provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0161] This disclosure provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0162] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referenced interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this disclosure, please refer to the descriptions of the method embodiments of this disclosure for understanding.

[0163] It should be noted that, Figure 4 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this disclosure, such as... Figure 4 As shown, the hardware entity of the computer device 400 includes: a processor 401, a communication interface 402, and a memory 403, wherein:

[0164] Processor 401 typically controls the overall operation of computer device 400.

[0165] Communication interface 402 enables computer devices to communicate with other terminals or servers via a network.

[0166] The memory 403 is configured to store instructions and applications executable by the processor 401, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 401 and various modules in the computer device 400. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 401, the communication interface 402, and the memory 403 can be performed via bus 404.

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

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

[0169] In the several embodiments provided in this disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0170] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

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

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

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

[0174] The above description is merely an embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A data processing method, characterized by, The data processing method is applied to a geometry cache controller, and comprises the following steps: In a geometry phase of a graphics rendering performed by a graphics processing unit, an interface for accessing a local storage system of the graphics processing unit is allocated to a read application initiated by a geometry data processing module in response to the read application; Geometry data corresponding to the read application is obtained from the local storage system through the interface corresponding to the read application; The geometry data is cached to a shared memory space of the geometry cache controller; the shared memory space is a storage area set in the geometry cache controller and used for collectively caching geometry data from multiple geometry data processing modules; The geometry data in the shared memory space is returned to the geometry data processing module.

2. The data processing method according to claim 1, characterized in that, The data processing method further comprises the following steps: Data storage requirements and data transmission paths of multiple geometry data processing modules are determined; In the geometry cache controller, a shared memory space matching the data storage requirements and the data transmission paths is configured; the data transmission paths are paths of data from the geometry data processing modules to the geometry cache controller, from the geometry cache controller to the local storage system, and from the local storage system to the geometry cache controller.

3. The data processing method according to claim 2, characterized in that, The step of configuring, in the geometry cache controller, a shared memory space matching the data storage requirements and the data transmission paths comprises the following steps: In a case where the data storage requirements represent that multiple geometry data processing modules each have a space, a private memory space matching the data transmission paths is configured for each geometry data processing module in the geometry cache controller; the shared memory space comprises private memory spaces of multiple geometry data processing modules; In a case where the data storage requirements represent that multiple geometry data processing modules correspond to a same space, a shared memory space matching the data transmission paths is configured in the geometry cache controller.

4. The data processing method of claim 1, wherein, The step of allocating, to the read application, an interface for accessing the local storage system of the graphics processing unit comprises the following steps: In a case where the read application is multiple first read applications sent by a single geometry data processing module, corresponding interfaces are sequentially allocated to the multiple first read applications based on identifiers and application sequences of the multiple first read applications; In a case where the read application is multiple second read applications sent by multiple geometry data processing modules, corresponding interfaces are sequentially allocated to the multiple second read applications based on identifiers, application sequences and execution timings of the multiple second read applications; the execution timings represent processing sequences of the corresponding read applications in the graphics rendering.

5. The data processing method according to claim 4, characterized in that, The step of sequentially allocating, to the multiple first read applications, corresponding interfaces based on the identifiers and the application sequences of the multiple first read applications comprises the following steps: Corresponding relationships between multiple functionally different geometry data processing modules and interfaces of the local storage system and idle conditions of multiple interfaces in the local storage system are determined; According to the identification and application order of the plurality of first read applications, based on the correspondence and the idle condition of the plurality of interfaces, the plurality of first read applications are sequentially allocated corresponding interfaces.

6. The data processing method according to claim 4, characterized in that, The plurality of second read applications are sequentially allocated corresponding interfaces based on the identification, application order and execution timing of the plurality of second read applications, including: Determine the correspondence between a plurality of functionally different geometric data processing modules and the interfaces of the local storage system, the idle condition of the plurality of interfaces in the local storage system; Based on the identification, application order and execution timing of the plurality of second read applications, determine the access order of the plurality of second read applications; According to the access order, based on the correspondence and the idle condition of the plurality of interfaces, the plurality of second read applications are sequentially allocated corresponding interfaces.

7. The data processing method according to any one of claims 1 to 6, characterized in that, The geometric data is cached to the shared memory space of the geometric cache controller, including: According to the application order of the read application, the geometric data is cached to the shared memory space; or, Determine the exclusive memory space of the geometric data processing module from the shared memory space, and cache the geometric data to the exclusive memory space of the geometric data processing module; the shared memory space includes a plurality of exclusive memory spaces of the geometric data processing module; Wherein, when caching, whether the geometric data is valid, the corresponding geometric data processing module of the geometric data is recorded.

8. The data processing method according to any one of claims 1 to 6, characterized in that, A plurality of functionally different geometric data processing modules have different application channels, and each geometric data processing module simultaneously sends the corresponding number of read applications through the corresponding application channel.

9. A data processing system, characterized by The data processing system includes a geometric cache controller and a local storage system, and the geometric cache controller includes a shared memory space; The local storage system is used for storing geometric data of a plurality of geometric data processing modules; The geometric cache controller is used for responding to the read application initiated by the geometric data processing module, allocating an interface of the local storage system for accessing the graphic processing unit for the read application; through the corresponding interface of the read application, the corresponding geometric data of the read application is obtained from the local storage system; the geometric data is cached to the shared memory space of the geometric cache controller, and the geometric data in the shared memory space is returned to the geometric data processing module; the shared memory space is a storage area set inside the geometric cache controller, used for centralized caching of geometric data from a plurality of geometric data processing modules.

10. A data processing apparatus, characterized by, The data processing device includes: The allocation unit is configured to, in the geometric phase of the graphic processing unit for graphic rendering, respond to the read application initiated by the geometric data processing module, and allocate an interface of the local storage system for accessing the graphic processing unit for the read application; The acquisition unit is configured to, through the corresponding interface of the read application, obtain the corresponding geometric data of the read application from the local storage system; a storage unit configured to cache the geometry data to a shared memory space of the geometry cache controller; the shared memory space is a memory area set inside the geometry cache controller, used to cache geometry data from multiple geometry data processing modules; a transmission unit configured to return the geometry data in the shared memory space to the geometry data processing modules.

11. A computer device comprising a memory and a geometry cache controller, said memory storing a computer program executable on a processor, characterized in that, The geometry cache controller, when executing the program, implements the steps of the method in any one of claims 1 to 8.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the method in any one of claims 1 to 8.

Images