Graph rendering method and device, computer equipment, readable storage medium and product

Abstract

The invention relates to a graph rendering method and device, computer equipment, a readable storage medium and a product. The method comprises the steps of calling an interface function driven by a first DRI in response to a graphic rendering request; wherein the first interface function is used for returning to a structural body, the structural body comprises a function pointer of a first DRI drive and a function pointer of a second DRI drive, and at least one function of the second DRI drive is different from the function of the first DRI drive; calling a first rendering function based on a function pointer driven by the first DRI; and in the process of processing the graphic rendering request through the first rendering function, if the graphic rendering request relates to a first function in the at least one function, calling a second rendering function based on a function pointer driven by a second DRI to perform graphic rendering. By adopting the method, the graphic rendering effect can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of graphics rendering, and particularly relates to a graphics rendering method and device, computer equipment, a readable storage medium and a product. BACKGROUND

[0002] Direct Rendering Infrastructure (DRI) is a mechanism that enables an application or a client to directly access a Graphics Processing Unit (GPU) for graphics rendering, and enables the application or the client to directly perform hardware acceleration, and is commonly used in X Window System and Wayland display servers.

[0003] In the related art, a GPU manufacturer usually has only one set of DRI driver. When developing the DRI driver, in order to meet the requirements, the GPU manufacturer may need to develop a brand-new DRI driver and discard the old DRI driver, so that the new DRI driver and the old DRI driver are independent of each other, and the new DRI driver usually cannot directly inherit or call the functions of the old DRI driver, which leads to incompatibility of the functions of the new and old DRI drivers, and thus there is a problem of poor rendering effect when the new DRI driver is used to process a rendering object that depends on the function of the old DRI driver. SUMMARY

[0004] Therefore, it is necessary to provide a graphics rendering method and device, computer equipment, a computer readable storage medium and a computer program product capable of improving the rendering effect.

[0005] In a first aspect, the present application provides a graphics rendering method, comprising: in response to a graphics rendering request, calling a first interface function of a first Direct Rendering Infrastructure (DRI) driver; wherein the first interface function is used to obtain a structure body, the structure body comprising a function pointer of the first DRI driver and a function pointer of a second DRI driver, at least one function of the second DRI driver being different from a function of the first DRI driver; calling a first rendering function based on the function pointer of the first DRI driver; in the process of processing the graphics rendering request by the first rendering function, if the graphics rendering request involves a first function in the at least one function, calling a second rendering function based on the function pointer of the second DRI driver to perform graphics rendering, the second rendering function being used to implement the first function.

[0006] In one of the embodiments, the method further comprises: obtaining a first structure returned by the first interface function in the first DRI driver; loading a library file of the second DRI driver in the first DRI driver, obtaining a second structure returned by a second interface function of the second DRI driver based on the library file; and extending the first structure based on the second structure to obtain the structure.

[0007] In one of the embodiments, the obtaining the first structure returned by the first interface function in the first DRI driver comprises: calling a first entry function of the first DRI driver to obtain a first interface function list of the first DRI driver; and calling the first interface function in the first interface function list to obtain the first structure.

[0008] In one of the embodiments, the obtaining the second structure returned by the second interface function of the second DRI driver based on the library file comprises: searching for a second entry function of the second DRI driver from the library file, and calling the second entry function to obtain a second interface function list of the second DRI driver; and calling the second interface function in the second interface function list to obtain the second structure.

[0009] In one of the embodiments, the extending the first structure based on the second structure to obtain the structure comprises: embedding a function pointer in the second structure into the first structure to obtain the structure.

[0010] In one of the embodiments, the method further comprises: determining a function to be executed in the process of processing the graphic rendering request by the first rendering function; if the function to be executed comprises a first function in the at least one function, predicting a computing resource required for calling the second rendering function to execute the first function; if the computing resource is less than or equal to a preset computing resource threshold, determining that the graphic rendering request involves the first function; and if the function to be executed does not comprise the first function or the computing resource is greater than the computing resource threshold, determining that the graphic rendering request does not involve the first function.

[0011] In one of the embodiments, the determining the function to be executed comprises: parsing the graphic rendering request to obtain a function parameter required for rendering; and determining the function to be executed according to the parsed function parameter.

[0012] In a second aspect, the application further provides a graphic rendering device, comprising:

[0013] The first calling module is used to call a first interface function of the first Direct Rendering Infrastructure (DRI) driver in response to a graphics rendering request; wherein the first interface function is used to return a structure, the structure including a function pointer of the first DRI driver and a function pointer of the second DRI driver, and at least one function of the second DRI driver is different from the function of the first DRI driver.

[0014] The second calling module is used to call the first rendering function based on the function pointer of the first DRI driver;

[0015] The third calling module is used to call the second rendering function based on the function pointer of the second DRI driver to perform graphics rendering when the graphics rendering request is processed by the first rendering function. If the graphics rendering request involves the first function among the at least one functions, the second rendering function is used to implement the first function.

[0016] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the graphics rendering method provided in the first aspect embodiment of this application.

[0017] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the graphics rendering method provided in the first aspect of the embodiment of this application.

[0018] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the graphics rendering method provided in the first aspect of the embodiment of this application.

