An apparatus, method, electronic device and storage medium for asynchronously committing a command set

Abstract

The present disclosure relates to the technical field of computers, and provides an apparatus and method for asynchronously submitting a command set, an electronic device and a storage medium, which are applied to a user mode driver (UMD). The apparatus comprises a main thread and an asynchronous thread. The main thread writes an identifier of a current command buffer in a command buffer array into an identifier storage area in response to a command set submission request of a graphical programming interface, and returns a response result of the command submission request to the graphical programming interface. The current command buffer is used to store commands currently written by an application program. The asynchronous thread takes out a new identifier from the identifier storage area if the new identifier exists in the identifier storage area, and performs a command set submission operation on a command buffer corresponding to the new identifier. The present disclosure can improve the utilization rate of CPU resources.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, and particularly relates to an apparatus and method for asynchronously submitting a command set, an electronic device and a storage medium. BACKGROUND

[0002] When a computer renders graphics, an application uses a graphics programming interface (such as DirectX or OpenGL) to describe the image it wants to display on the screen. These descriptions are converted into graphics rendering commands and stored in a command buffer. Then, the commands in the command buffer are submitted to the graphics hardware for execution through the coordination of the operating system (OS), user mode driver (UMD) and kernel mode driver (KMD).

[0003] Command buffer submission is the process of passing these commands from the software layer to the hardware for execution. After the graphics hardware receives the rendering commands, it begins to execute them, and eventually displays the rendered image on the screen. It should be noted that the completion of command buffer submission does not mean that graphics rendering has been completed, but only indicates that the commands have begun to be executed on the graphics hardware. The actual rendering process may take some time to complete, depending on the complexity of the commands and the capabilities of the hardware.

[0004] The user mode driver needs to wait for each command buffer submission request to return from the kernel mode driver before it can continue execution, to ensure that the commands have actually been rendered, and then rewrite the instructions in the command buffer. The switching process from user mode to kernel mode is very time-consuming, and if the application and user mode driver initiate a large number of command buffer submission requests, the entire application and user mode driver will be in a CPU waiting state, resulting in wasted CPU resources and a slower response speed of the application. SUMMARY

[0005] The present disclosure provides a technical solution for asynchronously submitting a command set.

[0006] According to an aspect of the present disclosure, an apparatus for asynchronously submitting a command set is provided, which is applied to a user mode driver (UMD) and includes a main thread and an asynchronous thread, wherein:

[0007] The main thread writes the identifier of a current command buffer in a command buffer array into an identifier storage area in response to a command set submission request of a graphics programming interface, and returns a response result of the command submission request to the graphics programming interface, the current command buffer being used to store commands currently being written by an application.

[0008] The asynchronous thread takes out the new identifier if the new identifier exists in the identifier storage area, and performs a command set submission operation on the command buffer corresponding to the new identifier.

[0009] In a possible implementation, the main thread takes the next command buffer in the command buffer array as the current command buffer if the submission result of the next command buffer is submission completion.

[0010] In a possible implementation, the main thread returns the command buffer submission result to the graphic programming interface after writing the identifier of the current command buffer in the command buffer array into the identifier storage area.

[0011] In a possible implementation, the asynchronous thread determines the target command buffer from the command buffer array according to the new identifier taken out from the identifier storage area;

[0012] The command set in the target command buffer is submitted.

[0013] In a possible implementation, the asynchronous thread calls the callback function provided by the graphic programming interface to perform the command set submission operation on the command buffer corresponding to the identifier;

[0014] The asynchronous thread receives the callback function result returned by the graphic programming interface, and determines the submission result of the command set submission operation.

[0015] In a possible implementation, the asynchronous thread determines the submission result of each command buffer, and marks the submission result in the command buffer array.

[0016] In a possible implementation, the asynchronous thread suspends and waits for the main thread to write the new identifier into the identifier storage area if there is no new identifier in the identifier storage area.

[0017] In a possible implementation, the identifier storage area is a ring buffer.

[0018] According to an aspect of the present disclosure, a method for asynchronously submitting a command set is provided, which is applied to an apparatus for asynchronously submitting a command set, the apparatus including a main thread and an asynchronous thread, and the method includes:

