A buffer object access method and device, an electronic device, and a readable storage medium

Abstract

The application discloses a buffer object access method and device, electronic equipment and a readable storage medium, comprising: after receiving a calculation request and calculation data, configuring the buffer object as a non-releasable state when processing by a graphics processor; and configuring the buffer object as an accessed state when detecting that the buffer object is currently in a non-accessed state; configuring the buffer object as a non-accessed state after completing a calculation task according to the calculation request and the calculation data, and configuring the buffer object as a releasable state when detecting that the buffer object meets a release condition. The application provides a reliable, controllable and efficient buffer object access mechanism in a complex multi-stage calculation task and multi-thread operation environment, and improves the stability and security of the server in executing a calculation task.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a method, apparatus, electronic device and readable storage medium for accessing buffer objects. Background Technology

[0002] In GPU (Graphics Processing Unit) virtualization and simulation scenarios, clients typically submit computing tasks to the server for execution. The server accesses buffer objects based on the computing tasks to read and write computing data. Therefore, access control of buffer objects directly affects the stability of task execution and the correctness of data processing.

[0003] In existing technologies, the access process of buffer objects is usually controlled by a task scheduling process. The server controls the usage state of buffer objects according to the order of task start, execution and end. When a buffer object is reused continuously in different execution stages of the same task, the task scheduling process will consider the task to be completed after the previous stage is completed, and thus release the buffer object. When a buffer object is accessed concurrently by multiple tasks, the task scheduling process will consider the buffer object to be no longer used after a certain access task is completed, and thus release the buffer object.

[0004] Therefore, in multi-stage reuse or multi-threaded concurrent access scenarios, it is easy for buffer objects to be released prematurely while still in use, or for other tasks to operate on the buffer object while it is being accessed, which can lead to data errors, memory access errors, or task execution failures. Summary of the Invention

[0005] This application aims to provide a method, apparatus, electronic device, and readable storage medium for accessing buffer objects, at least to solve the problems that existing methods are prone to causing buffer objects to be released prematurely while still in use, or to be accessed by other tasks simultaneously, leading to data errors, abnormal memory access, or task execution failures.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application propose a buffer object access method, applied to a server with a graphics processor, comprising: Receive computation requests and computation data sent by the client, wherein the computation request is used to request access to a buffer object; When the computing request is processed by the graphics processor, the buffer object is configured to a non-release state; and when it is detected that the buffer object is currently in an unaccessed state, the buffer object is configured to an accessed state. After the computational data is written into the buffer object, the computation is performed by the graphics processor, and the computation result is written back to the buffer object for the client to read later. The buffer object is configured to be in an unaccessed state, and when the release condition of the buffer object is detected, the buffer object is configured to be in a releaseable state.

[0007] Secondly, embodiments of this application provide a buffer object access device, comprising: The request receiving module is used to receive calculation requests and calculation data sent by the client, wherein the calculation request is used to request access to the buffer object; The state configuration module is used to configure the buffer object to a non-release state when the graphics processor processes the computing request; and to configure the buffer object to an accessed state when it is detected that the buffer object is currently in an unaccessed state. The calculation execution module is used to write the calculation data into the buffer object, perform the calculation through the graphics processor, and write the calculation result back to the buffer object for the client to read later. The release control module is used to configure the buffer object as unaccessed and to configure the buffer object as releasable when it is detected that the buffer object meets the release conditions.

[0008] In the embodiments of this application, by configuring the buffer object to a non-release state when the graphics processor processes the computation request and configuring it to an accessing state before access, the secure management of the buffer object is achieved. This protects the buffer object during access, preventing accidental release or simultaneous access by other tasks in a multi-tasking or multi-threaded environment, thereby avoiding access conflicts. By writing the computation data provided by the client into the buffer object, and then executing the computation through the graphics processor and writing the computation result back to the buffer object, the integrity and correctness of the data during the computation process are guaranteed, while ensuring the client's secure reading of the computation result. After the access is completed, the buffer object state is restored to unaccessed, and it is released only when the release condition is met, thus achieving complete lifecycle management of the buffer object. This method can provide a reliable, controllable, and efficient buffer object access mechanism in complex multi-stage computation tasks and multi-threaded operation environments, improving the stability and security of server-side computation task execution.

[0009] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating the steps of a buffer object access method provided in an embodiment of this application; Figure 2 This is a flowchart of another buffer object access method provided in an embodiment of this application; Figure 3 This is a flowchart of another buffer object access method provided in an embodiment of this application; Figure 4 This is a flowchart of the sub-steps of a buffer object access method provided in an embodiment of this application; Figure 5 This is a flowchart of the sub-steps of a buffer object access method provided in an embodiment of this application; Figure 6 This is a flowchart of the sub-steps of a buffer object access method provided in an embodiment of this application; Figure 7 This is a flowchart of the sub-steps of a buffer object access method provided in an embodiment of this application; Figure 8 This is a flowchart of the sub-steps of a buffer object access method provided in an embodiment of this application; Figure 9 This is a flowchart of another buffer object access method provided in an embodiment of this application; Figure 10 This is a diagram of the buffer object management architecture provided in an embodiment of this application; Figure 11 This is a block diagram of a buffer object access device provided in an embodiment of this application; Figure 12 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0012] The embodiments of this application will now be described in detail. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0013] In GPU virtualization and simulation scenarios, for remote OpenCL (Open Computing Language) simulation execution, the server receives computation requests and data sent by the client and executes the corresponding kernel simulation task through the graphics processor or graphics processor simulation module. During this process, computation data needs to be written to a buffer object first. When executing the kernel simulation, data is read from the buffer object, and the computation results are written back to the buffer object for subsequent client access. The buffer object stores input, output, or intermediate data during the graphics processor's operation, and its access status affects the data correctness and execution stability of the kernel simulation task.

[0014] In related technologies, the server typically controls the access status of buffer objects based on task scheduling procedures. For example, after receiving a computation request from a client, the server executes kernel simulation tasks according to the task submission order or task priority, and accesses the corresponding buffer objects during task execution. When the same buffer object is reused continuously at different execution stages of the same task, or accessed simultaneously by multiple tasks, relying solely on the task scheduling procedure to determine the usage status of the buffer object can easily lead to inaccurate status judgments, resulting in the buffer object being mistakenly released or access conflicts occurring. Therefore, it is necessary to ensure that the server can accurately distinguish the usage status of buffer objects during access and release, avoiding mutual interference between accesses to the same buffer object in different tasks or different execution stages of the same task.

[0015] Based on this, such as Figure 1 As shown, this embodiment provides a buffer object access method applied to a server with a graphics processor, including: Step 101: Receive the calculation request and calculation data sent by the client. The calculation request is used to request access to the buffer object.

[0016] In this embodiment of the application, the computation request is a request message sent by the client to the server to trigger the graphics processor to execute a computation task; the computation data is the relevant data for executing the computation task; and the buffer object is used to store the relevant data when the graphics processor executes the computation task.

[0017] For example, in a remote OpenCL simulation execution scenario, the kernel simulation task is to multiply each element in the array by 2. The client sends a calculation request and calculation data to the server. The calculation data is the array [1, 2, 3, 4]. The calculation request is used to instruct the server to access the corresponding buffer object and process the calculation data according to the kernel simulation task.