[0019] The aforementioned graphics rendering method, apparatus, computer device, computer-readable storage medium, and computer program product, in response to a graphics rendering request, call a first interface function of a first DRI driver. The first interface function obtains a structure, which includes function pointers for the first DRI driver and a second DRI driver. At least one function of the second DRI driver differs from that of the first DRI driver. A first rendering function is called based on the function pointer of the first DRI driver. During the processing of the graphics rendering request through the first rendering function, if the graphics rendering request involves a first function among at least one of the functions, a second rendering function is called based on the function pointer of the second DRI driver to perform graphics rendering. The second rendering function is used to implement the first function. This application embodiment can call rendering functions of at least two DRI drivers through a structure, achieving rendering based on at least two DRI drivers, compatible with different functions, and avoiding functional loss or rendering quality degradation due to DRI driver upgrades. When a new DRI driver has a specific functional loss, it can seamlessly switch to the rendering function of the old DRI driver for graphics rendering, reducing rendering errors caused by DRI driver problems, ensuring the continuity and reliability of the rendering process, and thus improving the rendering effect while ensuring rendering reliability. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram of the architecture of the DRI driver in the Linux graphics system in related technologies;

[0022] Figure 2 This is an application environment diagram of a graphics rendering method in one embodiment;

[0023] Figure 3 This is a flowchart illustrating a graphics rendering method in one embodiment;

[0024] Figure 4 This is a flowchart illustrating the expansion of a structure in one embodiment;

[0025] Figure 5 for Figure 4 A flowchart illustrating step 401;

[0026] Figure 6 for Figure 4 A flowchart illustrating step 402 in the middle section;

[0027] Figure 7 This is a flowchart illustrating a process for determining whether a graphics rendering request involves a first function in one embodiment.

[0028] Figure 8 This is a flowchart illustrating a specific example of a graphics rendering method.

[0029] Figure 9 This is a structural block diagram of a graphics rendering apparatus in one embodiment;

[0030] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0032] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0033] In related technologies, a GPU manufacturer typically only has one DRI driver. The DRI driver loading process is as follows: Figure 1 As shown, Figure 1 This diagram illustrates the architecture of the DRI driver in a Linux graphics system, demonstrating how the DRI driver interacts with upper-layer graphics components (X Window System, Wayland protocol, OpenGL / EGL, etc.) to ultimately achieve hardware-accelerated graphics rendering. The following sections... Figure 1 Explain the meaning of each word in the text:

[0034] DRI is a technology in Linux systems that allows applications or clients to communicate directly with the graphics card hardware, bypassing intermediate redundant layers (such as indirect scheduling by the X server) to achieve direct rendering and significantly improve graphics performance. In the diagram, the DRI driver is the hardware interaction endpoint of the entire architecture—all upper-level graphics instructions are ultimately translated into low-level commands that the graphics card can execute through it.

[0035] The OpenGL Extension to the X Window System (GLX) is an extension that combines OpenGL with the X Window System, allowing OpenGL to render in the X environment and supporting DRI hardware acceleration.

[0036] X Server: The core of traditional window management, responsible for window layout and input device management.

[0037] Accelerated Indirect GLX (AIGLX): A technique that accelerates indirect graphics rendering, enabling the X server to process GLX OpenGL requests in a hardware-accelerated manner.

[0038] Device Driver Extensions (DDX): DDX is part of the X Window System and is responsible for handling hardware-related operations. It works with DRI to enable hardware acceleration in X servers.

[0039] Embedded-System Graphics Library (EGL): This is a graphics library primarily responsible for creating and managing graphics contexts, and serving as a bridge between graphics interfaces (such as OpenGL ES) and the underlying windowing system (or windowless system).

[0040] Generic Buffer Manager (GBM) is a buffer management library that provides a simple interface for applications to handle graphics buffers.

[0041] Wayland is a window display protocol used for communication between display servers and application clients. Weston is a reference implementation based on the Wayland protocol, used for window management and human-computer interaction; it functions as both a window manager and a compositor. These two components are designed to replace the traditional X Graph system, providing a more modern approach to graphics processing.

[0042] In Linux, there are two main technical paths for graphics rendering: the traditional X Window path and the emerging Wayland path.

[0043] X Window Path (corresponding component connections in the diagram: GLX→DRI driver; GLX→AIGLX→X server→DDX→DRI driver; DDX→EGL): Applications based on the X Window system initiate OpenGL 3D graphics rendering requests (such as drawing game screens) through GLX. GLX splits the request into two parts: one part is directly passed to the DRI driver (initial hardware rendering instructions); the other part is optimized by AIGLX and forwarded to the X server (the X server needs to coordinate window layout and display hierarchy, and cannot completely bypass it). The X server, as the core of traditional window management, is responsible for confirming window position and resolution adaptation, and then passing the instructions to DDX. DDX converts the general instructions of the X server into hardware-related instructions that the current graphics card can recognize; at the same time, DDX will work with EGL to perform cross-interface compatibility processing. DDX passes the converted instructions to the DRI driver, merges them with the instructions directly passed in the first step, and finally the DRI driver graphics card completes the graphics rendering, and the image is displayed on the screen.