[0019] The main thread writes the identifier of the current command buffer in the command buffer array into the identifier storage area in response to a command set submission request of a graphic programming interface, and returns a response result of the command submission request to the graphic programming interface, the current command buffer being used to store commands currently written by an application program;

[0020] The asynchronous thread takes out the new identifier in the case that the new identifier exists in the identifier storage area, and performs a command set submission operation on a command buffer corresponding to the new identifier.

[0021] According to an aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to perform the above method.

[0022] According to an aspect of the present disclosure, a computer-readable storage medium is provided, having stored thereon computer program instructions, which, when executed by a processor, implement the above method.

[0023] In the embodiments of the present disclosure, the user mode driver includes a main thread and an asynchronous thread. The main thread writes an identifier of a current command buffer into an identifier storage area in response to a command set submission request of a graphic programming interface, the current command buffer being used to store a command set that an application is currently writing, and returns a response result of the command submission request to the graphic programming interface. The asynchronous thread takes out a new identifier in the case that the new identifier exists in the identifier storage area, and performs a command set submission operation on a command buffer corresponding to the new identifier. In this way, the main thread writes the identifier of the current command buffer into the identifier storage area and immediately returns the response result to the graphic programming interface, and the asynchronous thread performs the command set submission operation asynchronously according to the new identifier, so that the asynchronization of the command set submission process is realized. The main thread can process other tasks (such as a next command set submission request) without waiting for the command set submission to be completed, so that the waiting time of the CPU is reduced and the utilization rate of the CPU resources is improved. At the same time, the graphic programming interface can continue to write commands into a next command buffer based on the response result, so that the application can maintain smooth responsiveness and efficient processing capability, the application can continue to write a new command set more efficiently based on the response result without waiting for the current command set submission to be completed, and thus the response speed and overall performance of the application are improved.

[0024] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, but not limiting the present disclosure. Other features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0025] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present disclosure and, together with the specification, serve to explain the technical solutions of the present disclosure.

[0026] Figure 1A flowchart showing an operation flow of command buffer submission.

[0027] Figure 2 A block diagram showing an apparatus for asynchronously submitting a command set according to an embodiment of the present disclosure.

[0028] Figure 3 A scenario diagram showing an application scenario of an apparatus for asynchronously submitting a command set according to an embodiment of the present disclosure.

[0029] Figure 4 A flowchart showing a method for asynchronously submitting a command set according to an embodiment of the present disclosure.

[0030] Figure 5 A block diagram showing an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0031] Various exemplary embodiments, features and aspects of the present disclosure will be explained in detail below with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar elements. Although various aspects of the embodiments are illustrated in the drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

[0032] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any implementation described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations.

[0033] The term "and / or", merely describes association relationship of associated objects, and means that three relationships can exist, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. In addition, the term "at least one" herein means any one of multiple or any combination of at least two of multiple, for example, including at least one of A, B and C can mean including any one or more elements selected from the set consisting of A, B and C.

[0034] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the specific embodiments below. Those skilled in the art should understand that the present disclosure can also be implemented without certain specific details. In some examples, methods, means, elements and circuits that are well known to those skilled in the art are not described in detail in order to highlight the main idea of the present disclosure.

[0035] Figure 1 A flowchart showing an operation flow of command buffer submission. As Figure 1As shown, when a complete command buffer submission operation is performed: 1. an application calls a graphics programming interface (Direct3D runtime); 2. the Direct3D runtime initiates a command buffer submission to a user mode driver; 3. the user mode driver calls a submission callback function of the Direct3D runtime, the Direct3D runtime is switched from user mode to kernel mode, 4. a kernel interface of a DirectX graphics kernel subsystem (DXGK) is called; 5. the DirectX graphics kernel subsystem submits the command buffer to a kernel mode driver (KMD); 6. the kernel mode driver returns a submission result to the DirectX graphics kernel subsystem; 7. the DirectX graphics kernel subsystem returns the submission result to the Direct3D runtime; 8. the Direct3D runtime is switched from kernel mode back to user mode, and returns the submission result to the user mode driver as a result of the callback function; 9. the user mode driver returns the submission result to the Direct3D runtime, 10. the Direct3D runtime feeds back to the application. The application starts to write a graphics rendering command set to the command buffer again, and performs a next command buffer submission.