[0018] By receiving computation requests and computation data sent by the client, and determining the buffer object that needs to be accessed based on the computation request, a clear correspondence is established between the client's computation task and the server's buffer object.

[0019] Step 102: When processing a computation request through the graphics processor, configure the buffer object to a non-release state; and when it is detected that the buffer object is currently in an unaccessed state, configure the buffer object to an accessed state.

[0020] In this embodiment, the graphics processor processing a computation request means that the server, based on the computation request sent by the client, calls the graphics processor or graphics processor simulation module to execute the corresponding kernel simulation task; configuring the buffer object as a non-release state means that the buffer object will not be released during the graphics processor processing the computation request; the unaccessed state means that the buffer object is not currently being accessed by other threads; the accessed state means that the buffer object is currently being accessed by other threads; configuring the buffer object as an accessed state can prevent the buffer object from being accessed by other threads simultaneously while participating in the current computation task.

[0021] Specifically, after the server identifies the buffer object, it obtains the reference count of the buffer object and updates the reference count so that the updated reference count does not meet the release condition; at this time, even if there is a resource cleanup process, the buffer object will not be released.

[0022] Subsequently, the server reads the access flag of the buffer object. If the access flag indicates that it has not been accessed, it means that no other thread is currently accessing the buffer object. At this time, the server sets the access flag to the accessed state to indicate that the buffer object has entered the access process of the current computation request.

[0023] By configuring buffer objects to a non-release state before the graphics processor processes computation requests, it is possible to prevent buffer objects from being released before the computation request is completed. By checking whether a buffer object is in an unaccessed state before accessing it, and configuring it to an accessed state only when it is not accessed, it is possible to prevent multiple computation requests or multiple threads from accessing the same buffer object at the same time, thereby reducing the risk of data races or data overwriting.

[0024] Step 103: After writing the calculation data into the buffer object, perform the calculation through the graphics processor and write the calculation result back into the buffer object for subsequent reading by the client.

[0025] In this embodiment of the application, the graphics processor performing computation refers to the graphics processor processing the computation data in the buffer object according to the kernel simulation task corresponding to the computation request; the computation result is the execution result of the kernel simulation task.

[0026] Specifically, the server writes the array [1, 2, 3, 4] sent by the client into a buffer object for storage. Then, the graphics processor starts executing the kernel simulation task. First, it reads the array [1, 2, 3, 4] from the buffer object and processes it according to the calculation logic of multiplying each element by 2 to obtain the calculation result [2, 4, 6, 8]. The calculation result is then written back to the buffer object. When the client reads the result later, it can obtain the calculation result from the buffer object.

[0027] By first writing the computational data into a buffer object, and then having the graphics processor perform computations based on the data in the buffer object, the computational data can have a clear storage location on the server side, avoiding unclear data sources or chaotic data transmission during the computation process, which is beneficial to the stable execution of computational tasks in remote OpenCL simulation scenarios.

[0028] Step 104: Configure the buffer object to be in an unaccessed state, and when the release condition of the buffer object is detected, configure the buffer object to be in a releaseable state.

[0029] In this embodiment, the "unaccessed" state indicates that no task is currently performing an access operation on the buffer object; the release condition is a condition used to determine whether the buffer object can be released. For example, the buffer object is no longer occupied by a computation request and is not currently in an accessed state; the "releaseable" state means that the buffer object has met the release requirements and can be reclaimed by the server.

[0030] Specifically, after the kernel simulation task multiplies each element in the array by 2 and writes the result array back to the buffer object, the buffer object is configured as unaccessed. Subsequently, the server checks whether the buffer object meets the release conditions. For example, the server determines whether the buffer object is still occupied by other threads based on its reference count. If the buffer object is no longer occupied by other computation requests and is currently in an unaccessed state, the server configures the buffer object as a releaseable state so that the buffer object can be reclaimed later.

[0031] By configuring a buffer object to be free only when the release condition is met, you can avoid releasing the buffer object while it is still occupied or may still be accessed, thus ensuring the accuracy of the release timing of the buffer object and reducing memory access exceptions or resource management errors.

[0032] In summary, by configuring the buffer object to a non-release state when the graphics processor processes the computation request and configuring it to an accessed state before access, secure management of the buffer object is achieved. This protects the buffer object during access, preventing accidental release or simultaneous access by other tasks in a multi-tasking or multi-threaded environment, thus avoiding access conflicts. By writing the computation data provided by the client into the buffer object, then executing the computation through the graphics processor and writing the computation result back to the buffer object, the integrity and correctness of the data during the computation process are guaranteed, while ensuring the client's secure reading of the computation result. After access is completed, the buffer object state is restored to unaccessed, and it is released when the release condition is met, achieving complete lifecycle management of the buffer object. This method provides a reliable, controllable, and efficient buffer object access mechanism in complex multi-stage computation tasks and multi-threaded operation environments, improving the stability and security of server-side computation task execution.

[0033] Optional, such as Figure 2 As shown, prior to step 101, the method includes steps 105-107: Step 105: Upon receiving a creation request from the client, create a buffer object for the computation request.

[0034] Step 106: Obtain the global object list, and write the buffer object to the global object list when the global object list is in an unaccessed state.

[0035] Step 107: After writing is complete, configure the global object list to be in an unaccessed state.

[0036] In this embodiment of the application, for steps 105-107 above, the creation request refers to the request information sent by the client to the server to request the server to create a buffer object; the request may carry the size, identification information, or relevant parameters required for subsequent calculation requests of the buffer object; the buffer object may include management information such as handle, virtual address, memory pointer, size, reference count, access status, and linked list pointer; for use in calculation requests means that after the buffer object is created, it can be used as a data interaction space for subsequent calculation requests.

[0037] Specifically, in a remote OpenCL simulation execution scenario, after the server receives the creation request, it first allocates memory space for the buffer object to actually store subsequent calculation data. Then, it creates a structure for the buffer object and records the handle, virtual address, memory pointer, size, reference count, access status, and linked list pointer of the buffer object in the structure.

[0038] In this embodiment, the global object list is a list structure that manages multiple buffer objects; the global object list is in an unaccessed state, which can be understood as no other thread currently performing insertion, deletion, or modification operations on the global object list; writing a buffer object into the global object list means adding the created buffer object as a list node to the global object list.

[0039] Specifically, when the server detects that there is no global object list, it creates a global object list. This global object list is used to store various buffer objects that the server has already created, such as BO1, BO2, BO3, etc. Before adding the newly created buffer object to the global object list, it first checks whether the global object list is currently being operated on by other threads. If it is being operated on, it waits until the global object list becomes accessible. Then, the server acquires the mutex lock corresponding to the global object list, indicating that the global object list is currently occupied by this thread, and other threads cannot simultaneously perform insertion, deletion, or modification operations on the list. Finally, the newly created buffer object is written to the global object list.

[0040] In this embodiment of the application, the unaccessed state means that no thread is currently occupying the global object list to perform operations such as insertion, deletion, or modification.