[0044] The Wayland path (corresponding component connections in the diagram: weston / wayland application → EGL; weston / wayland application → GBM; EGL ↔ GBM; EGL → DRI driver): Applications based on the Wayland protocol (such as modern Linux desktop software and embedded device applications) initiate graphics rendering requests through the Weston (Wayland compositor) coordination window. The Weston / wayland application passes the request to EGL, which interacts bidirectionally with GBM. GBM is responsible for allocating memory buffers to store image data (such as temporarily storing pixel data). EGL obtains a free buffer from GBM, writes rendering instructions to the buffer, and then notifies GBM to commit the data. EGL retrieves the committed graphics data from GBM and passes it directly to the DRI driver without going through an additional intermediate layer (the core advantage of the Wayland protocol: streamlined link). At the same time, Weston interacts directly with GBM to confirm the buffer data after window compositing, ensuring the correct image hierarchy. The DRI driver receives instructions and buffer data from EGL, drives the graphics card to render, and finally displays the image on the screen.

[0045] When developing DRI drivers, GPU manufacturers may need to develop entirely new DRI drivers to meet requirements, discarding older ones. This results in new and old DRI drivers operating independently, meaning the new driver typically cannot directly inherit or call the functionality of the old one. This incompatibility leads to poor rendering quality when using the new driver to process rendering objects that depend on the functionality of the old driver. Furthermore, the development process for a new DRI driver is lengthy. To shorten development time, the new driver may temporarily require some capabilities from the old driver, requiring a process of integrating old driver functionality. However, achieving compatibility between the new and old DRI drivers remains a challenge.

[0046] Therefore, this application proposes a graphics rendering method that can... Figure 1 Based on this, it is compatible with other DRI drivers. By achieving rendering through compatibility with multiple DRI drivers, the rendering effect can be improved.

[0047] The graphics rendering method provided in this application embodiment can be applied to, for example, Figure 2 In the application environment shown, terminal 202 communicates with server 204 via a network. A data storage system can store the data that server 204 needs to process. The data storage system can be integrated onto server 204 or located on the cloud or other network servers. Terminal 202 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 204 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0048] In one exemplary embodiment, such as Figure 3 As shown, a graphics rendering method is provided, which can be applied to... Figure 1 The following steps 301 to 303 are described for example server 204.

[0049] Step 301: In response to the graphics rendering request, the interface function of the first DRI driver is called.

[0050] The first interface function returns a structure, which includes function pointers for both the first and second DRI drivers. At least one function of the second DRI driver differs from that of the first DRI driver. The structure is obtained by extending the first structure of the first DRI driver. "At least one function" refers to a function of the second DRI driver that differs from that of the first DRI driver.

[0051] In this context, a graphics rendering request refers to a graphics processing instruction or data initiated by an application or client, requesting the server to perform a specific rendering operation. A structure is a data set that aggregates function pointers or method interfaces of at least two functionally different DRI drivers (a first DRI driver and a second DRI driver). The first DRI driver can refer to a newly developed DRI driver, and the second DRI driver can refer to an older DRI driver. There must be at least one second DRI driver. The first interface function of the first DRI driver is the standard entry function in the DRI architecture for users to create and obtain graphics objects, and it has the function of returning a structure. Structure types include at least one of screen structure, context structure, drawable object structure, and image structure. The screen structure, as the root object of graphics rendering, represents a physical or virtual display screen and manages the global resources and state of the display device; the context structure stores rendering resources such as shaders, textures, and buffers, maintains the OpenGL rendering state, and manages the rendering command queue and execution state; the drawable object structure represents the window surface or frame buffer, manages front and back buffer swapping, and processes the size and format of the drawing surface; the image structure encapsulates textures and image data, and manages image format conversion and sampling. Each struct has a corresponding interface function, and the extended struct is obtained by calling the interface function.

[0052] For example, when a graphics rendering request is received, the first interface function of the first DRI driver is first called, such as the function createNewScreen() for creating a screen object, the function createNewContext() for creating a context object, the function createNewDrawable() for creating a drawable object, and the function createImageFromName() for creating an image object, to obtain the structure returned by these first interface functions. Each structure is obtained by extending the first structure of the first DRI driver so that it contains the functions of both the first and second DRI drivers. That is, each structure includes function pointers of the first and second DRI drivers for the corresponding functions.

[0053] Step 302: Call the first rendering function based on the function pointer of the first DRI driver.

[0054] The first rendering function refers to the core process function with rendering capabilities provided by the first DRI driver, which is used to handle graphics rendering requests.

[0055] For example, the first rendering function is called based on the function pointer of the first DRI driver in the structure to establish the basic rendering environment and state.

[0056] Step 303: During the process of processing the graphics rendering request through the first rendering function, if the graphics rendering request involves the first function of at least one function, the second rendering function is called based on the function pointer driven by the second DRI to perform graphics rendering.

[0057] The second rendering function is used to implement the first function. The second rendering function refers to a function provided by the second DRI driver to implement a specific rendering function that the first DRI driver does not have. The first function refers to any one of at least one function of the second DRI driver.

[0058] Optionally, the server deploys a first DRI driver and also deploys all or at least some of the functions of the second DRI driver (including at least one function different from the functions of the first DRI driver) to reduce the resource pressure on the server. The specific deployment is determined based on the deployable resources of the server, and this application embodiment does not impose any limitations on this. The structure may also include function pointers of the first DRI driver and function pointers corresponding to at least one function of the second DRI driver to ensure that specific functions in the second DRI driver can be called.

[0059] For example, during the execution of the first rendering function, the specific requirements of the current rendering scene are analyzed in real time, including the graphics features required for rendering, performance requirements, and compatibility requirements, in order to obtain the analysis results.