[0036] That is, the command buffer submission needs to be switched from user mode to kernel mode by the Direct3D runtime, and waits for the DirectX graphics kernel subsystem to return the result to the user mode driver, and then the user mode driver performs the next operation. However, the switching process from user mode to kernel mode is very time-consuming, if the application and the user mode driver initiate a large number of command buffer submission requests, the entire application and the user mode driver will be in a CPU waiting state, resulting in waste of CPU resources, and low response speed of the application.

[0037] In the embodiments of the present disclosure, the user mode driver includes a main thread and an asynchronous thread. The main thread writes an identifier of a current command buffer in a command buffer array into an identifier storage area in response to a command set submission request of a graphic programming interface, and returns a response result of the command submission request to the graphic programming interface. The current command buffer is used to store an instruction set that an application is currently writing. The asynchronous thread takes out a new identifier from the identifier storage area and performs a command set submission operation on a command buffer corresponding to the new identifier, if the new identifier exists in the identifier storage area. In this way, the main thread writes the identifier of the current command buffer into the identifier storage area and returns the response result to the graphic programming interface immediately, and the asynchronous thread performs the command set submission operation asynchronously according to the new identifier, so that the asynchronization of the command set submission process is realized. The main thread can process other tasks (such as a next command set submission request) without waiting for the command set submission to be completed, so that the waiting time of the CPU is reduced and the utilization rate of the CPU resources is improved. At the same time, the graphic programming interface can continue to write commands into a next command buffer based on the response result, so that the application can maintain smooth responsiveness and efficient processing capability, and the application can continue to write a new command set more efficiently based on the response result without waiting for the current command set to be submitted, thereby improving the response speed and overall performance of the application.

[0038] Figure 2 A block diagram of an apparatus for asynchronously submitting a command set according to an embodiment of the present disclosure is shown in FIG. 1. Figure 2 As shown in FIG. 1, a user mode driver UMD includes a main thread 11 and an asynchronous thread 12, wherein:

[0039] The main thread writes an identifier of a current command buffer in a command buffer array 15 into an identifier storage area 14 in response to a command set submission request of a graphic programming interface 13, and returns a response result of the command submission request to the graphic programming interface. The current command buffer is used to store an instruction set that an application is currently writing.

[0040] The asynchronous thread 12 takes out a new identifier from the identifier storage area 14 and performs a command set submission operation on a command buffer corresponding to the new identifier, if the new identifier exists in the identifier storage area.

[0041] A graphic programming interface is a software interface for creating and rendering graphics. The graphic programming interface provides a set of functions and classes for handling the rendering and computation of graphics. The graphic programming interface enables developers to create high-quality graphics applications, such as games, simulators, visualization tools, etc., by utilizing hardware acceleration technology. In an example, the graphic programming interface can include Direct3D, OpenGL, Vulkan, etc. In the embodiments of the present disclosure, the apparatus for asynchronously submitting a command set is described by taking Direct3D as an example.

[0042] A user mode driver is used to handle the low-level interaction with the graphics hardware and translates the graphics rendering requirements of an application into actual rendering operations. An application describes the graphics to be displayed through the use of APIs provided by a graphics programming interface (e.g., Direct3D), and the user mode driver translates the description into commands that the graphics hardware can understand, i.e., graphics rendering commands.

[0043] In a Direct3D-based graphics rendering process, the user mode driver works in conjunction with a kernel mode driver, the user mode driver runs in the user mode of the Direct3D runtime, and the kernel mode driver runs in the kernel mode. The user mode driver and the kernel mode driver interact with each other through a specific communication mechanism to submit a graphics rendering command set to the graphics hardware for execution. The user mode driver runs in the user mode and can only access the user address space, it does not have the access authority of the kernel mode driver, so it can avoid some security risks.

[0044] In the embodiments of the present disclosure, the thread in which the user mode driver is located is referred to as a main thread, and the user mode driver creates another new thread, which is referred to as an asynchronous thread for ease of description. The user mode driver creates a storage area to store an identifier. The storage area is used to realize the communication between the main thread and the asynchronous thread, and the main thread informs the asynchronous thread of the command buffer of the instruction set to be submitted through the storage area. For ease of description, the present disclosure refers to the storage area as an identifier storage area.