[0041] Specifically, after the buffer object is written, the server releases the mutex. Once the mutex is released, it means that the write operation on the global object list has ended, and the global object list is no longer occupied by the current thread. At this time, the global object list can be inserted, deleted, or modified by other threads, that is, the global object list is configured to be in an unaccessed state.

[0042] For example, a buffer object can be represented using the following structure: typedef struct vgpu_bo { uint32_t handle; / / BO handle uint64_t va_addr; / / Virtual address size_t size; / / Size of BO void *cpu_ptr; / / CPU memory pointer atomic_int refcnt; / / Reference counting atomic_bool being_accessed; / / Concurrency access flag struct vgpu_bo *next; / / Linked list pointer vgpu_bo_t; The specific parameter values ​​of the structure of the buffer object BO8 created in step 105 are as follows: The handle field value is set to 8; the va_addr field value is set to 0x100800000; the size field value is set to 4096; the cpu_ptr field value is set to 0x7f9e4c006f20; the refcnt field value is set to 1; the being_accessed field value is set to false; bo *next is empty because the buffer object has not yet been stored in the global object list.

[0043] The global object list obtained in step 106 is vgpu_bo_t *g_bo_list=[BO1, BO2, ..., BO7]. When the server is about to write the newly created BO8 into this global object list, it first tries to acquire the mutex lock corresponding to the global object list. If the mutex lock detects that the global object list is in an unaccessed state, BO8 is written into the global object list while holding the mutex lock. At this time, BO7's bo *next points to BO8, and the global object list is updated to [BO1, BO2, ..., BO7, BO8].

[0044] Step 107: After the write operation is complete, release the mutex lock and configure the global object list to be in an unaccessed state.

[0045] In summary, by creating buffer objects for computation requests and writing them to the global object list, the server can manage all buffer objects in a unified manner, making it easier to quickly find the corresponding buffer object based on the computation request. By introducing a mutex lock, multiple threads can be prevented from simultaneously inserting, deleting, or modifying buffer objects in the global object list, reducing the risk of list node corruption or buffer object loss.

[0046] Optionally, the buffer object includes guidance information; such as... Figure 3 As shown, the method includes steps 108-109: Step 108: Parse the computation request using the graphics processor to obtain the target guidance information carried in the computation request.

[0047] Step 109: Locate the guidance information corresponding to the target guidance information in the global object list, and determine the buffer object to be accessed by the calculation request based on the guidance information; the guidance information includes the handle and virtual address.

[0048] In this embodiment of the application, for steps 108-109 above, the calculation request is used to instruct the graphics processor to perform the corresponding calculation task, including the buffer object that needs to be accessed in this calculation, and the corresponding data processing method; the target guidance information may include the handle information, virtual address information, or other information that can uniquely or relatively uniquely locate the buffer object.

[0049] Specifically, the client needs to execute a kernel simulation task, such as multiplying each element in the array by 2. The client sends a calculation request to the server, which carries target guidance information. This target guidance information can be the handle information of the buffer object, such as handle=8, or the virtual address information of the buffer object, such as va=0x100800000.

[0050] In this embodiment, the global object list is a list on the server that stores information about all buffer objects, used to support the creation, registration, retrieval, reuse, and release management of buffer objects.

[0051] Specifically, after receiving the computation request, the server parses the request using the graphics processing unit (GPU) or GPU emulation module, extracting target guidance information from it. For example, if the computation request carries handle information (handle=8) or virtual address information (va=0x100800000), the server searches the global object list for a buffer object containing the corresponding handle or virtual address. The found buffer object is then identified as the target buffer object that the computation request needs to access. For instance, if the current global object list contains eight buffer objects (BO1, BO2, ..., BO8), the field information for each buffer object might be as follows: BO1: { handle = 1; va_addr = 0x100100000; size = 2048; cpu_ptr=0x7f9e4c000b20; refcnt=1; being_accessed=false; bo *next=BO2; }; BO2: { handle=2; va_addr=0x100200000; size=1024; cpu_ptr=0x7f9e4c001020; refcnt=1; being_accessed=false; bo *next=BO3; } , ...... , BO8: { handle=8; va_addr=0x100800000; size=4096; cpu_ptr=0x7f9e4c006f20; refcnt=1; being_accessed=false; bo *next=NULL; }; When the server receives a computation request, it parses the request. If the handle information carried in the computation request is handle = 8, the server starts searching from the head node of the global object list. First, it reads the handle field of BO8 and detects that BO8's handle is 8, which matches the handle=8 carried in the computation request. Therefore, the server determines BO8 as the target buffer object that the computation request needs to access.

[0052] By introducing target guidance information, the server can accurately determine the buffer object that the computation request needs to access, avoiding the problem of unclear access object due to a large number of buffer objects. The guidance information includes handles and virtual addresses, allowing the server to determine the buffer object based on either the handle or the virtual address. This adapts to different types of computation request access methods, improves the flexibility and accuracy of buffer object lookup, and ensures that the graphics processor can access the correct buffer object when performing computation tasks.

[0053] Optionally, the buffer object includes a reference count; the reference count is used to characterize whether the buffer object can be released; step 102 specifically includes: Step 1021: Set the current value of the reference count to a first value using atomic reference counting. The first value is used to characterize the buffer object as being in a non-release state.

[0054] In this embodiment, atomic reference counting means that the process of updating the reference count is executed as a complete operation in a multi-threaded environment and will not be modified by other threads during the update process. That is, when one thread is updating the reference count of the buffer object, other threads cannot modify the same reference count at the same time, thereby avoiding lost or erroneous updates of the reference count; the current value refers to the count value recorded by the buffer object before this update, which reflects the current reference status of the buffer object; the first value is the count value obtained after the atomic reference counting update, which is used to indicate that the buffer object is still in a used or pending state and cannot be released.

[0055] Specifically, the server obtains the current reference count of the buffer object as 1, indicating that the buffer object is currently only managed by the global object list. When a computation request needs to access the buffer object, the server updates the reference count to the first value, such as 2. This update process is completed through atomic reference counting, so that obtaining the current value and writing back the first value are performed as a continuous counting update process, avoiding counting errors caused by multiple threads updating the same reference count simultaneously. For example, in a kernel simulation scenario where each element in an array is multiplied by 2, after the server determines the buffer object that the current computation request needs to access, it updates the reference count of the buffer object from 1 to 2 through atomic reference counting. When the reference count is 2, the buffer object is determined to not meet the release condition, so the buffer object will not be released during the process of writing array data, reading computation, and writing back the result.

[0056] By using atomic reference counting to update the reference count of a buffer object from its current value to a first value, the reference state of the buffer object can be accurately recorded in a multi-threaded environment, avoiding count loss or errors when multiple threads update the reference count simultaneously. By setting the first value to indicate that the buffer object does not currently meet the release condition, the server can keep the buffer object from being released during the processing of computation requests. This can prevent the buffer object from being prematurely released by the resource cleanup process during data writing, graphics processor calculation, or result write-back, thereby reducing the risk of access exceptions and computation interruptions, and thus improving the stability of computation task execution and the reliability of data processing.

[0057] Optional, such as Figure 4 As shown, sub-step 1021 specifically includes sub-steps 10211-10214: Sub-step 10211: When the reference count is detected to be in a state where it has not been accessed by other threads, configure the reference count to be in an accessed state.

[0058] Sub-step 10212: Get the current value of the reference count.

[0059] Sub-step 10213: After incrementing the current value to obtain the first value, change the current value to the first value.

[0060] Sub-step 10214: Configure the reference count to an unaccessed state.

[0061] In this embodiment of the application, for sub-steps 10211-10214, the reference count being in a state of not being accessed by other threads means that no other thread is currently reading, calculating, or writing back the reference count; other threads can be calculation threads, access threads, or resource cleanup threads running concurrently on the server; configuring the reference count to a state of being accessed means that the current thread has obtained the permission to update the reference count, indicating that the reference count is being processed by the current thread, and other threads cannot modify the reference count at the same time.

[0062] For example, the reference count of the buffer object BO8 in the server is currently 1. Thread A is preparing to process a computation request to access BO8 and needs to update the reference count of BO8. Thread A first checks if the reference count has been updated by thread B or thread C. If it hasn't been processed by thread B or thread C, then thread A marks the reference count as accessed. At this point, if thread B or thread C also wants to update the reference count of BO8, they need to wait for thread A to complete its update.

[0063] For example, if the current reference count of BO8 is 1, it means that the buffer object is currently only managed by the global object list. After thread A obtains the permission to update the reference count, it reads the current value as 1, which serves as the basis for subsequent increment calculations.

[0064] In this embodiment of the application, incrementing calculation refers to adding one or increasing by a preset amount based on the current value of the reference count; the first value refers to the new reference count value obtained after the incrementing calculation, which is used to indicate that the buffer object has been occupied by an access request or a computing task, and therefore does not meet the release condition.

[0065] Specifically, thread A obtains the current reference count of BO8 as 1. Thread A increments this current value to get the first value of 2, and updates the reference count of BO8 from 1 to 2. At this time, the reference count of BO8 is 2, which means that the buffer object has been occupied by the current computation request. BO8 should not be released during the period when the computation request accesses BO8.

[0066] In this embodiment of the application, the unaccessed state means that other threads can continue to perform update operations on the reference count.

[0067] For example, thread A has updated the reference count of BO8 from 1 to 2; after the update, thread A sets the reference count to an unaccessed state. Subsequently, if thread B also needs to handle another computation request to access BO8, thread B can continue to obtain the current value of BO8's reference count and perform the next update based on the current value. Alternatively, after thread A has set the reference count to an unaccessed state, thread B starts executing the computation task. In this case, if thread B needs to access BO8, thread B can continue to obtain the current value of BO8's reference count and perform the next update based on the current value.

[0068] By checking whether the reference count is not accessed by other threads before updating it, and configuring it as accessed during the update process, multiple threads can avoid simultaneously reading and modifying the same reference count, reducing the chance of lost or incorrect updates. For example, when two threads access the same buffer object simultaneously, they will not both read the current value 1 and write back 2. Instead, thread A will read the current value 1 and update it to 2, while thread B will read the current value 2 and update it to 3. The updated value indicates that the buffer object is currently occupied by the access request, preventing the server from mistakenly classifying the buffer object as available for release during subsequent release checks, thus ensuring that the buffer object remains valid during request processing.

[0069] Optionally, the buffer object includes access flags; such as Figure 5 As shown, step 102 specifically includes sub-steps 1022-1024: Sub-step 1022: Obtain the current value of the access flag.

[0070] Sub-step 1023: When it is determined from the current value that the buffer object is currently in an accessed state, the calculation request begins to wait until the buffer object is in an unaccessed state.

[0071] Sub-step 1024: When it is determined that the buffer object is currently in an unaccessed state based on the current value, change the current value to the second value; the second value is used to indicate that the buffer object is in an accessed state.

[0072] In this embodiment, for sub-steps 1022-1024, the access flag is a status identifier used to indicate whether the buffer object is currently being accessed. The access flag can include an accessed state and an unaccessed state. The accessed state indicates that the buffer object is currently being accessed by a computation request, thread, or task; the unaccessed state indicates that the buffer object is not currently being accessed.

[0073] Specifically, there is a buffer object BO8 in the server. Thread A is about to access BO8 according to the calculation request. Before accessing it, thread A first reads the access flag of BO8. If the access flag reads that it has been accessed, it means that BO8 is currently being accessed by other threads. If the access flag reads that it has not been accessed, it means that BO8 can be accessed by thread A.

[0074] In this embodiment, the accessed state means that the buffer object is currently being accessed by other computation requests or threads. The access operation here may include writing computation data to the buffer object, reading data from the buffer object, performing kernel simulation computation, or writing back the computation result. The computation request starting to wait means that the current computation request does not perform the access operation on the buffer object for the time being, but waits for the ongoing access process to end.

[0075] For example, thread A is accessing BO8 and has already set the access flag of BO8 to the accessed state; at this time, thread B also receives a computation request that needs to access BO8; after reading the access flag of BO8, thread B finds that BO8 is currently in the accessed state, so thread B does not access BO8 immediately, but enters a waiting state; only after thread A completes the access to BO8 and restores the access flag of BO8 to the unaccessed state can thread B continue to execute subsequent access operations.

[0076] In this embodiment, the second value refers to a status value indicating that the buffer object has entered the access process. For example, the access flag can be represented by a Boolean value, where a first status value of false indicates that it has not been accessed, and a second value of true indicates that it has been accessed.

[0077] For example, after waiting, thread B reads the access flag of BO8 again and finds that BO8 is currently in an unaccessed state. At this time, thread B changes the access flag of BO8 from false (which corresponds to unaccessed) to the second value true. After the modification, BO8 is marked as accessed, indicating that thread B has obtained the opportunity to access BO8, and other threads will not access BO8 simultaneously when they read this state.

[0078] By obtaining the current value of the access flag and putting the computation request into a waiting state when the buffer object is in an accessed state, multiple computation requests or multiple threads can be prevented from accessing the same buffer object simultaneously. By modifying the access flag to a second value indicating that the buffer object has been accessed when it is in an unaccessed state, it can be clearly identified that the buffer object has entered the access process of the current computation request. This can reduce data overwriting, data races, or abnormal computation results caused by concurrent access, thereby ensuring the access order and data reliability of the buffer object during task execution.

[0079] Optionally, the buffer object includes a memory pointer; such as Figure 6 As shown, step 103 specifically includes sub-steps 1031-1035: Sub-step 1031: Determine the address of the buffer object in memory based on the memory pointer; write the calculated data into the memory corresponding to the address.

[0080] Sub-step 1032: Read the computed data from the buffer object.

[0081] Sub-step 1033: Perform kernel simulation on the calculated data to obtain the calculation results.

[0082] Sub-step 1034: Write the calculation result to the buffer object.

[0083] Sub-step 1035: Determine the address of the buffer object in memory based on the memory pointer; write the calculation result to the memory corresponding to the address.

[0084] In this embodiment, for sub-steps 1031-1035, the memory pointer is information pointing to the actual storage area by the buffer object. When the server creates the buffer object, it allocates a segment of memory for the buffer object. The memory pointer is used to record the location of this memory segment, enabling the server to find the storage space corresponding to the buffer object based on the pointer. Memory is the actual storage area used to store data. In this embodiment, memory can be used to store computational data sent by the client, or it can be used to store computational results obtained after the graphics processor performs computation. The address is the identifier of the specific storage location in memory. Based on the memory pointer in the buffer object, the server can determine the memory address corresponding to the buffer object and write computational data or computational results into the storage area corresponding to that address.

[0085] For example, when the server creates a buffer object BO8, it allocates a memory space for BO8 and records a memory pointer cpu_ptr in the BO8 structure. This memory pointer points to the memory address corresponding to BO8, such as 0x7f9e4c006f20. The calculation data sent by the client is an array [1, 2, 3, 4]. The server determines the memory address 0x7f9e4c006f20 of BO8 based on the memory pointer in BO8, and then writes the array [1, 2, 3, 4] into the memory area corresponding to that address.

[0086] In this embodiment, the kernel simulation task performed by the graphics processor is to multiply each element in the array by 2. The graphics processor reads the array [1, 2, 3, 4] from the memory corresponding to BO8, performs the calculation, and obtains the result array [2, 4, 6, 8]. After the calculation is completed, the server determines the memory address 0x7f9e4c006f20 corresponding to BO8 based on the memory pointer of BO8, and writes the result array [2, 4, 6, 8] into the memory area corresponding to that address. At this time, the data stored in BO8 is updated from the input array to the calculation result, and the client can subsequently read BO8 to obtain the calculation result.

[0087] By determining the memory address corresponding to the buffer object using a memory pointer and writing the computational data to the memory area corresponding to that address, the computational data sent by the client can be accurately stored in the target buffer object, avoiding ambiguity in the write location or writing to the wrong object. After the computation is completed, the memory address corresponding to the buffer object is determined again based on the memory pointer, and the computation result is written back to the memory area corresponding to that address, ensuring that the computation result corresponds to the original buffer object, facilitating subsequent reading by the client. Thus, the writing of computational data, the computational processing by the graphics processor, and the writing back of computational results are all completed around the same buffer object, ensuring the clarity of the data flow path and the accuracy of the computational result acquisition.

[0088] In this embodiment of the application, the computational data is data that has been written into the buffer object and needs to participate in kernel simulation processing, such as arrays, matrices, image pixel data, etc.

[0089] For example, the client sends the calculation data as an array [1, 2, 3, 4]; the server has already written this array into the buffer object BO8; before executing the kernel simulation, the graphics processor or graphics processor simulation module reads the array [1, 2, 3, 4] from BO8 according to the memory location corresponding to BO8, as the input data for this kernel simulation task.

[0090] In this embodiment, kernel simulation is the process by which the server simulates the execution of computational tasks by the graphics processor according to the kernel computation logic submitted by the client; here, the kernel can be a specific computational function, such as array element multiplication, matrix operation, or image processing function; the computational result is the output data obtained after performing kernel simulation on the computational data.

[0091] For example, the kernel simulation task in this case is to multiply each element in the array by 2. After the graphics processor or graphics processor simulation module reads the array [1, 2, 3, 4] in BO8, it performs the multiplication by 2 on each element in turn to obtain the calculation result [2, 4, 6, 8].

[0092] In this embodiment of the application, writing the calculation result to the buffer object means that the server re-stores the output data obtained from the kernel simulation into the corresponding buffer object, so that the buffer object saves the result data of this calculation task for the client to read later.

[0093] For example, after the server completes the kernel simulation by multiplying the array elements by 2, it obtains the result array [2, 4, 6, 8]. Subsequently, the server writes the result array into the memory area corresponding to BO8. After the writing is completed, the data stored in BO8 is the calculation result [2, 4, 6, 8]. The client can then read BO8 to obtain the calculation result.

[0094] By first reading computational data from a buffer object, then performing kernel simulation on that data, and finally writing the results back to the buffer object, the input data, computation, and output results are all processed within the same buffer object. This ensures that the data source and result storage location for the kernel simulation task are clearly defined, avoiding confusion in the correspondence between computational data and results. Furthermore, after the computational results are written back to the buffer object, the client can read the results based on that buffer object, making the data flow path during remote OpenCL simulation execution clearer and helping to ensure the accuracy of the computational results and the continuity of the computational task execution.

[0095] Optionally, the buffer object includes a reference count; such as Figure 7 As shown, in step 104, after configuring the buffer object to an unaccessed state, steps 1041-1044 are included: Step 1041: When the reference count is detected to be in a state where it has not been accessed by other threads, configure the reference count to be in an accessed state.

[0096] Step 1042: Obtain the current value of the reference count.

[0097] Step 1043: After calculating the third value by decreasing the current value, change the current value to the third value; the third value is used to represent the current release state of the buffer object.

[0098] Step 1044: Configure the reference count to be in an unaccessed state.

[0099] In this embodiment of the application, for steps 1041-1044, the reference count being in a state of not being accessed by other threads means that no other thread is currently performing read, increment, decrement, or write-back operations on the reference count; other threads may be threads in the server that are processing other computation requests, access requests, or resource cleanup processes; configuring the reference count to a state of being accessed means that the current thread has obtained the permission to update the reference count, so that other threads cannot modify the reference count simultaneously for the time being.

[0100] For example, the reference count of buffer object BO8 is currently 2. After thread A completes its access to BO8, it needs to update the reference count. Thread A first checks whether the reference count of BO8 has been modified by thread B. If it has not been modified, it sets the reference count to the accessed state. At this time, even if thread B is also preparing to update the reference count of BO8, it needs to wait for thread A to complete its update of the reference count.

[0101] In this embodiment of the application, the current value refers to the value recorded by the reference count of the buffer object before the current decrement calculation is performed. This value is used to indicate the current occupancy status of the buffer object.

[0102] For example, after thread A acquires the permission to update the reference count of BO8, it reads the reference count of BO8 and gets the current value of 2. This value indicates that BO8 is still in an occupied state and has not yet met the conditions for release.

[0103] In this embodiment of the application, the decrement calculation refers to the calculation of decreasing the reference count by one or by a set amount based on the current value of the reference count; the third value refers to the new reference count value obtained after the decrement calculation; the third value is used to characterize whether the buffer object currently meets the release condition. If the third value still does not meet the release condition, it means that the buffer object still needs to be retained; if the third value meets the release condition, it means that the buffer object can enter the release process.

[0104] For example, thread A reads that the current reference count of BO8 is 2, and decrements the current value to get a third value of 1. Then, thread A updates the reference count of BO8 from 2 to 1. If the system sets the reference count to 1 to indicate that only the global object list manages the references, then the third value of 1 can indicate that BO8 currently meets the release judgment condition. The server can then determine whether to release BO8 based on whether BO8 is in an unaccessed state.

[0105] For example, both thread A and thread B need to access BO8. During the access process, BO8's reference count is 3, including the global object list management reference, the access reference corresponding to thread A, and the access reference corresponding to thread B. After thread A completes its access, thread A reads the current reference count of BO8 as 3 and decrements it to obtain a third value of 2. Subsequently, thread A updates BO8's reference count from 3 to 2. Since the third value of 2 indicates that BO8 still has other references besides the global object list management reference, if thread B is still accessing it, the third value of 2 does not meet the release condition, and the server continues to retain BO8 without performing a release operation. After thread B completes its access, the reference count is decremented again. If the updated reference count meets the release condition, the server then determines whether to release BO8 based on its access status.

[0106] In this embodiment of the application, configuring the reference count to an unaccessed state means that after the current thread completes the reading, decrementing, and writing back operations of the reference count, it releases the update occupation of the reference count, so that other threads can continue to perform subsequent updates or judgments on the reference count.

[0107] For example, thread A has updated the reference count of BO8 from 2 to 1. After the update, thread A sets the reference count to an unaccessed state. After that, if thread B needs to query or update the reference count of BO8, it can continue to access the reference count field.

[0108] In the above process, by confirming that the reference count has not been accessed by other threads before decrementing the reference count and configuring the reference count to an accessed state during the update, we can avoid multiple threads reading and modifying the same reference count simultaneously, thus reducing the risk of reference count update conflicts. By executing the process in the following order—first occupying the reference count, then reading the current value, then performing the decrement calculation, then writing back the third value, and finally releasing the occupied state—we can ensure that the decrementing process of the reference count has a clear sequential relationship, preventing multiple threads from repeatedly modifying the reference count after completing access simultaneously.

[0109] Optional, such as Figure 8 As shown, step 104 includes: Step 1045: Get the current value of the reference count.

[0110] In this embodiment, the current value of the reference count refers to the value recorded by the reference count before the release judgment is performed on the buffer object; this value is used to reflect whether the buffer object is still being occupied by access requests, computing tasks or other threads.

[0111] For example, if there is a buffer object BO8 on the server, and thread A has completed accessing BO8 and updating the reference count, the server needs to determine whether BO8 can be released. So it reads the current value of BO8's reference count. If the current value is 1, it means that BO8 may only have references managed by the global object list. If the current value is 2, it means that BO8 may still be occupied by other threads or tasks.

[0112] Step 1046: When the current value is detected to be the set release value, configure the buffer object to be released.

[0113] In the embodiments of this application, the set release value refers to a pre-set reference count value used to determine whether the buffer object can be released. For example, the release value can be set to 1, indicating that the buffer object is only managed by the global object list and is no longer occupied by access requests or computing tasks; the releaseable state means that the buffer object has met the release judgment conditions and can enter the subsequent resource release process, such as releasing the corresponding memory space, removing or cleaning up structure information from the global object list.

[0114] For example, after thread A completes its access to BO8, it updates the reference count of BO8 from 2 to 1. The server then obtains the current reference count of BO8. If it detects that the current value is the set release value of 1, it will indicate that BO8 is in a releaseable state. At this time, BO8 can enter the subsequent release process.

[0115] For example, both thread A and thread B access BO8. After thread A completes its access, the reference count of BO8 is updated from 3 to 2. After the server obtains the current value, it detects that the current value is 2, which is not equal to the set release value of 1. This indicates that BO8 has not yet met the release condition, so BO8 will not be configured as a releaseable state. After thread B completes its access and updates the reference count from 2 to 1, the server obtains the current value again and detects that the current value is the set release value of 1. Only then will BO8 be configured as a releaseable state.

[0116] By obtaining the current reference count during the release determination phase and comparing it with the set release value, the server can determine whether to allow the release based on the actual usage of the buffer object. If the current value has not reached the set release value, it means the buffer object may still be occupied by other tasks or threads, and the server continues to retain the buffer object. If the current value reaches the set release value, it means the buffer object is no longer occupied by access requests or computational tasks, and it can be configured to be released. This avoids prematurely releasing buffer objects while they are still in use and makes the release timing of buffer objects more accurate.

[0117] Optionally, the buffer object includes a linked list pointer; a sub-step of step 106 writes the buffer object to a global object list, including: Step 1061: Connect the buffer object to the global object list using a linked list pointer.

[0118] In this embodiment, a linked list pointer refers to a pointer field in the buffer object structure used to point to other buffer objects. Through the linked list pointer, different buffer objects can be connected in a certain order to form a global object list.

[0119] Specifically, the server has already created two buffer objects, BO1 and BO2. The current global object list is: BO1→BO2. At this time, the server receives a new creation request and creates a buffer object BO3. The structure of BO3 includes a linked list pointer field. The server can use the linked list pointer of BO2 to point to BO3, thereby adding BO3 to the global object list. For example, after inserting BO3 at the end of the list, the global object list becomes: BO1→BO2→BO3. In this way, BO3 is registered in the global object list. When the server receives a calculation request later, it can search for BO1, BO2, and BO3 in sequence along the linked list and determine the target buffer object based on the handle or virtual address.

[0120] This embodiment describes a method for accessing buffer objects, applied in an OpenCL scenario, such as... Figure 9 As shown, the specific process is as follows: S1, Request Sending Phase.

[0121] The OpenCL application first sends a buffer object creation request to the server, for example, sending `GEM_CREATE(handle=8, size=4096)`. In response to this request, the server creates a buffer object `BO8` with a handle of 8 and a size of 4096 bytes, and allocates corresponding memory space for `BO8`. After creation, the server initializes the reference count of `BO8` to 1. This reference count indicates that `BO8` has been created by the server and is in a basic management state. Subsequently, the OpenCL application sends a virtual address configuration request, for example, sending `GEM_VA(handle=8, va=0x100800000)`. The server locates `BO8` based on handle 8 and writes the virtual address `0x100800000` into the virtual address field `va_addr` of `BO8`. Through this process, a correspondence is established between `BO8` and the virtual address, and the server can subsequently determine the buffer object to be accessed based on this virtual address.

[0122] S2, Enter the data writing stage.

[0123] The OpenCL application requests to write 512 bytes of computational data to the buffer object corresponding to virtual address 0x100800000. The server locates BO8 based on this virtual address, and after determining the actual memory location of BO8 based on the memory pointer cpu_ptr in BO8, it writes the computational data sent by the OpenCL application to the actual memory area pointed to by the memory pointer cpu_ptr, so that BO8 stores the input data needed for this kernel simulation task.

[0124] S3. Enter the computation task execution phase.

[0125] The OpenCL application sends CS_SUBMIT(job_id=123,deps=[8]), which indicates that a computation task with the number 123 is submitted and that the computation task depends on a buffer object with handle 8. The server determines that BO8 is the buffer object that the current computation task needs to access based on the dependency information and updates the reference count of BO8 from 1 to 2. After the reference count is updated to 2, it indicates that BO8 is in an occupied state during the execution of the current computation task and does not meet the release condition.

[0126] Before executing the kernel simulation, the server sets the access flag of BO8, being_accessed, to true, indicating that BO8 is currently being accessed. After that, the server executes the kernel simulation task. Specifically, the server reads the computation data from the memory area pointed to by cpu_ptr of BO8, performs the simulation calculation according to the corresponding kernel computation logic, and writes the calculation result back to the memory area corresponding to BO8. For example, if the kernel simulation task is to multiply each element in the array by 2, the server reads the input array from BO8, performs the multiplication by 2, and then rewrites the result array back into BO8.

[0127] S4. Enter the task waiting phase.

[0128] The OpenCL application sends WAIT_CS(job_id=123) to wait for the computation task numbered 123 to complete. After confirming that the kernel simulation task has been completed, the server sets the access flag being_accessed of BO8 to false, indicating that BO8 is no longer under access. Subsequently, the server can return the output data saved in BO8 to the client, or allow the client to retrieve the output data through a read request later.

[0129] S5, Buffer object closing phase.

[0130] The OpenCL application sends GEM_CLOSE(handle=8), and the memory management module finds BO8 based on handle 8 and updates the reference count of BO8 from 2 to 1. At this time, although the application side has closed the buffer object, the reference count of BO8 is still 1, indicating that BO8 is still in the basic management state. Therefore, the memory management module does not release BO8 for the time being.

[0131] S6, Task Cleanup Phase.

[0132] The server executes a job cleanup process, updating the reference count of BO8 from 1 to 0. When the reference count is updated to 0 and the access flag of BO8 is false, it means that BO8 is neither occupied by a computing task nor in the process of being accessed. At this time, the server safely releases BO8, including releasing the actual memory area pointed to by cpu_ptr, cleaning up the structure information of BO8, and removing BO8 from the global object list. Through the above process, BO8 forms a complete lifecycle management from creation, address configuration, data writing, kernel simulation execution, task completion, to final release.

[0133] The GPU buffer object management architecture of this application embodiment is as follows: Figure 10 As shown, the GPU buffer object management architecture is connected to the OpenCL simulation execution engine for unified management of buffer objects during OpenCL simulation execution. This management architecture includes an atomic reference counting mechanism, a concurrency access control mechanism, a global list management mechanism, and a complete lifecycle management mechanism. Specifically, the atomic reference counting mechanism updates the reference state when a buffer object is referenced or released to support safe resource release; the concurrency access control mechanism performs selective synchronization when multiple tasks or threads access buffer objects to avoid concurrent access conflicts; the global list management mechanism centrally registers and searches created buffer objects, supporting rapid location of buffer objects through dual lookup using handles and virtual addresses; and the complete lifecycle management mechanism covers the creation, reference, access, and release processes of buffer objects to support buffer object reuse in multi-stage tasks and ensure the safe management of the memory corresponding to buffer objects. Through this management architecture, the OpenCL simulation execution engine can reliably access and orderly release the required buffer objects when executing computational tasks.

[0134] This application provides a buffer object access device, applied to a server with a graphics processor, such as... Figure 11 As shown, it includes: The request receiving module 201 is used to receive the calculation request and calculation data sent by the client. The calculation request is used to request access to the buffer object. The state configuration module 202 is used to configure the buffer object to a non-release state when processing a calculation request through the graphics processor; and to configure the buffer object to an accessed state when it is detected that the buffer object is currently in an unaccessed state. The calculation execution module 203 is used to write the calculation data into the buffer object, perform the calculation through the graphics processor, and write the calculation result back to the buffer object for subsequent reading by the client. Release control module 204 is used to configure the buffer object as unaccessed and to configure the buffer object as releasable when the release condition is met.

[0135] Optionally, the request receiving module 201 includes: Create a submodule to create a buffer object for the computation request before receiving the computation request and computation data sent by the client. When a creation request is received from the client, the buffer object is created. The submodule also retrieves the global object list and writes the buffer object to the global object list if the list is in an unaccessed state. After writing, the global object list is configured to be in an unaccessed state.

[0136] Optionally, the buffer object includes guidance information; The status configuration module 202 includes: The lookup submodule is used to parse the computation request through the graphics processor, obtain the target guidance information carried in the computation request, search for the guidance information corresponding to the target guidance information in the global object list, and determine the buffer object to be accessed by the computation request based on the guidance information; the guidance information includes handle and virtual address.

[0137] Optionally, the buffer object includes a reference count; the reference count is used to characterize whether the buffer object can be released. The status configuration module 202 further includes: The configuration submodule is used to configure a buffer object to be in a non-release state, including: setting the current value of the reference count to a first value through atomic reference counting, where the first value is used to characterize the buffer object as being in a non-release state.

[0138] Optionally, the configuration submodule includes: The reference count setting unit is used to set the current value of the reference count to a first value through atomic reference counting, including: when it is detected that the reference count is in a state where it has not been accessed by other threads, configuring the reference count to a state where it has been accessed; obtaining the current value of the reference count; incrementing the current value to obtain the first value, and then changing the current value to the first value; configuring the reference count to a state where it has not been accessed.

[0139] Optionally, the buffer object includes an access flag; The status configuration module 202 further includes: The access configuration submodule is used to configure a buffer object to be accessed when it is detected that the buffer object is currently in an unaccessed state. This includes: obtaining the current value of the access flag; when it is determined that the buffer object is currently in an unaccessed state based on the current value, changing the current value to a second value; the second value is used to indicate that the buffer object is in an accessed state; after obtaining the current value of the access flag, the module further includes: when it is determined that the buffer object is currently in an accessed state based on the current value, calculating that the request starts waiting until the buffer object is in an unaccessed state.

[0140] Optionally, the buffer object includes a memory pointer; The computation execution module 203 includes: The write submodule is used to write computational data to a buffer object, including: determining the memory address of the buffer object based on the memory pointer; and writing the computational data to the memory address corresponding to the memory address. The write-back submodule is used to write the calculation results back to the buffer object, including: determining the address of the buffer object in memory based on the memory pointer; and writing the calculation results to the memory corresponding to the address.

[0141] Optionally, the calculation execution module 203 further includes: The execution submodule is used to perform calculations through the graphics processor, including: reading calculation data from a buffer object; performing a calculation kernel simulation on the calculation data to obtain the calculation results; and writing the calculation results to a buffer object.

[0142] Optionally, the buffer object includes a reference count; The release control module 204 includes: The reference count update submodule is used to configure the reference count to be accessed after configuring the buffer object to be unaccessed and detecting that the reference count is not accessed by other threads. It obtains the current value of the reference count; calculates a third value by decrementing the current value, and then changes the current value to the third value. The third value is used to represent the current release state of the buffer object; and the reference count is configured to be unaccessed.

[0143] Optionally, the release control module 204 further includes: The release submodule is used to configure a buffer object into a releaseable state when it is detected that the release condition is met. This includes: obtaining the current value of the reference count; and configuring the buffer object into a releaseable state when the current value is detected as the set release value.

[0144] Optionally, the buffer object includes a linked list pointer; The creation of the submodule includes: The write sub-unit is used to write the buffer object to the global object list, including: connecting the buffer object to the global object list via a linked list pointer.

[0145] In summary, in this embodiment of the invention, the buffer object access device achieves efficient and secure management of buffer objects through the collaborative work of a request receiving module, a state configuration module, a calculation execution module, and a release control module. Specifically, the request receiving module accurately receives calculation requests and data sent by the client, providing reliable input for subsequent processing; the state configuration module configures the buffer object to a non-release state when processing calculation requests and sets it to an accessed state when not accessed, effectively preventing the buffer object from being accidentally released or accessed by other tasks during the execution of a calculation task, avoiding data contention and access conflicts; the calculation execution module writes calculation data into the buffer object, performs the calculation, and then writes the result back to the buffer object, achieving closed-loop management of data input, calculation processing, and result storage, ensuring the accuracy of calculation results and data consistency; the release control module restores the buffer object to an unaccessed state after calculation and configures it to a releaseable state when the release conditions are met, achieving secure management of the buffer object's lifecycle, thereby avoiding memory leaks and unnecessary resource consumption, and improving the overall stability and reliability of the server executing calculation requests in a multi-threaded, multi-tasking environment.

[0146] The buffer object access device in this embodiment of the invention can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This embodiment of the invention does not impose specific limitations.

[0147] The buffer object access device in this embodiment of the invention can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this embodiment of the invention does not impose specific limitations.

[0148] The buffer object access device provided in this embodiment of the invention can implement the various processes implemented by the buffer object access device in the method embodiment. To avoid repetition, these processes will not be described again here.

[0149] Optionally, embodiments of the present invention also provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the various processes of the above-described buffer object access method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0150] It should be noted that the electronic devices in the embodiments of the present invention include the mobile electronic devices and non-mobile electronic devices described above.