[0060] In one possible implementation, based on the analysis results, if it is determined that the graphics rendering request involves not only the functions of the first DRI driver but also the first function of a second DRI driver that differs from the functions of the first DRI driver, then not only is the first rendering function called to handle the graphics rendering request, but also the second rendering function of the second DRI driver is called through the function pointer of the second DRI driver in the structure to perform graphics rendering. This call can be a switch of the entire rendering pipeline or a mixed call of specific rendering stages.

[0061] In another possible implementation, if the analysis results determine that the graphics rendering request only involves the functions of the first DRI driver and not the first function of at least one of the functions, then there is no need to call the second rendering function; graphics rendering can be achieved simply by calling the first rendering function.

[0062] In another possible implementation, if the analysis results determine that the graphics rendering request only involves the first function of at least one function of the second DRI driver, then the graphics rendering can be achieved by calling the second rendering function without calling the first rendering function.

[0063] Depending on the specific needs, some objects require both the old and new DRI drivers to be created simultaneously, such as the screen (DRIscreen). For other objects, it is sufficient to create either the new or old DRI driver separately, such as the context (DRIcontext).

[0064] For example, the first DRI driver is the new DRI driver, and the second DRI driver is the old DRI driver. For a screen object, it is necessary to create an instance of the old DRI driver at the same time. Therefore, during the execution of the rendering function of the new DRI driver, the rendering function of the old DRI driver is called based on the function pointer of the old DRI driver in the structure, so as to realize the rendering of the screen object based on the new and old drivers.

[0065] In the aforementioned graphics rendering method, in response to a graphics rendering request, a first interface function of a first DRI driver is called. This first interface function obtains a structure, which includes function pointers for both the first and second DRI drivers. At least one function of the second DRI driver differs from that of the first DRI driver. A first rendering function is called based on the function pointer of the first DRI driver. During the processing of the graphics rendering request through the first rendering function, if the graphics rendering request involves the first function among at least one of the functions, a second rendering function is called based on the function pointer of the second DRI driver to perform graphics rendering. The second rendering function is used to implement the first function. This embodiment of the application can call rendering functions of at least two DRI drivers through a structure, enabling rendering based on at least two DRI drivers. This ensures compatibility with different functions and avoids functional loss or rendering quality degradation due to DRI driver upgrades. When a new DRI driver has a specific functional loss, the rendering function of the old DRI driver can be seamlessly switched for graphics rendering, reducing rendering errors caused by DRI driver problems and ensuring the continuity and reliability of the rendering process. Therefore, it can improve the rendering effect while ensuring rendering reliability.

[0066] In related technologies, when developing DRI drivers, GPU manufacturers may need to develop entirely new DRI drivers and discard older ones to meet requirements. However, the development process for new DRI drivers is lengthy. To shorten development time, new DRI drivers may temporarily require some capabilities of the old DRI drivers, thus involving a process of combining the functions of the old drivers. However, how to achieve compatibility between the new and old DRI drivers is a problem. To address this, embodiments of this application use the structure of the old DRI driver to extend the structure of the new DRI driver to obtain the aforementioned structure, thereby achieving compatibility between the new and old DRI drivers.

[0067] The following describes the specific process of expanding the first structure driven by the first DRI to obtain the above structure.

[0068] In one exemplary embodiment, such as Figure 4 As shown, the method further includes steps 401 to 403. Wherein:

[0069] Step 401: Obtain the first structure returned by the first interface function in the first DRI driver.

[0070] The first structure refers to a data set containing function pointers or method interfaces of each rendering function of the first DRI driver, and its type includes at least one of screen structure, context structure, drawable object structure, and image structure.

[0071] For example, first, the first DRI driver new_dri.so (the name of the first DRI driver) is loaded. In the first DRI driver, the first structure returned by the interface function of the first DRI driver (such as the function createNewScreen for creating screen objects) is obtained. The first structure includes function pointers of each rendering function of the first DRI driver (such as screen rendering functions).

[0072] Step 402: Load the library file of the second DRI driver in the first DRI driver, and obtain the second structure returned by the second interface function of the second DRI driver based on the library file.

[0073] The second structure refers to a data collection containing function pointers or method interfaces of the various rendering functions of the second DRI driver. Its type includes at least one of screen structure, context structure, drawable object structure, and image structure. The library file refers to the file that stores the second entry function of the second DRI driver. The second interface function is used to return the second structure of the second DRI driver.

[0074] For example, the first DRI driver can use the dlopen function to open the library file old_dri.so (the name of the library file) of the second DRI driver, and use the dlsym function to find the second entry function of the second DRI driver from the library file. By calling the second entry function, the first driver can obtain a list of all functional extensions and implementations provided by the second DRI driver. Based on the list of functional extensions of the second DRI driver, the second structure returned by the second interface function of the second DRI driver can be obtained, thereby obtaining the function pointers of each rendering function of the second DRI driver.

[0075] Step 403: Expand the first structure based on the second structure to obtain the structure.

[0076] For example, after obtaining the first structure and the second structure, the first structure is extended based on the second structure. For instance, pointers to structure data and function tables in the second structure are embedded in the first structure to obtain a new structure. The new structure contains function pointers of both the first and second DRI drivers. Therefore, the new structure is compatible with the functions of both the old and new DRI drivers. The new structure is returned through the first interface function corresponding to the first structure (such as the function createNewScreen for creating screen objects), so that the structure returned by the first interface function is a new structure that is an extension of the first structure.