[0045] In a possible implementation, the identifier storage area is a ring buffer, which can store a certain amount of data in a fixed-size buffer, and the reading and writing of data are realized through the circular movement of a pointer. Specifically, two pointers are used in the ring buffer, one points to the writing position, and the other points to the reading position. When the writing pointer reaches the end of the buffer, it is reset to the start position of the buffer, forming a cycle. Similarly, the reading pointer also moves in the same way, so that the circular reading and writing of data can be realized.

[0046] The command buffer array includes a plurality of command buffers, and the identifier of the command buffer is an identifier of each command buffer in the command buffer array. By using the identifier, different command buffers can be distinguished, so as to correctly manage and execute the graphics rendering commands contained in the command buffer, and realize the asynchronous submission of the command set.

[0047] In a possible implementation, the main thread takes the next command buffer in the command buffer array as the current command buffer in a case where the submission result of the next command buffer is submission completion.

[0048] The next command buffer in the command buffer array, which can be the next command buffer in the command buffer array in the order of the identifiers, the current command buffer is used to store the commands that the application is currently writing. The application can write commands to the command buffer array in the order of the identifiers of the command buffers, and the command buffer being written to the command buffer array is the current command buffer.

[0049] Because there are multiple command buffers in the command buffer array, the application and the user mode driver do not need to wait for each command buffer to return a submission completion from the kernel mode driver after submitting a request. As long as the command set submission of the next command buffer is completed, the application can write the instruction set to the next command buffer, that is, continue to write instructions to the command buffer that has been submitted. In this way, the application can maintain smooth responsiveness and efficient processing capability, while fully utilizing CPU resources.

[0050] The asynchronous thread communicates with the user mode driver through the identifier storage area. The identifier in the identifier storage area represents the command buffer that needs to perform command set submission. Therefore, when there is a new identifier in the identifier storage area, the asynchronous thread takes out the new identifier and performs a command set submission operation on the command buffer corresponding to the new identifier.

[0051] This process ensures the asynchronous processing of command buffer submission and improves the performance of the application and the user mode driver. By using the identifier storage area, the asynchronous thread can effectively track and manage the command buffers that need to perform command set submission.

[0052] The main thread can return a response result of the command submission request to the graphics programming interface when writing the identifier of the current command buffer in the command buffer array to the identifier storage area. The response result can be a submission completion result. In one possible implementation, the main thread returns the command buffer submission result to the graphics programming interface after writing the identifier of the current command buffer in the command buffer array to the identifier storage area.

[0053] After the main thread writes the identifier of the current command buffer to the identifier storage area, the asynchronous thread will asynchronously perform a command set submission operation. At this time, the main thread can not wait for the command set submission to be completed, but can directly return a submission completion result to the graphics programming interface. In this way, the graphics programming interface can continue to perform other tasks (for example, continue to use the next command buffer as the current command buffer and continue to write commands to the current command buffer), without waiting for the asynchronous thread to complete the submission operation of the command buffer.

[0054] For the graphics programming interface, it continues to write commands into the command buffer only after receiving the feedback of the successful submission of the command buffer. In the technical solution of the present disclosure, the command buffer is submitted in an asynchronous manner. In order to enable the graphics programming interface to continue to write commands into the next command buffer without waiting for all the command buffers to be submitted, the main thread can immediately send the submission result of the submission completion to the graphics programming interface after writing the identifier of the current command buffer into the identifier storage area, so as to enable the graphics programming interface to continue to write commands into the next command buffer. In this way, the application program can maintain smooth responsiveness and efficient processing capability, and at the same time, the CPU resources are fully utilized.

[0055] In a possible implementation, the asynchronous thread determines the target command buffer corresponding to the new identifier taken from the identifier storage area from the command buffer array; and submits the command set in the target command buffer.

[0056] After the asynchronous thread takes the new identifier from the identifier storage area, the asynchronous thread determines the target command buffer corresponding to the new identifier from the command buffer array. Through this operation, the asynchronous thread can find the command buffer that needs to submit the command set, so as to ensure the correct submission of the command set.

