Task processing method, computing device and storage medium
By introducing a driver manager into the computing device and using a function pointer table to query and pass call requests, the driver compatibility and switching problems in multi-GPU computing devices are solved, and flexible driver management and resource optimization are achieved.
Patent Information
- Application Number
- CN202510667820.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-22
- Publication Date
- 2025-09-19
AI Technical Summary
In the prior art, it is difficult to effectively make drivers for different graphics processors compatible and switchable in computing devices with multiple graphics processors, resulting in high system complexity, resource waste, and compatibility issues.
A driver manager is introduced as an intermediate layer to intercept the call request of the target program through the target dynamic library, and use the function pointer table to query and pass the call request to the corresponding driver, thereby realizing the intelligent selection and loading of the graphics processor driver.
The system can flexibly load, unload and switch different graphics processor drivers in a multi-graphics processor computing device, thereby improving the system's compatibility and resource utilization efficiency.
Smart Images

Figure CN120672559A_ABST
Abstract
Description
Technical Field
[0001] This specification relates to the field of computer technology, specifically, to driver management technology in the field of computer technology, and more specifically, to a task processing method, computing device, and storage medium. Background Art
[0002] A graphics processing unit (GPU) is a specialized hardware component for graphics rendering and computing. Originally designed to accelerate computer graphics rendering tasks, GPUs have also played a significant role in general computing as technology has evolved. A GPU driver is a software component that bridges the gap between the operating system and user programs and the GPU hardware, fulfilling communication and collaboration requirements. Therefore, the GPU driver plays a crucial role in the GPU's operation, and ensuring its proper functioning during task processing is crucial. Summary of the Invention
[0003] The embodiments of this specification provide a task processing method, a computing device, and a storage medium to achieve the purpose of ensuring the normal operation of a graphics processor driver during task processing in a computing device including multiple graphics processors.
[0004] To achieve the above technical objectives, the embodiments of this specification provide the following technical solutions:
[0005] In a first aspect, a task processing method is provided, which is applied to a computing device, the computing device including a central processing unit (CPU) and a graphics processing unit (GPU), the CPU being used for a driver manager, the driver manager including a target dynamic library pre-loaded in a target program; the task processing method comprising:
[0006] In response to a call request for the graphics rendering unit initiated by the target program, executing a call process of the graphics processor;
[0007] The calling process includes:
[0008] calling the target dynamic library to intercept the call request, querying the function pointer table using the call request if a function pointer table has been initialized, passing the call request to a driver corresponding to the call request based on the query result, and returning an execution result to the target program; the function pointer table including a pointer to an interface function of a driver of a graphics processor currently loaded on the computing device;
[0009] When the computing device starts or switches the driver of the graphics processor, the driver manager initializes the function pointer table to fill the function pointer table with pointers to interface functions of the driver of the graphics processor that need to be loaded.
[0010] In a second aspect, a computing device is provided, comprising: a central processing unit and a graphics processing unit, wherein the central processing unit is configured to run a driver manager, wherein the driver manager comprises: a target dynamic library, wherein the target dynamic library is pre-loaded in a target program;
[0011] The central processing unit is configured to:
[0012] In response to a call request for the graphics rendering unit initiated by the target program, executing a call process of the graphics processor;
[0013] The calling process includes:
[0014] calling the target dynamic library to intercept the call request, querying the function pointer table using the call request if a function pointer table has been initialized, passing the call request to a driver corresponding to the call request based on the query result, and returning an execution result to the target program; the function pointer table including a pointer to an interface function of a driver of a graphics processor currently loaded on the computing device;
[0015] When the computing device starts or switches the driver of the graphics processor, the driver manager initializes the function pointer table to fill the function pointer table with pointers to interface functions of the driver of the graphics processor that need to be loaded.
[0016] Optionally, the initialization process of the function pointer table includes:
[0017] When the computing device includes a plurality of the graphics processors, selecting a target graphics processor; the target graphics processor includes a graphics processor that the computing device needs to load;
[0018] Determining a target driver according to a first configuration file and the target graphics processor, wherein the target driver includes a driver that needs to be switched; the first configuration file is used to describe a determination rule for the target driver;
[0019] The target driver is loaded, the interface function of the target driver is searched, and the pointer pointing to the interface function of the target driver is filled into the function pointer table.
[0020] Optionally, the calling module determines, based on the first configuration file and the target graphics processor, that the target driver is specifically used for:
[0021] Obtaining identity parameters of a current graphics processor, where the current graphics processor includes a graphics processor currently used by the computing device, and the identity parameters include a model and a type;
[0022] The first configuration file is queried according to the identity parameters of the current graphics processor and the target graphics processor to determine the target driver.
[0023] Optionally, the central processing unit loads the target driver and searches for an interface function of the target driver for:
[0024] Dynamically loading the program library of the target driver through a loading function;
[0025] The search function pointer of the program library of the target driver is obtained through the pointer function, and the interface function of the target driver is searched from the program library of the target driver using the search function pointer.
[0026] Optionally, the central processing unit selects a target graphics processor specifically for:
[0027] When a graphics processor specified by the user exists, selecting the graphics processor specified by the user as the target graphics processor;
[0028] When there is no graphics processor specified by the user, the graphics processor pointed to by the first target path is selected as the target graphics processor.
[0029] Optionally, the central processing unit is further configured to run an operating system; and before selecting a target graphics processor, the central processing unit is further configured to:
[0030] Traverse the second target path of the operating system to determine whether the computing device has multiple graphics processors. If so, perform the step of selecting a target graphics processor.
[0031] Optionally, the central processing unit queries the function pointer table using the call request, transmits the call request to a driver corresponding to the call request according to the query result, and returns an execution result to the target program.
[0032] querying the function pointer table using the call request to determine whether a target pointer exists in the function pointer table, the target pointer pointing to an interface function of the graphics processor driver targeted by the call request; if not, returning an execution result including exception information to the target program, the exception information indicating that the call request is not supported;
[0033] If so, the call request is passed to the interface function pointed to by the target pointer to instruct the graphics processor driver to execute the operation instruction targeted by the call request and return the operation result to the driver manager. After receiving the operation result, the driver manager returns the execution result including the operation result to the target program.
[0034] Optionally, the graphics processor driver includes at least one of an open source driver based on a target open source graphics library, a driver of a first target manufacturer based on the target open source graphics library, and a closed source driver of a second target manufacturer.
[0035] According to a third aspect, a computer-readable storage medium is provided, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the task processing method described above is implemented.
[0036] In a fourth aspect, a computer program product or computer program is provided, the computer program product comprising a computer program stored in a computer-readable storage medium; a processor of a computer device reads the computer program from the computer-readable storage medium, and when the processor executes the computer program, implements the steps of the task processing method described above. Optionally, the computer program may be stored in a computer-readable storage medium or in the cloud; the processor of the computer device reads the computer program from the computer-readable storage medium or in the cloud.
[0037] As can be seen from the above technical solution, the task processing method provided in the embodiments of this specification is implemented based on a computing device including a central processing unit and a graphics processing unit, wherein the central processing unit is used to run a driver manager, and the driver manager includes: a target dynamic library, which is pre-loaded in the target program. In this way, when the target program initiates a call request for the graphics rendering unit, the target dynamic library can be called to intercept the call request. If the function pointer table has been initialized, the call request is used to query the function pointer table. According to the query result, the call request is passed to the driver corresponding to the call request, and the execution result is returned to the target program. When the computing device starts or switches the driver of the graphics processor, the driver manager initializes the function pointer table to fill the function pointer table with pointers to the interface functions of the driver of the graphics processor to be loaded. Through the above mechanism, when there are multiple graphics processors in the computing device, the switching requirements between the drivers of different graphics processors can be met, and the purpose of ensuring the normal operation of the graphics processor driver during task processing in a computing device containing multiple graphics processors is achieved. At the same time, the task processing method can also support the calling requirements of the graphics processor when there is only one graphics processor in the computing device, and support the calling requirements of the graphics processor when the central processing unit is used as a virtual graphics processor in the computing device. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] In order to more clearly illustrate the implementation methods of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the implementation methods or the description of the prior art. Obviously, the drawings described below are only the implementation methods of this specification. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.
[0039] Figure 1 A flowchart of a task processing method provided for one embodiment of this specification;
[0040] Figure 2 A schematic diagram of a framework of a task processing method provided for one embodiment of this specification;
[0041] Figure 3 A schematic diagram of a feasible execution process of a task processing method provided in one embodiment of this specification;
[0042] Figure 4 A schematic diagram of the structure of a computing device provided for one embodiment of this specification. DETAILED DESCRIPTION
[0043] Unless otherwise defined, technical or scientific terms used in this specification should have the same ordinary meaning as those understood by persons of ordinary skill in the art to which this specification pertains. The terms "first," "second," and similar terms used in this specification do not denote any order, quantity, or importance, but are provided solely to avoid confusion between constituent elements.
[0044] Unless the context requires otherwise, throughout this specification, the term "plurality" means "at least two," and "including" is to be interpreted as open and inclusive, meaning "including, but not limited to." Throughout this specification, terms such as "one embodiment," "some embodiments," "exemplary embodiments," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with the embodiment or example is included in at least one embodiment or example of this specification. The schematic representations of these terms do not necessarily refer to the same embodiment or example.
[0045] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this specification.
[0046] First, it should be noted that spatially relative terms, such as "front" and "back," are intended to refer to the first and second opposing surfaces of a device or component. The "front" and "back" expressions are used here to accommodate the orientation of the drawings and facilitate description. When the orientation of the drawings changes, spatially relative terms should be interpreted accordingly. For example, if a device or component in a drawing is flipped, "front" should be read as "back."
[0047] Overview
[0048] In servers, data centers, and workstations used for complex graphic design and video editing tasks, multiple graphics processors can be set up to work together. With the continuous development of graphics processor technology, multi-graphics processor designs have also appeared in personal home desktops and mobile terminals. Among the multiple graphics processors, there may be graphics processors from different manufacturers, and the drivers adapted to these graphics processors may also be different. In related technologies, if there are multiple graphics processors in a computing device, in order to be compatible with the switching requirements of different types of graphics processors, a customized operating system usually needs to be installed in the computing device. When the graphics processor needs to be switched, the corresponding customized operating system needs to be loaded accordingly, thereby achieving the purpose of loading the corresponding graphics processor driver during the startup process of the customized operating system.
[0049] While this approach enables compatibility between multiple GPUs within the same computing device, it requires customized operating system development for different GPU models, requiring significant manpower and time. Furthermore, with the emergence of new GPUs, the customized operating system may need to be redeveloped, increasing the complexity and maintenance difficulty of the system. Furthermore, this solution requires the computing device to store multiple image files for different GPUs, resulting in a waste of computing device storage resources. Users may also face compatibility issues when upgrading or replacing devices.
[0050] To solve this problem, the inventors proposed a computing device architecture and provided a task processing method based on the architecture. Specifically, the computing device includes a central processing unit (CPU) and a graphics processing unit (GPU), wherein the CPU is used to run a driver manager, wherein the driver manager includes a target dynamic library pre-loaded in a target program; that is, a driver manager is added to the operating system of the computing device, wherein the target dynamic library of the driver manager is pre-loaded in the target program. In this way, based on the target dynamic library, call requests for a graphics rendering unit initiated by the target program can be intercepted. After intercepting the call request, if the function pointer table has been initialized, the call request is used to query the function pointer table, and the call request is passed to the driver corresponding to the call request based on the query result, and the execution result is returned to the target program; the function pointer table includes a pointer to the interface function of the driver of the graphics processor currently loaded by the computing device; when the computing device starts or switches the driver of the graphics processor, the driver manager initializes the function pointer table to fill the function pointer table with pointers to the interface functions of the driver of the graphics processor to be loaded. In this way, by introducing the driver manager as an intermediate layer, the call request for the graphics rendering unit initiated by the target program is intercepted and forwarded, the graphics rendering unit is separated from the specific driver of the graphics processor, and the intelligent selection and loading of the driver of the graphics processor is realized through the initialization process of the function pointer table, thereby making it possible for the system to flexibly load, unload and switch the drivers of different graphics processors based on the driver manager. In general, the above mechanism can meet the switching requirements between the drivers of different graphics processors when there are multiple graphics processors in the computing device, and achieve the purpose of ensuring the normal operation of the driver of the graphics processor during the task processing process in the computing device containing multiple graphics processors. At the same time, the task processing method can also support the calling requirements of the graphics processor when there is only one graphics processor in the computing device, and support the calling requirements of the graphics processor when the central processing unit is used to simulate the graphics processor in the computing device.
[0051] Based on the above concept, an embodiment of this specification provides a task processing method. The task processing method provided in the embodiment of this specification will be exemplarily described below with reference to the accompanying drawings.
[0052] Exemplary Methods
[0053] Taking the application in computing equipment as an example, the embodiment of this specification provides a task processing method, such as Figure 1As shown, the computing device 10 includes a central processing unit 11 and a graphics processing unit 12. The central processing unit 11 is used to run a driver manager. The driver manager includes: a target dynamic library, which is pre-loaded in a target program. Optionally, the target program includes at least one of a system framework and a graphics program. The task processing method includes:
[0054] In response to a call request for the graphics rendering unit initiated by the target program, executing a call process of the graphics processor 12;
[0055] The calling process includes:
[0056] calling the target dynamic library to intercept the call request, querying the function pointer table using the call request if the function pointer table has been initialized, passing the call request to a driver corresponding to the call request based on the query result, and returning an execution result to the target program; the function pointer table includes a pointer to an interface function of the driver of the image processor currently loaded by the computing device 10;
[0057] When the computing device 10 starts or switches the driver of the graphics processor 12, the driver manager initializes the function pointer table to fill the function pointer table with pointers to interface functions of the driver of the graphics processor 12 that need to be loaded.
[0058] In the computing device 10, there can be one or more central processing units (CPUs) 11, and accordingly, there can be one or more graphics processing units (GPUs) 12. In one embodiment, the CPU can also function as a graphics rendering unit, which includes a graphics environment manager (GEM) and a graphics rendering engine. The GEM is used to initialize and manage the graphics environment, and the graphics rendering engine is used to execute target tasks within the graphics environment. The CPU can also function to run an operating system, which provides an operating environment for the graphics rendering unit and the driver manager. Within the graphics rendering unit, the GEM can initialize and manage the graphics environment, providing the graphics rendering engine with an execution environment for target tasks. The graphics rendering engine can execute target tasks within the graphics environment, which may include graphics rendering tasks, etc. For example, in some embodiments, the graphics rendering engine can provide a foundation for executing target tasks by providing interface functions. Optionally, the GEM can include EGL (Embedded Graphics Library), and the graphics rendering engine can include OpenGL ES (or OpenGL for Embedded Systems). EGL is an intermediate interface layer between OpenGL ES components and the local window management system. Introducing EGL can mask the differences between windows on different platforms. OpenGL ES is a lightweight 3D graphics API designed for embedded devices such as smartphones and tablets. It is a subset of OpenGL that removes some complex and redundant features of the desktop version to adapt to the hardware limitations and performance requirements of embedded devices.
[0059] A dynamic library (DLL) can be a file containing shareable code and resources. Specifically, in this embodiment, the target dynamic library can provide a common API (Application Programming Interface) interface for the graphics environment manager and graphics rendering engine to intercept call requests to the graphics environment manager or graphics rendering engine. When the computing device 10 runs on the OpenHarmony operating system, the target dynamic library can provide a common API interface for the graphics environment manager and graphics rendering engine defined by the Khronos organization.
[0060] Based on the unified interface provided by the target dynamic library, the driver manager can implement a call request for the graphics rendering unit initiated by the target program. Before passing the call request to the specific driver, it first determines whether the function pointer table has been initialized. If it has been initialized, it can be considered that the computing device 10 has loaded the correct driver for the graphics processor 12, and the call request can be passed to the driver to execute subsequent actions. If the function pointer table is not initialized, the function pointer table initialization process can be executed to fill the function pointer table with a pointer to the interface function of the driver for the graphics processor 12 to be loaded, thereby correctly loading the required driver and meeting the switching requirements of the drivers for different graphics processors 12.
[0061] The task processing method provided in the embodiments of this specification is particularly suitable for computing devices 10 based on the OpenHarmony operating system. The OpenHarmony operating system is an open source project incubated and operated by the Open Atom Foundation. Its goal is to build a framework and platform for the operating system of intelligent terminal devices based on an open source approach in the era of full scenarios, full connectivity, and full intelligence, and to promote the prosperity and development of the Internet of Things industry. However, due to the relatively late birth of the OpenHarmony operating system, the OpenHarmony operating system has poor compatibility with third-party applications, and its technology stack is not very mature and complete in the technical branch of driver compatibility of multiple graphics processors 12. Therefore, when different graphics processor 12 hardware is used in a computing device 10 equipped with the OpenHarmony operating system, the computing device 10 has no way to well meet the switching requirements between the drivers of different graphics processors 12. In particular, as the types of graphics processors 12 continue to increase, the types of drivers for graphics processors 12 have also increased, and there is an urgent need for the computing device 10 to achieve compatibility with the drivers of different graphics processors 12 in a single operating system.
[0062] Therefore, in this embodiment, in order to meet the switching requirements of different drivers of a computing device 10 including multiple graphics processors 12 and ensure the normal operation of the computing device 10, a driver manager is added to the operating system of the computing device 10. The target dynamic library of the driver manager is pre-loaded in the target program. In this way, based on the target dynamic library, call requests for the graphics rendering unit initiated by the target program can be intercepted. After the call request is intercepted, if the function pointer table has been initialized, the call request is used to query the function pointer table, and the call request is passed to the driver corresponding to the call request based on the query result, and the execution result is returned to the target program; the function pointer table includes a pointer to the interface function of the driver of the graphics processor currently loaded by the computing device 10; when the computing device 10 starts or switches the driver of the graphics processor 12, the driver manager initializes the function pointer table to fill the function pointer table with pointers to the interface functions of the driver of the graphics processor 12 to be loaded. In this way, by introducing the driver manager as an intermediate layer, the call request for the graphics rendering unit initiated by the target program is intercepted and forwarded, the graphics rendering unit is separated from the specific driver of the graphics processor 12, and the driver of the graphics processor 12 is intelligently selected and loaded through the initialization process of the function pointer table, thereby making it possible for the system to flexibly load, unload, and switch the drivers of different graphics processors 12 based on the driver manager. In general, the above mechanism can meet the switching requirements between the drivers of different graphics processors 12 when there are multiple graphics processors 12 in the computing device 10, and achieve the purpose of ensuring the normal operation of the driver of the graphics processor 12 during the task processing process in the computing device 10 containing multiple graphics processors 12. At the same time, the task processing method can also support the calling requirements of the graphics processor 12 when there is only one graphics processor 12 in the computing device 10, and support the calling requirements of the graphics processor 12 when the central processing unit 11 in the computing device 10 simulates the graphics processor 12.
[0063] In one embodiment, a feasible method for initializing a function pointer table is provided, and the initialization process of the function pointer table includes:
[0064] When the computing device 10 includes a plurality of the graphics processors 12, a target graphics processor 12 is selected; the target graphics processor 12 includes the graphics processor 12 that the computing device 10 needs to load;
[0065] Determine a target driver according to a first configuration file and the target graphics processor 12, wherein the target driver includes a driver that needs to be switched; the first configuration file is used to describe a determination rule for the target driver;
[0066] The target driver is loaded, the interface function of the target driver is searched, and the pointer pointing to the interface function of the target driver is filled into the function pointer table.
[0067] In one embodiment, the first configuration file may include a target driver determination rule. By querying the first configuration file based on the current state of computing device 10, it is possible to determine whether to load an open source driver based on a target open source graphics library, a driver based on the target open source graphics library from a first target manufacturer, or a closed-source driver from a second target manufacturer. The target library may be the Mesa3D graphics library. Through this process, the target driver can be accurately loaded, meeting the switching requirements of different driver types.
[0068] In one embodiment, determining the target driver according to the first configuration file and the target graphics processor 12 includes:
[0069] Obtaining identity parameters of a current graphics processor 12, where the current graphics processor 12 includes the graphics processor 12 currently used by the computing device 10, and the identity parameters include a model and a type;
[0070] The first configuration file is queried according to the identity parameters of the current graphics processor 12 and the target graphics processor 12 to determine the target driver.
[0071] In one embodiment, for a computing device 10 running the OpenHarmony operating system, obtaining the identity parameters of the current graphics processor 12 can be accomplished by querying the model and type of the graphics processor 12 via libdrm-related interfaces to obtain the identity parameters of the graphics processor 12 currently used by the computing device 10. In this embodiment, the first configuration file may include a correspondence between the identity parameters of the current graphics processor 12, the target graphics processor 12, and the driver, thereby satisfying the requirement for determining the target driver by querying the first configuration file. By combining the identity parameters of the current graphics processor 12 and the target graphics processor 12, the target driver can be accurately determined.
[0072] In one embodiment, the loading of the target driver and searching for the interface function of the target driver include:
[0073] Dynamically loading the program library of the target driver through a loading function;
[0074] The search function pointer of the program library of the target driver is obtained through the pointer function, and the interface function of the target driver is searched from the program library of the target driver using the search function pointer.
[0075] The load function may refer to a program library that loads the target driver, the pointer function may refer to a function that includes a search function pointer for searching the program library for the target driver, and the search function pointer may refer to a pointer that includes the function of searching the interface function of the target driver. Still taking the computing device 10 equipped with the OpenHarmony operating system as an example, the load function may include the dlopen function, the pointer function may include the dlsym function, and the search function pointer may include the eglGetProcessAddress function pointer. After loading the program library for the target driver and obtaining the search function pointer, the search function pointer may be used to search the program library for the target driver's interface function, which may include an API function.
[0076] In one embodiment, the selected target graphics processor 12 includes:
[0077] When there is a graphics processor 12 specified by the user, selecting the graphics processor 12 specified by the user as the target graphics processor 12;
[0078] When there is no graphics processor 12 specified by the user, the graphics processor 12 pointed to by the first target path is selected as the target graphics processor 12 .
[0079] The user can specify the graphics processor 12 through a configuration file or environment variable, satisfying the user's need to independently select the graphics processor 12 to be used. In addition, if the user does not specify a graphics processor 12, the computing device 10 can use the graphics processor 12 pointed to by the first target path as the target graphics processor 12. The first target path can be a default path or a path automatically adjusted by the computing device 10 based on the load status of each graphics processor 12. This specification does not limit this.
[0080] Still taking the computing device 10 equipped with the OpenHarmony operating system as an example, when the user does not specify the graphics processor 12, the graphics processor 12 pointed to by the / dev / dri / Render128 path can be used as the target graphics processor 12.
[0081] In one embodiment, before selecting the target graphics processor 12, the method further includes:
[0082] Traversing the second target path of the operating system to determine whether the computing device 10 has multiple graphics processors 12, and if so, executing the step of selecting a target graphics processor 12;
[0083] If not, the step of determining a target driver according to the first configuration file and the target graphics processor 12 is performed. In this case, the target graphics processor 12 may be the only graphics processor 12 in the computing device 10 .
[0084] In one embodiment, the second target path may be a parent path of the first target path. Taking a computing device 10 equipped with an OpenHarmony operating system as an example, feasible implementations for determining whether the computing device 10 has multiple graphics processors 12 may include:
[0085] The number of renderD* series nodes under / dev / dri is traversed, and based on the number of traversed nodes, whether there are multiple GPUs 12 is determined. For example, if there is only one node, renderD128, under the second target path, then there is only one GPU 12; if there are three nodes, renderD128, renderD129, and renderD130, under the second target path, then there are three GPUs 12 in the computing device 10; and so on. By traversing the number of renderD* series nodes under the second target path, the purpose of determining whether there are multiple GPUs 12 in the computing device 10 can be achieved.
[0086] One embodiment of the present specification provides a feasible execution method when a function pointer table has been initialized. Specifically, querying the function pointer table using the call request, passing the call request to a driver corresponding to the call request according to the query result, and returning the execution result to the target program includes:
[0087] querying the function pointer table using the call request to determine whether a target pointer exists in the function pointer table, the target pointer pointing to an interface function of the driver of the graphics processor 12 targeted by the call request; if not, returning an execution result including exception information to the target program, the exception information being used to indicate that the call request is not supported;
[0088] If so, the call request is passed to the interface function pointed to by the target pointer to instruct the driver of the graphics processor 12 to execute the operation instruction targeted by the call request and return the operation result to the driver manager. After receiving the operation result, the driver manager returns the execution result including the operation result to the target program.
[0089] When the target pointer does not exist in the function pointer table, an execution result including exception information may be returned to the target program to inform the user that the current call request is not supported.
[0090] If a target pointer exists in the function pointer table, a call request can be passed to the interface function pointed to by the target pointer. This interface function ultimately implements the API operation instructions of the graphics rendering unit, which can be completed by a specific driver provided by the graphics processor 12 vendor. After completing the specific operation, the graphics processor 12 driver returns the operation result to the driver manager. The driver manager returns an execution result containing the operation result to the target program as a response to the call request.
[0091] In an optional embodiment, when the target program is a system framework, the call request may include a request for a graphics environment manager, and may also include a request for a graphics rendering engine; when the target program includes a graphics program, the call request may include a request for the graphics rendering engine.
[0092] In one embodiment, the system framework may be defined as the portion of the operating system that provides core APIs and services to support the development and operation of applications. A graphics program may refer to an application running in the operating system that requires the graphics processor 12 to call, such as a program capable of generating, processing, or displaying graphical content. This includes, but is not limited to, games, graphic design software, image editing tools, video players, and the like.
[0093] As described above, the driver of the graphics processor 12 may include at least one of: an open source driver based on a target open source graphics library, a driver of a first target manufacturer based on the target open source graphics library, and a closed source driver of a second target manufacturer. Among them, the target open source graphics library may include a Mesa3D graphics library, and the open source driver based on the target open source graphics library may be a universal driver. The driver of the first target manufacturer based on the target open source graphics library may be a graphics processor 12 driver of a specific manufacturer, and these drivers may not be able to be upgraded to an open source driver based on the target open source graphics library due to various reasons. The closed source driver of the second target manufacturer may be a closed source driver developed by a specific manufacturer for its graphics processor 12 product. When the driver of the graphics processor 12 includes the above three types of drivers, it can meet the driving requirements of most graphics processors 12, thereby improving the applicability of the task processing method.
[0094] In a specific embodiment of this specification, a feasible processing process of a task processing method is provided, such as Figure 2 and Figure 3 As shown, Figure 2The overall framework of the task processing method is shown. Figure 3 Specific feasible steps are shown.
[0095] refer to Figure 2 , the driver manager acts as an intermediate layer, intercepting the call request for the graphics rendering unit initiated by the target program, processing it and passing it to a specific driver (open source Meas3D driver, specific Mesa3D driver or closed source driver), and the driver operates the specific graphics processor 12 through DRM / KMS. Among them, DRM (Direct Rendering Manager) is part of the Linux kernel, responsible for managing the hardware resources of the graphics processor 12 and providing access control and resource management functions for the graphics processor 12. KMS (Kernel Mode Setting) is a submodule of DRM, focusing on the setting and management of graphics mode.
[0096] refer to Figure 3 , the execution process of the task processing method includes:
[0097] S1, operating system startup;
[0098] S2. The target program (system framework or graphics program) links to the target dynamic library;
[0099] S3, the target program requests to call the graphics rendering unit;
[0100] S4. The driver manager intercepts these call requests through the target dynamic library;
[0101] S5. Determine whether the function pointer table is initialized. If so, proceed to step S12; if not, proceed to step S6.
[0102] S6. Determine whether there are multiple graphics processors 12 in the computing device 10. For example, by traversing the renderD* series nodes under / dev / dri, determine whether there are multiple graphics processors 12. If yes, proceed to step S7; if no, proceed to step S8.
[0103] S7. Selecting a target GPU 12: If the user does not specify a specific GPU 12 from among the multiple GPUs 12 as the target GPU 12 through a configuration file or environment variable, the GPU 12 pointed to by / dev / dri / Render128 may be used as the target GPU 12; if the user specifies a specific GPU 12 from among the multiple GPUs 12, the specified GPU 12 may be used as the target GPU 12;
[0104] S8. Determine the target driver: Determine the target driver according to the first configuration file and the target graphics processor 12;
[0105] S9. Dynamically loading the program library of the target driver through a loading function: the driver manager can dynamically load the program library of the target driver through a dlopen function;
[0106] S10, obtaining the search function pointer of the program library of the target driver through the pointer function; the driver manager can obtain the eglGetProcessAddress function pointer of the loaded dynamic library through dlsym;
[0107] S11, using the search function pointer to search for the interface function of the target driver from the program library of the target driver; the driver manager can use the eglGetProcessAddress function pointer to search for the GLES / EGL API function from the dynamic library loaded by dlopen, and fill the function pointer table. After the function pointer table is filled, the process can jump to step S12 to continue execution;
[0108] S12, determine whether the target pointer exists in the function pointer table, if not, execute step S13, if yes, execute step S14;
[0109] S13. Return the execution result including the exception information;
[0110] S14, passing the call request to the interface function pointed to by the target pointer;
[0111] S15, the driver of the graphics processor 12 executes the operation instruction targeted by the call request and returns the operation result to the driver manager;
[0112] S16. After receiving the operation result, the driver manager returns the execution result including the operation result to the target program.
[0113] Exemplary devices
[0114] In an exemplary embodiment of the present specification, a task processing apparatus is provided, which is applied to a computing device 10. The computing device 10 includes a central processing unit 11 and a graphics processing unit 12. The central processing unit 11 is used to run a driver manager. The driver manager includes: a target dynamic library, which is pre-loaded in a target program; the task processing apparatus includes:
[0115] a calling module, configured to execute a calling process of the graphics processor 12 in response to a calling request for the graphics rendering unit initiated by the target program;
[0116] The calling process includes:
[0117] calling the target dynamic library to intercept the call request, querying the function pointer table using the call request if the function pointer table has been initialized, passing the call request to a driver corresponding to the call request based on the query result, and returning an execution result to the target program; the function pointer table includes a pointer to an interface function of the driver of the image processor currently loaded by the computing device 10;
[0118] When the computing device 10 starts or switches the driver of the graphics processor 12, the driver manager initializes the function pointer table to fill the function pointer table with pointers to interface functions of the driver of the graphics processor 12 that need to be loaded.
[0119] Optionally, the initialization process of the function pointer table includes:
[0120] When the computing device 10 includes a plurality of graphics processors 12, a target graphics processor 12 is selected; the target graphics processor 12 includes the graphics processor 12 that the computing device 10 needs to load;
[0121] Determine a target driver according to a first configuration file and the target graphics processor 12, wherein the target driver includes a driver that needs to be switched; the first configuration file is used to describe a determination rule for the target driver;
[0122] The target driver is loaded, the interface function of the target driver is searched, and the pointer pointing to the interface function of the target driver is filled into the function pointer table.
[0123] Optionally, the calling module determines, based on the first configuration file and the target graphics processor 12, that the target driver is specifically used for:
[0124] Obtaining identity parameters of a current graphics processor 12, where the current graphics processor 12 includes the graphics processor 12 currently used by the computing device 10, and the identity parameters include a model and a type;
[0125] The first configuration file is queried according to the identity parameters of the current graphics processor 12 and the target graphics processor 12 to determine the target driver.
[0126] Optionally, the calling module loads the target driver and searches for an interface function of the target driver for:
[0127] Dynamically loading the program library of the target driver through a loading function;
[0128] The search function pointer of the program library of the target driver is obtained through the pointer function, and the interface function of the target driver is searched from the program library of the target driver using the search function pointer.
[0129] Optionally, the calling module selects the target graphics processor 12 to be specifically used for:
[0130] When there is a graphics processor 12 specified by the user, selecting the graphics processor 12 specified by the user as the target graphics processor 12;
[0131] When there is no graphics processor 12 specified by the user, the graphics processor 12 pointed to by the first target path is selected as the target graphics processor 12 .
[0132] Optionally, the central processing unit is further configured to run an operating system; and before the calling module selects the target graphics processor 12, it is further configured to:
[0133] The second target path of the operating system is traversed to determine whether the computing device 10 has multiple graphics processors 12 . If so, the step of selecting a target graphics processor 12 is performed.
[0134] Optionally, the calling module queries the function pointer table using the calling request, transmits the calling request to a driver corresponding to the calling request according to the query result, and returns an execution result to the target program.
[0135] querying the function pointer table using the call request to determine whether a target pointer exists in the function pointer table, the target pointer pointing to an interface function of the driver of the graphics processor 12 targeted by the call request; if not, returning an execution result including exception information to the target program, the exception information being used to indicate that the call request is not supported;
[0136] If so, the call request is passed to the interface function pointed to by the target pointer to instruct the driver of the graphics processor 12 to execute the operation instruction targeted by the call request and return the operation result to the driver manager. After receiving the operation result, the driver manager returns the execution result including the operation result to the target program.
[0137] Optionally, the driver of the graphics processor 12 includes at least one of an open source driver based on a target open source graphics library, a driver of a first target manufacturer based on the target open source graphics library, and a closed source driver of a second target manufacturer.
[0138] For the specific definition of the task processing device, please refer to the definition of the task processing method above, and will not be repeated here. The various modules in the above-mentioned task processing device can be implemented in whole or in part by software, hardware, or a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.
[0139] Exemplary Computing Devices
[0140] Another embodiment of this specification also provides a computing device 10, such as Figure 4 As shown, it includes: a central processing unit 11 and a graphics processing unit 12, the central processing unit 11 is used to run a driver manager, and the driver manager includes: a target dynamic library, and the target dynamic library is pre-loaded in the target program;
[0141] The central processing unit 11 is configured to:
[0142] In response to a call request for the graphics rendering unit initiated by the target program, executing a call process of the graphics processor 12;
[0143] The calling process includes:
[0144] calling the target dynamic library to intercept the call request, querying the function pointer table using the call request if the function pointer table has been initialized, passing the call request to a driver corresponding to the call request based on the query result, and returning an execution result to the target program; the function pointer table includes a pointer to an interface function of the driver of the image processor currently loaded by the computing device 10;
[0145] When the computing device 10 starts or switches the driver of the graphics processor 12, the driver manager initializes the function pointer table to fill the function pointer table with pointers to interface functions of the driver of the graphics processor 12 that need to be loaded.
[0146] Optionally, the initialization process of the function pointer table includes:
[0147] When the computing device 10 includes a plurality of the graphics processors 12, a target graphics processor 12 is selected; the target graphics processor 12 includes the graphics processor 12 that the computing device 10 needs to load;
[0148] Determine a target driver according to a first configuration file and the target graphics processor 12, wherein the target driver includes a driver that needs to be switched; the first configuration file is used to describe a determination rule for the target driver;
[0149] The target driver is loaded, the interface function of the target driver is searched, and the pointer pointing to the interface function of the target driver is filled into the function pointer table.
[0150] Optionally, the calling module determines, based on the first configuration file and the target graphics processor 12, that the target driver is specifically used for:
[0151] Obtaining identity parameters of a current graphics processor 12, where the current graphics processor 12 includes the graphics processor 12 currently used by the computing device 10, and the identity parameters include a model and a type;
[0152] The first configuration file is queried according to the identity parameters of the current graphics processor 12 and the target graphics processor 12 to determine the target driver.
[0153] Optionally, the central processing unit 11 loads the target driver and searches for an interface function of the target driver for:
[0154] Dynamically loading the program library of the target driver through a loading function;
[0155] The search function pointer of the program library of the target driver is obtained through the pointer function, and the interface function of the target driver is searched from the program library of the target driver using the search function pointer.
[0156] Optionally, the central processing unit 11 selects the target graphics processor 12 to:
[0157] When there is a graphics processor 12 specified by the user, selecting the graphics processor 12 specified by the user as the target graphics processor 12;
[0158] When there is no graphics processor 12 specified by the user, the graphics processor 12 pointed to by the first target path is selected as the target graphics processor 12 .
[0159] Optionally, the central processing unit is further configured to run an operating system; and before the central processing unit 11 selects a target graphics processor 12, it is further configured to:
[0160] The second target path of the operating system is traversed to determine whether the computing device 10 has multiple graphics processors 12 . If so, the step of selecting a target graphics processor 12 is performed.
[0161] Optionally, the central processing unit 11 queries the function pointer table using the call request, transmits the call request to a driver corresponding to the call request according to the query result, and returns an execution result to the target program. Specifically,
[0162] querying the function pointer table using the call request to determine whether a target pointer exists in the function pointer table, the target pointer pointing to an interface function of the driver of the graphics processor 12 targeted by the call request; if not, returning an execution result including exception information to the target program, the exception information being used to indicate that the call request is not supported;
[0163] If so, the call request is passed to the interface function pointed to by the target pointer to instruct the driver of the graphics processor 12 to execute the operation instruction targeted by the call request and return the operation result to the driver manager. After receiving the operation result, the driver manager returns the execution result including the operation result to the target program.
[0164] Optionally, the driver of the graphics processor 12 includes at least one of an open source driver based on a target open source graphics library, a driver of a first target manufacturer based on the target open source graphics library, and a closed source driver of a second target manufacturer.
[0165] Exemplary computer program products and storage media
[0166] In addition to the above-mentioned methods and devices, the task processing method provided in the embodiments of this specification may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the task processing method according to various embodiments of this specification described in the above-mentioned "Exemplary Method" section of this specification.
[0167] The computer program product may be implemented in hardware, software, or a combination thereof. In one embodiment, the computer program product is implemented as a computer storage medium. In another embodiment, the computer program product is implemented as a software product, such as a software development kit (SDK).
[0168] The computer program product may be written in any combination of one or more programming languages to implement the operations of the embodiments of this specification, including object-oriented programming languages such as Java, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's computing device, as a stand-alone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.
[0169] In addition, an embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and the computer program is used by a processor to execute the steps of the task processing method according to various embodiments of this specification described in the above "Exemplary Method" section of this specification.
[0170] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the various embodiments provided in this specification may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0171] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0172] The above-described embodiments merely represent several embodiments of this specification. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the solutions provided by the embodiments of this specification. It should be noted that a person skilled in the art can make several variations and improvements without departing from the concept of this specification, and these variations and improvements fall within the scope of protection of this specification. Therefore, the scope of protection of the patent in this specification shall be based on the appended claims.
Claims
1. A task processing method, characterized in that: The method is applied to a computing device, the computing device including a central processing unit and a graphics processing unit, the central processing unit being used for a driver manager, the driver manager including: a target dynamic library, the target dynamic library being pre-loaded in a target program; the task processing method including: In response to a call request for the graphics rendering unit initiated by the target program, executing a call process of the graphics processor; The calling process includes: calling the target dynamic library to intercept the call request, querying the function pointer table using the call request if a function pointer table has been initialized, passing the call request to a driver corresponding to the call request based on the query result, and returning an execution result to the target program; the function pointer table including a pointer to an interface function of a driver of a graphics processor currently loaded on the computing device; When the computing device starts or switches the driver of the graphics processor, the driver manager initializes the function pointer table to fill the function pointer table with pointers to interface functions of the driver of the graphics processor that need to be loaded.
2. The method according to claim 1, characterized in that The initialization process of the function pointer table includes: When the computing device includes a plurality of graphics processors, selecting a target graphics processor; the target graphics processor includes a graphics processor that the computing device needs to load; Determining a target driver according to a first configuration file and the target graphics processor, wherein the target driver includes a driver that needs to be switched; the first configuration file is used to describe a determination rule for the target driver; The target driver is loaded, the interface function of the target driver is searched, and the pointer pointing to the interface function of the target driver is filled into the function pointer table.
3. The method according to claim 2, characterized in that Determining the target driver according to the first configuration file and the target graphics processor includes: Obtaining identity parameters of a current graphics processor, where the current graphics processor includes a graphics processor currently used by the computing device, and the identity parameters include a model and a type; The first configuration file is queried according to the identity parameters of the current graphics processor and the target graphics processor to determine the target driver.
4. The method according to claim 2, characterized in that The step of loading the target driver and searching for an interface function of the target driver comprises: Dynamically loading the program library of the target driver through a loading function; The search function pointer of the program library of the target driver is obtained through the pointer function, and the interface function of the target driver is searched from the program library of the target driver using the search function pointer.
5. The method according to claim 2, characterized in that The selected target graphics processor includes: When a graphics processor specified by the user exists, selecting the graphics processor specified by the user as the target graphics processor; When there is no graphics processor specified by the user, the graphics processor pointed to by the first target path is selected as the target graphics processor.
6. The method according to claim 5, characterized in that The central processing unit is also used to run the operating system; Before selecting the target graphics processor, the method further includes: Traverse the second target path of the operating system to determine whether the computing device has multiple graphics processors. If so, perform the step of selecting a target graphics processor.
7. The method according to any one of claims 1 to 6, characterized in that The querying of the function pointer table using the call request, passing the call request to a driver corresponding to the call request according to the query result, and returning the execution result to the target program comprises: querying the function pointer table using the call request to determine whether a target pointer exists in the function pointer table, the target pointer pointing to an interface function of the graphics processor driver targeted by the call request; if not, returning an execution result including exception information to the target program, the exception information indicating that the call request is not supported; If so, the call request is passed to the interface function pointed to by the target pointer to instruct the graphics processor driver to execute the operation instruction targeted by the call request and return the operation result to the driver manager. After receiving the operation result, the driver manager returns the execution result including the operation result to the target program.
8. The method according to any one of claims 1 to 6, characterized in that The graphics processor driver includes at least one of an open source driver based on a target open source graphics library, a driver based on the target open source graphics library of a first target manufacturer, and a closed source driver of a second target manufacturer.
9. A computing device, characterized in that include: A central processing unit and a graphics processing unit, wherein the central processing unit is used to run a driver manager, wherein the driver manager includes: a target dynamic library, wherein the target dynamic library is pre-loaded in a target program; The central processing unit is configured to: In response to a call request for the graphics rendering unit initiated by the target program, executing a call process of the graphics processor; The calling process includes: calling the target dynamic library to intercept the call request, querying the function pointer table using the call request if a function pointer table has been initialized, passing the call request to a driver corresponding to the call request based on the query result, and returning an execution result to the target program; the function pointer table including a pointer to an interface function of a driver of a graphics processor currently loaded on the computing device; When the computing device starts or switches the driver of the graphics processor, the driver manager initializes the function pointer table to fill the function pointer table with pointers to interface functions of the driver of the graphics processor that need to be loaded.
10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by the processor, the task processing method according to any one of claims 1 to 8 is implemented.