[0077] In this embodiment, by dynamically loading the library file of the second DRI driver in the first DRI driver and obtaining the second structure returned by the interface function of the second DRI driver based on the library file, and extending the first structure based on the second structure, the extension of the first DRI driver based on the second DRI driver is realized. This can shorten the development time, ensure that the first DRI driver has the function of calling the second DRI driver, make the new driver compatible with the old driver, and facilitate the subsequent implementation of rendering compatible with both the new and old drivers.

[0078] The following example illustrates how to standardize the specific implementation process of obtaining the first structure under a dual-drive compatible framework.

[0079] In one exemplary embodiment, such as Figure 5 As shown, step 401 includes steps 501 and 502. Wherein:

[0080] Step 501: Call the first entry function of the first DRI driver to obtain the first interface function list of the first DRI driver.

[0081] The first interface function list includes metadata information of all available interface functions provided by the first DRI driver, including function identifier, function description, parameter format, and function pointer (address).

[0082] For example, when the first DRI driver needs to be loaded, the dynamic library file new_ of the first DRI driver is first located. This library file stores the first entry function of the first DRI driver and loads the driver into memory space through a system-level interface. After loading, it calls the first entry function of the first DRI driver, driDriverGetExtensions_new(), which serves as the primary communication interface between the first DRI driver and the graphics rendering system. After calling the first entry function, it executes an internal initialization process, including driver version verification, hardware capability detection, and resource allocation. Upon completion of initialization, the first entry function returns a structured list of first interface functions. This list includes metadata information for all available interface functions provided by the first DRI driver, including function identifiers, function descriptions, parameter formats, and function pointers (addresses).

[0083] Step 502: Call the first interface function in the first interface function list to obtain the first structure.

[0084] For example, after obtaining the list of interface functions for the first DRI driver, the list is parsed, and a suitable first interface function is selected from the list according to the needs of the current rendering task. This first interface function (such as the function `createNewScreen` for creating screen objects) executes its specific functional logic, including validating input parameters, allocating memory resources, and returning data. After the first interface function completes its execution, it returns a first structure. This first structure can be used for integrity verification, checking the validity of key fields, etc., and if the verification passes, it can be used to expand the structure.

[0085] It should be noted that a fallback strategy can be executed when the first entry function call fails, using the second DRI driver. When an exception occurs during the parsing of the first interface function list, a detailed error log is recorded and a diagnostic process is triggered. A fallback strategy can also be executed when the validation of the first structure fails.

[0086] Therefore, this embodiment, through a standardized process, can reliably and efficiently obtain the functional interfaces and structural resources of the first DRI driver, providing stable infrastructure support for subsequent dual-drive hybrid rendering.

[0087] The following example illustrates how to standardize the specific implementation process of obtaining the second structure under a dual-driver compatible framework.

[0088] In one exemplary embodiment, such as Figure 6As shown, step 402, obtaining the second structure returned by the second interface function of the second DRI driver based on the library file, includes steps 601 and 602. Wherein:

[0089] Step 601: Locate the second entry function of the second DRI driver in the library file and call the second entry function to obtain the list of second interface functions of the second DRI driver.

[0090] The second interface function list includes metadata information for all available interface functions provided by the second DRI driver, including function identifiers, function descriptions, parameter formats, and function pointers (addresses).

[0091] For example, the library file old_ of the second DRI driver is loaded in the first DRI driver. The system uses a dynamic symbol lookup interface to search for the second entry function of the second DRI driver (such as the driDriverGetExtensions_old function or a similar function) in the loaded library files. After finding the second entry function of the second DRI driver, it calls the entry function and retrieves the list of second interface functions of the second DRI driver returned by it.

[0092] Step 602: Call the second interface function in the second interface function list to obtain the second structure.

[0093] For example, after obtaining the list of second interface functions driven by the second DRI, the list is parsed, and a suitable second interface function is selected from the list and called. The called second interface function executes its internal logic, generates and returns a second structure.

[0094] Therefore, this embodiment, through a standardized process, can reliably and efficiently obtain the complete set of interface function structures from the second DRI driver library file, ensuring the reliability and completeness of the second structure acquisition, providing reliable underlying support for the collaborative work of the new and old DRI drivers, and providing reliable support for the complete integration of the old driver functions.

[0095] After obtaining the first and second structures, step 403 is executed, which involves extending the first structure based on the second structure to obtain a new structure. The following example describes a specific implementation method for extending the functionality of the first structure using function pointer embedding.

[0096] In an exemplary embodiment, step 403 includes: embedding function pointers in a second structure into a first structure to obtain a structure.

[0097] There is at least one first structure, and each first structure corresponds to one second structure. For example, the screen structure in the first DRI driver corresponds to the screen structure in the second DRI driver.

[0098] For example, firstly, within the first structure, while retaining the original field layout, an extended area is added specifically for embedding function pointers from the second structure. This extended area may include: a function pointer table for the second DRI driver (storing function pointers extracted from the second structure), compatibility flags (identifying the validity and availability of each function pointer), and version adaptation information (recording the version information of the second DRI driver corresponding to the function pointer), etc. Then, function pointers are obtained from the second structure, such as function pointers for the rendering pipeline (e.g., geometry processing, rasterization, pixel shading, etc.), resource management function pointers (e.g., memory allocation, texture management, etc.), and state control function pointers (e.g., context switching, synchronization control, etc.). The integrity and validity of each obtained function pointer are verified to ensure it is not empty and directly accessible to executable memory. The verified function pointers are then embedded into the extended area of ​​the first structure according to a predefined structure. Optionally, a function pointer field corresponding to the second structure can be reserved in the first structure. The function pointers in the second structure are copied to the corresponding field to obtain a new structure, which then includes function pointers from both the first and second DRI drivers.