[0057] Then, the asynchronous thread submits the command set in the target command buffer and sends the command set in the command buffer to the graphics hardware for execution. Through the submission of the command set, the graphics hardware is driven to perform the actual rendering operation. The process is performed asynchronously and does not block the execution of the main thread. The main thread can continue to perform other tasks without waiting for the submission operation of the command buffer to be completed. This asynchronous processing manner can improve the performance of the application program and the user mode driver and fully utilize the computing capability of the multi-core processor, thereby realizing efficient and asynchronous graphics rendering processing.

[0058] In a possible implementation, the asynchronous thread calls the callback function provided by the graphics programming interface to perform the command set submission operation on the command buffer corresponding to the identifier; and the asynchronous thread receives the callback function result returned by the graphics programming interface to determine the submission result of the command set submission operation.

[0059] When performing the command set submission operation, the asynchronous thread calls the callback function provided by the graphics programming interface. The callback function is a mechanism provided by the graphics programming interface, which allows developers to customize some operations or processing flows to be executed when a specific event occurs.

[0060] By invoking the callback function, the asynchronous thread can perform the command set submission operation on the command buffer identified. The graphics programming interface is switched from user mode to kernel mode to perform the subsequent submission operation. As an example, in the case of a graphics programming interface being a Direct3D runtime, when performing the submission operation, the Direct3D runtime invokes a kernel interface of a DirectX Graphics Kernel Subsystem (DXGK), the DirectX Graphics Kernel Subsystem submits the command buffer to a Kernel Mode Driver (KMD), the Kernel Mode Driver returns the submission result to the DirectX Graphics Kernel Subsystem, the DirectX Graphics Kernel Subsystem returns the submission result to the Direct3D runtime, the Direct3D runtime is switched from kernel mode back to user mode, and the submission result is returned to the asynchronous thread as the result of the callback function.

[0061] According to the result of the callback function, the asynchronous thread can determine the submission result of the command set submission operation.

[0062] In embodiments of the present disclosure, the asynchronous thread performs the command set submission operation on the command buffer identified by invoking a callback function provided by the graphics programming interface, and determines the submission result by receiving the result of the callback function. This mechanism improves the flexibility and customizability of command processing, while ensuring the correctness and reliability of the submission operation.

[0063] In a possible implementation, the asynchronous thread determines the submission result for each command buffer, and marks the submission result in the command buffer array.

[0064] After performing the command set submission operation, the asynchronous thread determines the submission result for each command buffer. The submission result can be different states such as success, failure, or need for retry. The asynchronous thread needs to determine the submission result for each command buffer according to the result of the callback function.

[0065] After determining the submission result for each command buffer, the asynchronous thread marks the corresponding result in the command buffer array. Specifically, the command buffer can have a state information, and the asynchronous thread can mark the submission result by updating the state information.

[0066] There can be various ways to mark the submission result in the command buffer array, which can be determined according to actual needs, for example, the submission result can be marked by setting a flag bit, updating a state value, or using other data structures.

[0067] By marking the submission result in the command buffer array, the main thread can effectively track and manage the status of each command buffer, ensuring correct processing and response to the submission result. For example, in the case of successful submission, the main thread can determine that the command set in the command buffer can be overwritten based on the successful submission result; in the case of failed submission, the main thread can initiate re-submission (re-write the identification of the command buffer with failed submission to the identification storage area) or return the corresponding result to the graphics programming interface. In this way, the correct operation of the application and user mode driver can be maintained, improving the efficiency of rendering processing while improving the reliability of rendering processing.

[0068] In a possible implementation, the asynchronous thread suspends and waits for the main thread to write the new identification to the identification storage area when there is no new identification in the identification storage area.

[0069] When the asynchronous thread has no new identification in the identification storage area, it will be suspended and wait for the main thread to write the new identification to the identification storage area. In this way, the asynchronous thread can release processor resources during the waiting period so that other threads or processes can use these resources.

[0070] When the main thread writes the new identification to the identification storage area, the wake-up mechanism of the asynchronous thread can be triggered to restore the asynchronous thread from the suspended state and continue to execute the task of asynchronously submitting the command set.

[0071] In this way, an effective cooperation mechanism is established between the asynchronous thread and the main thread. The main thread is responsible for managing the writing of identification and responding to the graphics programming interface, while the asynchronous thread determines whether to execute the task or wait according to the presence or absence of identification. This asynchronous cooperation method improves the performance of the application and user mode driver and ensures the effective use of CPU resources.