[0151] Figure 12 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of the present invention.

[0152] The electronic device 1300 includes, but is not limited to, components such as: radio frequency unit 1301, network module 1302, audio output unit 1303, input unit 1304, sensor 1305, display unit 1306, user input unit 1307, interface unit 1308, memory 1309, and processor 1310.

[0153] Those skilled in the art will understand that the electronic device 1300 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 1310 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 12 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0154] It should be understood that, in this embodiment of the invention, the input unit 1304 may include a graphics processing unit (GPU) 13041 and a microphone 13042. The GPU 13041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 1306 may include a display panel 13061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 1307 includes a touch panel 13071 and at least one of other input devices 13072. The touch panel 13071 is also called a touch screen. The touch panel 13071 may include a touch detection device and a touch controller. Other input devices 13072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0155] The memory 1309 can be used to store software programs and various data. The memory 1309 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 1309 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 1309 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0156] Processor 1310 may include one or more processing units; optionally, processor 1310 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 1310.

[0157] Optionally, embodiments of the present invention also provide a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described buffer object access method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0158] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A method for accessing a buffer object, applied to a server with a graphics processor, characterized in that, include: Receive computation requests and computation data sent by the client, wherein the computation request is used to request access to a buffer object; When the computing request is processed by the graphics processor, the buffer object is configured to a non-release state; and when it is detected that the buffer object is currently in an unaccessed state, the buffer object is configured to an accessed state. After the computational data is written into the buffer object, the computation is performed by the graphics processor, and the computation result is written back to the buffer object for the client to read later. The buffer object is configured to be in an unaccessed state, and when the release condition of the buffer object is detected, the buffer object is configured to be in a releaseable state.