[0099] Taking the screen structure, context structure, drawable object structure, and image structure as examples, the process of structure expansion is illustrated:

[0100] Extended Screen Structure (DRIscreenRec): Based on the new DRI driver's screen structure, an additional field is added to store function pointers to the old DRI driver's screen rendering functions, enabling it to retain functionality from both the old and new drivers. It is returned by the creation function `createNewScreen` or `createNewScreen2`. Simultaneously, the extended DRI pointers from the old driver's screen structure are extracted and saved, and these pointers are then stored in the new DRI driver's screen structure.

[0101] Extended Context Structure (DRIcontextRec): Based on the new DRI driver's context structure, add a field to store the function pointer of the old DRI driver's context rendering function, so that it has the functionality of both the old and new drivers. It is returned by creating the function createNewContext (creating a new driver context) or createContextAttributes (selecting the driver based on attributes).

[0102] Extended Drawable Structure (DRIdrawableRec): Based on the new DRI-driven drawable structure, add a field to store the function pointer of the old DRI-driven drawable rendering function, so that it has the functionality of both the old and new drivers. It is returned by the creation function createNewDrawable (create new driver drawable).

[0103] Extended Image Structure (DRImageRec): Based on the new DRI-driven image structure, a new field is added to store the function pointers of the old DRI-driven image rendering functions, so that it has both new and old driver functions. It is returned through the various CreateImage class functions in the DRI image extension (DRImageExtensions) structure. Each class function instantiates both the old and new image resources.

[0104] In this embodiment, through the above extension, the new DRI driver has obtained all the DRI interface functions of the old DRI driver. Therefore, during subsequent rendering, the old DRI driver can be executed when the new DRI driver is executed, thus achieving compatibility between the new and old DRI drivers.

[0105] The above describes the extension of the structure. After the extension, the new structure can be used for rendering. The following is an example.

[0106] In one exemplary embodiment, such as Figure 7 As shown, the method further includes steps 701 to 703. Wherein:

[0107] Step 701: During the process of handling the graphics rendering request through the first rendering function, determine the function to be executed.

[0108] For example, in the process of processing the graphics rendering request through the first rendering function, the graphics rendering request is first parsed, and the functions to be executed for rendering are determined based on the parsing results.

[0109] Step 702: If the function to be executed includes the first function, then predict the computing resources required to execute the first function by calling the second rendering function.

[0110] Step 703: If the computing resources are less than or equal to a preset computing resource threshold, then it is determined that the graphics rendering request involves a first function of at least one function.

[0111] Among them, the computing resource threshold is a threshold of computing resources used for graphics rendering by calling rendering functions, which is set in advance based on actual needs, actual constraints, server attributes, etc.

[0112] Step 704: If the function to be executed does not include the first function or the computing resources are greater than the computing resource threshold, then it is determined that the graphics rendering request does not involve the first function of at least one function.

[0113] For example, during the processing of a graphics rendering request through a first rendering function, the graphics rendering request is parsed to obtain the function to be executed. The function to be executed is compared with at least one function of a second DRI driver (different from the function of the first DRI driver). If the function to be executed includes the first function among at least one function, then at least one indicator such as the performance indicator, computing resources, and storage indicator of calling the second rendering function of the second DRI driver is further predicted or evaluated. If the indicator is not greater than a preset indicator (for example, the computing resources required to execute the first function by calling the second rendering function are not greater than a preset computing resource threshold), it indicates that the first function of the second DRI driver is required based on the function of the first DRI driver (new driver) and the execution of the first function by the second DRI driver meets the requirements. Then it is determined that the graphics rendering request involves the first function among at least one function. If the function to be executed does not include the first function among at least one function or the computing resources are greater than the preset computing resource threshold, it indicates that the first function of the second DRI driver is not required based on the function of the first DRI driver (new driver) or the cost of calling the second DRI driver is too high and it is not advisable to call the second DRI driver. Then it is determined that the graphics rendering request does not involve the first function among at least one function. For example, when it is detected that the rendering pipeline requires both the new and old DRI drivers' exclusive functions, the computational resources required to call the old DRI driver are further predicted. If the computational resources are not greater than a preset computational resource threshold, it is determined that the graphics rendering request involves the first function of at least one function of the first DRI driver, and the rendering function of the old DRI driver needs to be called. Therefore, the second rendering function of the old DRI driver is called at a specific stage of the rendering pipeline.

[0114] For example, a graphics rendering request includes a 3D game rendering request. During the execution of the first rendering function A of the new DRI driver, the graphics rendering request is first parsed to obtain the functions to be executed, including the ray tracing function of the new DRI driver and the texture function of the old DRI driver. Further, it is determined that the computational resources required to call the texture function of the old DRI driver are less than a preset computational resource threshold. Therefore, it is determined that the texture function involving the old DRI driver requires calling the second rendering function B of the old DRI driver. Then, during the texture processing stage of the execution of A, the rendering function B is called based on the function pointer of the old DRI driver in the structure to perform texture processing based on the old DRI driver.