[0072] An application scenario of an embodiment of the present disclosure is described below. In this application scenario, the graphics programming interface is specifically Direct3D runtime, Figure 3 An application scenario diagram of the device for asynchronously submitting a command set according to an embodiment of the present disclosure is shown in FIG. 1. Figure 3 As shown in FIG. 1, the flow of asynchronously submitting a command set is as follows:

[0073] User-mode driven (UMD) creates a fixed-size circular buffer. The specific implementation of this circular buffer is a fixed-size buffer, and its specific operating principle can be found in the possible implementation methods provided in this disclosure. This circular buffer is used for data transmission between the main thread and asynchronous threads. In addition, an array of command buffers of number N (N is a positive integer, such as N=128) is created, which contains N command buffers. Command buffers 0 to N-1 record the command sets they generate. The identifier of each command buffer is the slot ID, and the slot IDs are fixed, ranging from 0 to N-1.

[0074] Step 1: The Direct 3D runtime initiates a command buffer submission.

[0075] After the main thread starts, it will repeatedly execute the following steps:

[0076] Step 2.1: Upon receiving the command buffer commit request sent by the Direct3D runtime, insert the current command buffer slot number K into the circular buffer, and at the same time notify the asynchronous thread that a new slot number is to be written, which can wake up the waiting asynchronous thread.

[0077] Step 2.2: Return the command buffer and submit the results to the Direct3D runtime;

[0078] Step 2.3: The main thread moves to the next command buffer slot K+1 and checks whether its command buffer submission is complete (marked by the asynchronous thread). If it is not complete, it waits for it to complete. If it is complete, the next command buffer is used as the current command buffer, and subsequent graphics rendering requests initiated by the Direct3D runtime are executed, writing commands into the current command buffer.

[0079] An asynchronous thread continuously checks if a new slot number has been written to the circular buffer and performs the following steps:

[0080] Step 3.1: If there is no new slot number, the process will be suspended and wait for the main thread to write a new slot number to the circular buffer before waking up; if there is a new slot number, the slot number (let's assume it's M) will be read.

[0081] Step 3.2: Retrieve the command set from command buffer M in the command buffer array according to the slot number M;

[0082] Step 3.3: Call the submission callback function provided by the Direct3D runtime to submit the command set in the command buffer M. At this time, the Direct3D runtime will switch from user mode to kernel mode.

[0083] Step 3.4, after the submission is completed, the Direct3D runtime switches to the user mode, the callback function returns the submission result of the successful submission, and the asynchronous thread marks the corresponding slot M as the state of the completed submission.

[0084] The main thread and the asynchronous thread each asynchronously execute the above steps until the application program exits.