2. The method according to claim 1, characterized in that, Prior to the step of receiving the computation request and computation data sent by the client, the following steps are included: Upon receiving a creation request from the client, a buffer object is created for the computation request to use; Obtain a global object list, and when the global object list is in an unaccessed state, write the buffer object into the global object list; After the writing is completed, the global object list is configured to be in an inaccessible state.

3. The method according to claim 2, characterized in that, The buffer object includes guidance information; The method further includes: The graphics processor parses the computation request to obtain the target guidance information carried in the computation request; The system searches for guidance information corresponding to the target guidance information in the global object list, and determines the buffer object to be accessed by the computation request based on the guidance information; the guidance information includes a handle and a virtual address.

4. The method according to claim 1, characterized in that, The buffer object includes a reference count; the reference count is used to indicate whether the buffer object can be released. Configuring the buffer object to a non-release state includes: The current value of the reference count is set to a first value by atomic reference counting, and the first value is used to characterize that the buffer object is in a non-release state.

5. The method according to claim 4, characterized in that, The step of setting the current value of the reference count to a first value through atomic reference counting includes: When the reference count is detected to be in a state where it has not been accessed by other threads, the reference count is configured to be in an accessed state. Get the current value of the reference count; After incrementing the current value to obtain the first value, the current value is changed to the first value; Configure the reference count to an unaccessed state.