[0115] In this embodiment, during the process of the first rendering function processing the graphics rendering request, the function to be executed can be determined, and based on the function to be executed, it can be determined whether the graphics rendering request involves the first function of at least one function of the second DRI driver. This identifies the rendering scene that requires dual-driver collaboration and calls the second rendering function of the second DRI driver, achieving compatibility between the old and new DRI drivers, ensuring that the respective advantages of the old and new DRI drivers are utilized to the maximum extent, guaranteeing the integrity and correctness of the rendering function, and greatly improving the rendering effect.

[0116] In an exemplary embodiment, determining the function to be executed in step 701 may include: parsing the graphics rendering request to obtain the function parameters required for rendering; and determining the function to be executed based on the parsed function parameters.

[0117] The functional parameters refer to metadata embedded in the graphics rendering request that directly or indirectly indicate the required rendering operations.

[0118] For example, when the first rendering function begins processing a graphics rendering request, it first parses the request. During parsing, it extracts the functional parameters carried in the request. These functional parameters may include at least one of the following: functional parameters from GLX, the X server, DDX, the EGL interface, and GBM. Then, the function corresponding to the parsed functional parameters is determined as the function to be executed, such as the screen rendering function in DDX. If the screen rendering function involves the first function of the old DRI driver, then the second rendering function of the old DRI driver is called.

[0119] Therefore, this embodiment can accurately determine one or more functions to be executed for the current rendering task. These functions are used to subsequently determine whether to call the second rendering function of the second DRI driver.

[0120] The following describes the graphics rendering method of an embodiment of this application through a specific example.

[0121] In a specific example, such as Figure 8 As shown, the graphics rendering method includes the following steps:

[0122] Step 801: In response to the graphics rendering request, call the entry function of the new DRI driver to obtain the list of interface functions of the new DRI driver;

[0123] The entry function for the new DRI driver is driDriverGetExtensions_new().

[0124] Step 802: The new DRI driver opens the old DRI driver's library old_dri.so using the dlopen function and saves all extended implementations returned by the old DRI driver's entry function;

[0125] The entry function for the old DRI driver is driDriverGetExtensions_old().

[0126] Step 803: Call the screen creation function in the interface function list of the new DRI driver to obtain the screen structure returned by the function; the screen structure contains the functions of both the old and new DRI drivers.

[0127] Screen creation functions include createNewScreen or createNewScreen2.

[0128] Step 804: Input the screen structure into the context creation function in the interface function list of the new DRI driver, and call the function to obtain the context structure returned by the function; the context structure contains the functionality of both the old and new DRI drivers;

[0129] Context creation functions include createNewContext or createContextAttribs.

[0130] Step 805: Input the context structure into the drawable object creation function in the interface function list of the new DRI driver, and call the function to obtain the drawable object structure returned by the function; the drawable object structure contains the functionality of both the old and new DRI drivers.

[0131] The functions for creating drawable objects include the createNewDrawable function.

[0132] Step 806: Input the drawable object structure into the image creation function in the interface function list of the new DRI driver, and call the function to obtain the image structure returned by the function; the image structure contains the functionality of both the old and new DRI drivers.

[0133] Image creation functions include the CreateImage class functions in the DRIimageExtension structure.

[0134] Step 807: Call the rendering function of the new DRI driver based on the function pointer of the new DRI driver in each structure;

[0135] Step 808: During the execution of the new DRI-driven rendering function, determine whether the old DRI function's rendering function needs to be executed based on the rendering function. If yes, proceed to step 809; otherwise, end.

[0136] Step 809: Call the rendering function of the old DRI driver based on the function pointer of the old DRI driver in each structure.

[0137] The new DRI driver has acquired all the interface functions of the old DRI driver. The compatibility strategy differs for different objects: objects like `DRIscreen` require both the old and new drivers to be created simultaneously; while objects like `DRIcontext` can create either a new DRI driver instance or an instance of the old DRI driver independently. The new DRI driver can decide whether to call the old DRI driver based on the specific scenario, thus achieving compatibility between the two DRI drivers.

[0138] In summary, the embodiments of this application achieve compatibility with at least two sets of DRI drivers, old and new. In related technologies, the development process of new DRI drivers is lengthy, while the embodiments of this application combine the functions of old DRI drivers to realize the development of new DRI drivers, which can shorten the development time. At the same time, the graphics rendering is realized by using the developed new DRI drivers, which can achieve graphics rendering compatible with multiple sets of DRI drivers. The optimal driving path is automatically selected according to the characteristics of the rendering scene, thereby improving the rendering quality and rendering effect.

[0139] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0140] Based on the same inventive concept, this application also provides a graphics rendering apparatus for implementing the graphics rendering method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more graphics rendering apparatus embodiments provided below can be found in the limitations of the graphics rendering method described above, and will not be repeated here.

[0141] In one exemplary embodiment, such as Figure 9As shown, a graphics rendering apparatus is provided, comprising: a first invocation module 901, a second invocation module 902, and a third invocation module 903, wherein:

[0142] The first calling module 901 is used as a first calling module to call a first interface function of the first Direct Rendering Infrastructure (DRI) driver in response to a graphics rendering request; wherein the first interface function is used to return a structure, the structure including a function pointer of the first DRI driver and a function pointer of the second DRI driver, and at least one function of the second DRI driver is different from the function of the first DRI driver.

[0143] The second calling module 902 is used to call the first rendering function based on the function pointer of the first DRI driver;