[0085] In a possible implementation, the device for asynchronously submitting a command set can be implemented by an electronic device such as a terminal device and a server. The terminal device can be a user equipment (UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, or the like. The device can be implemented by a processor invoking computer-readable instructions stored in a memory.

[0086] In addition, the disclosure also provides a method for asynchronously submitting a command set, an electronic device, a computer-readable storage medium, and a program, which can be used to implement any of the devices for asynchronously submitting a command set provided by the disclosure. The corresponding technical solutions and descriptions are described in the method section and are not repeated here.

[0087] According to another aspect of the disclosure, a method for asynchronously submitting a command set is provided, which is applied to a device for asynchronously submitting a command set, the device including a main thread and an asynchronous thread, Figure 4 A flowchart of a method for asynchronously submitting a command set according to an embodiment of the disclosure is shown in FIG. 4. Figure 4 As shown in FIG. 4, the method includes the following steps.

[0088] In step S41, the main thread writes the identification of a current command buffer in a command buffer array into an identification storage area in response to a command set submission request of a graphic programming interface, and returns a response result of the command submission request to the graphic programming interface, the current command buffer being used to store commands currently being written by an application program.

[0089] In step S42, the asynchronous thread takes out a new identification in the identification storage area in the case that the new identification exists in the identification storage area, and performs a command set submission operation on a command buffer corresponding to the new identification.

[0090] In a possible implementation, the method further includes: in the case that a submission result of a next command buffer in the command buffer array is a completed submission, the main thread takes the next command buffer as the current command buffer.

[0091] In a possible implementation, the returning, by the graphics programming interface, of the response result of the command submission request to the main thread comprises: the main thread returning a command buffer submission result to the graphics programming interface after writing the identifier of the current command buffer in the command buffer array into the identifier storage area.

[0092] In a possible implementation, the performing, by the asynchronous thread, of the command set submission operation on the command buffer corresponding to the new identifier comprises:

[0093] The asynchronous thread determines the target command buffer corresponding to the new identifier taken from the identifier storage area from the command buffer array;

[0094] The command set in the target command buffer is submitted.

[0095] In a possible implementation, the performing, by the asynchronous thread, of the command set submission operation on the command buffer corresponding to the new identifier comprises:

[0096] The asynchronous thread calls a callback function provided by the graphics programming interface to perform the command set submission operation on the command buffer corresponding to the identifier;

[0097] The asynchronous thread receives a callback function result returned by the graphics programming interface to determine a submission result of the command set submission operation.

[0098] In a possible implementation, the method further comprises: the asynchronous thread determining a submission result of each command buffer and marking the submission result in the command buffer array.

[0099] In a possible implementation, the method further comprises: in a case where the identifier storage area has no new identifier, the asynchronous thread suspending and waiting for the main thread to write a new identifier into the identifier storage area.

[0100] In a possible implementation, the identifier storage area is a ring buffer.

[0101] The method has specific technical correlation with the internal structure of the computer system, and can solve the technical problem of how to improve the hardware operation efficiency or execution effect (including reducing data storage, reducing data transmission, improving hardware processing speed, etc.), thereby obtaining the technical effect of improving the internal performance of the computer system in line with the natural law.

[0102] In some embodiments, the apparatus provided by the embodiments of the present disclosure has functions or includes modules that can be used to execute the methods described in the above method embodiments, and the specific implementation can be referred to the description of the above method embodiments. For brevity, details are not repeated here.

[0103] The embodiment of the present disclosure further provides a computer readable storage medium, having stored thereon computer program instructions, which, when executed by a processor, implement the method described above. The computer readable storage medium can be a volatile or non-volatile computer readable storage medium.

[0104] The embodiment of the present disclosure further provides an electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to execute the method described above.

[0105] The embodiment of the present disclosure further provides a computer program product, comprising computer readable code, or a non-volatile computer readable storage medium carrying computer readable code, when the computer readable code is run in a processor of an electronic device, the processor in the electronic device executes the method described above.

[0106] The electronic device can be provided as a terminal, a server or other forms of devices.

[0107] Figure 5 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. For example, the electronic device 1900 can be provided as a server or a terminal device. Referring to Figure 5 , the electronic device 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932, for storing instructions executable by the processing component 1922, such as an application program. The application program stored in the memory 1932 can include one or more than one module each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute the instructions to perform the method described above.

[0108] The electronic device 1900 can further include a power supply component 1926 configured to perform power management of the electronic device 1900, a wired or wireless network interface 1950 configured to connect the electronic device 1900 to a network, and an input output interface 1958. The electronic device 1900 can operate based on an operating system stored in the memory 1932, such as Microsoft Windows Server TM , Apple's graphical user interface-based operating system (Mac OS X TM ), multi-user multi-process computer operating system (Unix TM ), free and open source Unix-like operating system (Linux TM ), open source Unix-like operating system (FreeBSD TM ) or the like.

[0109] In an example embodiment, a non-transitory computer-readable storage medium, e.g., memory 1932 including computer program instructions, is also provided, which can be executed by the processing component 1922 of the electronic device 1900 to complete the above method.

[0110] The present disclosure can be a system, a method, and / or a computer program product. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0111] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or punched tape, a

[0112] The computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0113] Computer readable program instructions for carrying out operations of the present disclosure can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0114] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0115] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can include random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other data storage device. When the computer readable program instructions are loaded into the computer and other programmable data processing apparatus, a series of operational steps are implemented that provide processes such that the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0116] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0117] The flow diagrams and the block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flow diagrams and the block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logic functions. In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and

[0118] The computer program product can be embodied in a tangible medium of