6. The method according to claim 1, characterized in that, The buffer object includes an access flag; The step of configuring the buffer object to an accessed state when it is detected that the buffer object is currently in an unaccessed state includes: Get the current value of the access flag; When it is determined that the buffer object is currently in an unaccessed state based on the current value, the current value is changed to a second value; the second value is used to indicate that the buffer object is in an accessed state. Following the step of obtaining the current value of the access flag, the method further includes: When the current value determines that the buffer object is currently in an accessed state, the calculation request begins to wait until the buffer object is in an unaccessed state.

7. The method according to claim 1, characterized in that, The buffer object includes a memory pointer; The step of writing the calculated data into the buffer object includes: The memory address of the buffer object is determined based on the memory pointer; the calculated data is written to the memory corresponding to the address. The step of writing the calculation result back to the buffer object includes: The address of the buffer object in memory is determined based on the memory pointer; the calculation result is written to the memory corresponding to the address.

8. The method according to claim 1, characterized in that, The calculation performed by the graphics processor includes: Read the computed data from the buffer object; The computational kernel is simulated on the computational data to obtain the computational results; The calculation result is written to the buffer object.

9. The method according to claim 1, characterized in that, The buffer object includes a reference count; Following the step of configuring the buffer object to an unaccessed state, the following is included: When the reference count is detected to be in a state where it has not been accessed by other threads, the reference count is configured to be in an accessed state. Get the current value of the reference count; After calculating the third value by decreasing the current value, the current value is changed to the third value; the third value is used to represent the current release state of the buffer object; Configure the reference count to an unaccessed state.