[0144] The third calling module 903 is used to call the second rendering function based on the function pointer of the second DRI driver to perform graphics rendering when the graphics rendering request is processed by the first rendering function. If the graphics rendering request involves the first function among the at least one functions, the second rendering function is used to implement the first function.

[0145] In one embodiment, the apparatus further includes a first acquisition module, a second acquisition module, and an extension module. The first acquisition module is configured to acquire a first structure returned by a first interface function in a first DRI driver; the second acquisition module is configured to load a library file of the second DRI driver in the first DRI driver and acquire a second structure returned by a second interface function of the second DRI driver based on the library file; the extension module is configured to extend the first structure based on the second structure to obtain the second structure.

[0146] In one embodiment, the first acquisition module is specifically configured to: call the first entry function of the first DRI driver to obtain a first interface function list of the first DRI driver; and call the first interface function in the first interface function list to obtain the first structure.

[0147] In one embodiment, the second acquisition module is specifically used to: search for the second entry function of the second DRI driver in the library file, and call the second entry function to obtain the second interface function list of the second DRI driver; and call the second interface function in the second interface function list to obtain the second structure.

[0148] In one embodiment, the extension module is specifically used to: embed function pointers from the second structure into the first structure to obtain the structure.

[0149] In one embodiment, the apparatus further includes: a first determining module, configured to determine a function to be executed during the processing of the graphics rendering request through the first rendering function; a second determining module, configured to predict the computing resources required to execute the first function by calling the second rendering function if the function to be executed includes the first function; and to determine that the graphics rendering request involves the first function among the at least one function if the computing resources are less than or equal to a preset computing resource threshold; and a third determining module, configured to determine that the graphics rendering request does not involve the first function among the at least one function if the function to be executed does not include the first function or the computing resources are greater than the computing resource threshold.

[0150] In one embodiment, the first determining module is specifically used to: parse the graphics rendering request to obtain the functional parameters required for rendering; and determine the function to be executed based on the parsed functional parameters.

[0151] The modules in the aforementioned graphics rendering device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0152] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores graphics rendering data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a graphics rendering method.

[0153] Those skilled in the art will understand that Figure 10The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0154] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the graphics rendering method proposed in the above embodiments of this application.

[0155] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the graphics rendering method proposed in the above embodiments of this application.

[0156] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the graphics rendering method proposed in the above embodiments of this application.

[0157] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0158] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 application.

[0159] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A graphics rendering method, characterized in that, The method includes: In response to a graphics rendering request, a first interface function of the first Direct Rendering Infrastructure (DRI) driver is invoked; wherein the first interface function is used to return a structure, the structure including function pointers of the first DRI driver and function pointers of the second DRI driver, wherein at least one function of the second DRI driver is different from the function of the first DRI driver. The first rendering function is called based on the function pointer of the first DRI driver; During the processing of the graphics rendering request through the first rendering function, if the graphics rendering request involves the first function among the at least one functions, then the second rendering function is called based on the function pointer of the second DRI driver to perform graphics rendering, and the second rendering function is used to implement the first function.

2. The method according to claim 1, characterized in that, The method further includes: In the first DRI driver, obtain the first structure returned by the first interface function; Load the library file of the second DRI driver in the first DRI driver, and obtain the second structure returned by the second interface function of the second DRI driver based on the library file; The first structure is extended based on the second structure to obtain the structure.

3. The method according to claim 2, characterized in that, The step of obtaining the first structure returned by the first interface function in the first DRI driver includes: Call the first entry function of the first DRI driver to obtain the first interface function list of the first DRI driver; The first interface function in the first interface function list is called to obtain the first structure.

4. The method according to claim 2, characterized in that, The second structure returned by the second interface function of the second DRI driver obtained based on the library file includes: Locate the second entry function of the second DRI driver in the library file, and call the second entry function to obtain the second interface function list of the second DRI driver; Call the second interface function in the second interface function list to obtain the second structure.

5. The method according to claim 2, characterized in that, The method of extending the first structure based on the second structure to obtain the structure includes: The function pointers in the second structure are embedded in the first structure to obtain the structure.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: During the process of processing the graphics rendering request through the first rendering function, the function to be executed is determined; If the function to be executed includes the first function, then predict the computing resources required to execute the first function by calling the second rendering function; If the computing resources are less than or equal to a preset computing resource threshold, then the graphics rendering request is determined to involve the first function; If the function to be executed does not include the first function or the computing resources are greater than the computing resource threshold, then it is determined that the graphics rendering request does not involve the first function.

7. The method according to claim 6, characterized in that, The function to be executed includes: Parse the graphics rendering request to obtain the functional parameters required for rendering; Based on the parsed functional parameters, the function to be executed is determined.

8. A graphics rendering apparatus, characterized in that, The device includes: The first calling module is used to call a first interface function of the first Direct Rendering Infrastructure (DRI) driver in response to a graphics rendering request; wherein the first interface function is used to return a structure, the structure including a function pointer of the first DRI driver and a function pointer of the second DRI driver, and at least one function of the second DRI driver is different from the function of the first DRI driver. The second calling module is used to call the first rendering function based on the function pointer of the first DRI driver; The third calling module is used to call the second rendering function based on the function pointer of the second DRI driver to perform graphics rendering when the graphics rendering request is processed by the first rendering function. If the graphics rendering request involves the first function among the at least one functions, the second rendering function is used to implement the first function.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images