[0119] The above description of the various embodiments is intended to be illustrative in all aspects, rather than being restrictive. Those skilled in the art can refer to the description of the various embodiments to make modifications and / or improvements.

[0120] Those skilled in the art can understand that, in the above-described method of the specific embodiments, the writing order of each step does not mean a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible inherent logic.

[0121] If the technical solutions of the present application involve personal information, the product applying the technical solutions of the present application has been explicitly informed of the personal information processing rules before processing the personal information, and has obtained the personal independent consent. If the technical solutions of the present application involve sensitive personal information, the product applying the technical solutions of the present application has obtained the personal independent consent before processing the sensitive personal information, and at the same time meets the requirement of "explicit consent". For example, at the personal information collection device such as camera, a clear and prominent mark is set to inform that it has entered the personal information collection range and will collect personal information. If the individual voluntarily enters the collection range, it is considered to agree to collect personal information. Or on the device for processing personal information, through the pop-up information or by asking the individual to upload his personal information, the individual's authorization is obtained under the condition that the device uses obvious mark / information to inform the individual of the personal information processing rules. The personal information processing rules can include personal information processor, personal information processing purpose, processing method and personal information type, etc.

[0122] The above has described various embodiments of the present disclosure, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those skilled in the art without departing from the scope and spirit of the described embodiments. The choice of terms used herein is intended to best explain the principles, practical application or improvement of technology in the market of the embodiments, or to enable other ordinary skilled in the art to understand the embodiments disclosed herein.

Claims

1. An apparatus for asynchronously submitting a set of commands, characterized in that, Applied to user-mode driven UMD, including main thread and asynchronous thread, wherein: The main thread responds to the command set submission request of the graphics programming interface by writing the identifier of the current command buffer in the command buffer array into the identifier storage area, and returns the response result of the command submission request to the graphics programming interface without waiting for the command set submission to be completed, so that the graphics programming interface can continue to write commands to the next command buffer based on the response result. The current command buffer is used to store the commands that the application is currently writing. If a new identifier is added to the identifier storage area, the asynchronous thread retrieves the new identifier and performs a command set commit operation on the command buffer corresponding to the new identifier.

2. The apparatus according to claim 1, characterized in that, If the main thread finds that the submission result of the next command buffer in the command buffer array is "submission complete", then the next command buffer will be used as the current command buffer.

3. The apparatus according to claim 1, characterized in that, After writing the identifier of the current command buffer in the command buffer array to the identifier storage area, the main thread returns the command buffer to submit the result to the graphical programming interface.

4. The apparatus according to claim 1, characterized in that: The asynchronous thread determines the corresponding target command buffer from the command buffer array based on the newly added identifier retrieved from the identifier storage area. Submit the command set in the target command buffer.

5. The apparatus according to claim 1, characterized in that: The asynchronous thread calls the callback function provided by the graphics programming interface to perform a command set submission operation on the command buffer corresponding to the identifier; The asynchronous thread receives the callback function result returned by the graphics programming interface and determines the submission result of the command set submission operation.

6. The apparatus according to claim 1, characterized in that, The asynchronous thread determines the submission result for each command buffer and marks the submission result in the command buffer array.

7. The apparatus according to claim 1, characterized in that: If no new identifier is added to the identifier storage area, the asynchronous thread is suspended and waits for the main thread to write the new identifier to the identifier storage area.

8. The apparatus according to claim 1, characterized in that, The identifier storage area is a circular buffer.

9. A method for asynchronously submitting a set of commands, characterized in that, An apparatus for asynchronously submitting command sets, the apparatus comprising a main thread and an asynchronous thread, the method comprising: The main thread responds to the command set submission request of the graphics programming interface by writing the identifier of the current command buffer in the command buffer array into the identifier storage area, and returns the response result of the command submission request to the graphics programming interface without waiting for the command set submission to be completed, so that the graphics programming interface can continue to write commands to the next command buffer based on the response result. The current command buffer is used to store the commands that the application is currently writing. If a new identifier is added to the identifier storage area, the asynchronous thread retrieves the new identifier and performs a command set commit operation on the command buffer corresponding to the new identifier.

10. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to implement the method of claim 9.

11. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method of claim 9.

Images