10. The method according to claim 9, characterized in that, The step of configuring the buffer object to a releaseable state when the release condition is met includes: Get the current value of the reference count; When the current value is detected to be the set release value, the buffer object is configured to be releaseable.

11. The method according to claim 2, characterized in that, The buffer object includes a linked list pointer; The step of writing the buffer object into the global object list includes: The buffer object is linked to the global object list via the linked list pointer.

12. A buffer object access device, applied to a server with a graphics processor, characterized in that, include: The request receiving module is used to receive calculation requests and calculation data sent by the client, wherein the calculation request is used to request access to the buffer object; The state configuration module is used to configure the buffer object to a non-release state when the graphics processor processes the computing request; and to configure the buffer object to an accessed state when it is detected that the buffer object is currently in an unaccessed state. The calculation execution module is used to write the calculation data into the buffer object, perform the calculation through the graphics processor, and write the calculation result back to the buffer object for the client to read later. The release control module is used to configure the buffer object as unaccessed and to configure the buffer object as releasable when the release condition is met.

13. An electronic device, characterized in that, The electronic device includes a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors according to any one of claims 1 to 11.

14. A readable storage medium, characterized in that, When the instructions in the readable storage medium are executed by a processor of an electronic device, the processor is enabled to perform the method as described in any one of claims 1 to 11.

Images