CN115167949B

CN115167949B - Method, device and medium for adapting high-version OpenGL function to low-version application program

Info

Publication number: CN115167949B
Application number: CN202211095506.6A
Authority: CN
Inventors: 杜文华; 李彪; 刘伟; 曹伟
Original assignee: Xi'an Xintong Semiconductor Technology Co ltd
Current assignee: Xi'an Xintong Semiconductor Technology Co ltd
Priority date: 2022-09-08
Filing date: 2022-09-08
Publication date: 2022-12-06
Anticipated expiration: 2042-09-08
Also published as: CN115167949A

Abstract

The embodiment of the invention discloses a method, a device and a medium for adapting a high-version OpenGL function to a low-version application program, wherein the method comprises the following steps: preloading a dynamic library file before starting an application program; the dynamic library file comprises a low-version OpenGL function which is obtained by simulating a high-version OpenGL function and is abandoned in the high-version OpenGL function; in the running process of the application program, if the executed OpenGL function does not exist in the high-version OpenGL function library, calling a low-version OpenGL function which is simulated in the dynamic library file and is the same as the executed OpenGL function; and if the executed OpenGL function exists in the high-version OpenGL function library, directly calling an OpenGL function which is the same name as the executed OpenGL function in the high-version OpenGL function library.

Description

Method, device and medium for adapting high-version OpenGL function to low-version application program

Technical Field

The embodiment of the invention relates to the technical field of computer graphic programming, in particular to a method, a device and a medium for adapting a high-version OpenGL function to a low-version application program.

Background

The Open Graphics Library or Open Graphics Library (OpenGL) is a cross-language, cross-platform Application Programming Interface (API) for rendering 2D, 3D vector Graphics. The application programming interface is composed of nearly 350 different function calls and is used for drawing complex three-dimensional images from simple graphic bits, openGL is commonly used for CAD, virtual reality, scientific visualization programs and electronic game development and is used as a software development kit of open three-dimensional graphics independent of an operating system, and application programs developed on the basis of the software development kit can be simply and conveniently transplanted to various platforms.

With the upgrade of OpenGL versions, the OpenGL version used in current graphics development is higher and higher, which has evolved from the first 1.0 to the latest 4.6 version. The development approach also changed from the original pure C/C + + programming to C/C + + hybrid Shader programming. After the OpenGL 3.3 version, the OpenGL graphics pipeline has been transitioned from a fixed pipeline to a programmable pipeline. The fixed pipeline programming mode is relatively simple, the programmable pipeline programming is more complex, but the programmable pipeline programming can realize certain rendering effect which cannot be realized by the fixed pipeline programming mode, and the performance of the fixed pipeline programming mode is improved to a certain extent compared with the programmable pipeline programming mode. However, the size of the application developed based on OpenGL is quite large at present, a small part of the application is developed by a high version after OpenGL 3.3, and a large part of the application is developed by a previous version before OpenGL 3.3, so that the application developed by the previous version before OpenGL 3.3 cannot be operated in an environment only supporting OpenGL 3.3 and later. If a target application program is rewritten on an interface of a later version using OpenGL 3.3, a large number of low-version OpenGL application program source codes need to be modified, and if there are many low-version OpenGL application program source codes but the modification mode is not universal, batch processing cannot be performed, the low-version OpenGL application program source codes need to be processed one by one, which is time-consuming, labor-consuming and low in adaptation efficiency.

Disclosure of Invention

In view of this, embodiments of the present invention are expected to provide a method for adapting a high-version OpenGL function to a low-version application program, and a mode of using the high-version OpenGL function to simulate a low-version OpenGL function that is discarded before OpenGL 3.3 can support that all application programs developed based on the low-version OpenGL can run on a high-version OpenGL platform, and it is not necessary to rewrite an interface in the high-version OpenGL and modify a large amount of source codes of the low-version OpenGL application program, so as to save development time and improve development efficiency.

The technical scheme of the embodiment of the invention is realized as follows:

in a first aspect, an embodiment of the present invention provides a method for adapting a high-version OpenGL function to a low-version application program, where the method includes:

preloading a dynamic library file before starting an application program; the dynamic library file comprises a low-version OpenGL function which is obtained by simulating a high-version OpenGL function and is abandoned in the high-version OpenGL function;

in the running process of the application program, if the executed OpenGL function does not exist in the high-version OpenGL function library, calling a low-version OpenGL function which is simulated in the dynamic library file and is the same as the executed OpenGL function;

and if the corresponding executed OpenGL function exists in the high-version OpenGL function library, directly calling an OpenGL function in the high-version OpenGL function library, which is the same name as the executed OpenGL function.

In a second aspect, an embodiment of the present invention provides an apparatus for adapting a high-version OpenGL function to a low-version application, where the apparatus includes: the device comprises a preloading part, a first calling part and a second calling part; wherein,

the preloading part is configured to preload the dynamic library file before the application program is started; the dynamic library file comprises a low-version OpenGL function which is obtained by simulating a high-version OpenGL function and is abandoned in the high-version OpenGL function;

the first calling part is configured to call a low-version OpenGL function which is simulated in the dynamic library file and is named as the executed OpenGL function if the executed OpenGL function does not exist in a high-version OpenGL function library in the running process of the application program;

the second calling part is configured to directly call an OpenGL function in the high-version OpenGL function library, which is the same name as the executed OpenGL function, if the executed OpenGL function exists in the high-version OpenGL function library.

In a third aspect, an embodiment of the present invention provides a computing device, where the computing device includes: a communication interface, a memory, and a processor; the various components are coupled together by a bus system; wherein,

the communication interface is used for receiving and sending signals in the process of receiving and sending information with other external network elements;

the memory for storing a computer program operable on the processor;

the processor is configured to, when the computer program is run, execute the steps of the method for adapting the high-version OpenGL function to the low-version application program according to the first aspect.

In a fourth aspect, an embodiment of the present invention provides a computer storage medium, where a program for adapting a high-version OpenGL function to a low-version application program is stored, and the program, when executed by at least one processor, implements the steps of the method for adapting a high-version OpenGL function to a low-version application program in the first aspect.

The embodiment of the invention provides a method for adapting a high-version OpenGL function to a low-version application program; by adding the dynamic library file, each abandoned low-version OpenGL function in the high-version OpenGL function library is realized by simulating the high-version OpenGL function, so that when an application program runs to the condition that the abandoned low-version OpenGL function needs to be executed, a same-name function in the dynamic library file is called to complete execution, the abandoned low-version OpenGL function in an application program source code does not need to be rewritten, and after the dynamic library file is loaded, the local high-version OpenGL function library can be adapted to run various application programs generated by the low-version OpenGL function, the development time is saved, and the development efficiency and the compatibility of the application program are improved.

Drawings

Fig. 1 is a schematic diagram of a computer system according to an embodiment of the present invention.

FIG. 2 is a block diagram illustrating an example implementation of the CPU, GPU and memory in FIG. 1.

FIG. 3 is a schematic flow chart of a fixed pipeline according to an embodiment of the present invention.

FIG. 4 is a flow chart of a programmable pipeline according to an embodiment of the present invention.

Fig. 5 is a flowchart illustrating a method for adapting a high-version OpenGL function to a low-version application according to an embodiment of the present invention.

Fig. 6 is a schematic diagram illustrating a detailed scheduling process of an application according to an embodiment of the present invention.

Fig. 7 is a schematic diagram illustrating a device for adapting a high-version OpenGL function to a low-version application according to an embodiment of the present invention.

Fig. 8 is a schematic diagram illustrating a device for adapting a high-version OpenGL function to a low-version application according to another embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention.

Referring to fig. 1, which shows a computer system 100 capable of implementing embodiments of the present invention, it should be noted that the illustrated system is only one example of a possible system, and embodiments of the present invention may be implemented in any of various systems as desired. The computer system component 100 may be embodied as any type of computing device, including without limitation a desktop computer, a server, a workstation, a laptop computer, a computer-based emulator, a wireless device, a mobile or cellular telephone (including so-called smartphones), a Personal Digital Assistant (PDA), a video game console (including video displays, mobile video game devices, mobile video conferencing units), a laptop computer, a desktop computer, a television set-top box, a tablet computing device, an e-book reader, a fixed or mobile media player, and the like. As shown in fig. 1, the computer system assembly 100 may include a Central Processing Unit (CPU) 10, a Graphic Processing Unit (GPU) 20, a memory 30, a display processor 40, a display 41, and a communication interface 50. Display processor 40 may be part of the same Integrated Circuit (IC) as GPU 20, may be external to one or more ICs that include GPU 20, or may be formed in an IC that is external to the IC that includes GPU 20.

Specifically, the CPU10 may comprise a general-purpose or special-purpose processor configured to process instructions of a computer program for execution, controlling the computer system composition 100 operations. The user may communicate with another input device (not shown) coupled to the computer system component 100 via the communication interface 50, such as: trackballs, keyboards, mice, microphones, touch pads, touch screens, and other types of devices provide input to the CPU10 in the computer system assembly 100 to cause the CPU10 to execute instructions of one or more software applications. The applications executing on the CPU10 may include a Graphical User Interface (GUI) application, an operating system, a portable graphics application, a computer-aided design program for engineering or artistic applications, a video game application, a word processor application, an email application, a spreadsheet application, a media player application, or a rendering application using 2D, 3D graphics, etc., and embodiments of the present invention are exemplified by executing a graphics rendering application. Furthermore, the rendering Application executing on the CPU10 may include one or more graphics rendering instructions (which may also be understood as one or more of the graphics included in a frame of a screen to be rendered) that may conform to a graphics Application Programming Interface (API), such as an open graphics library API (OpenGL API), an open graphics library embedded system (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, an open computing language (OpenCLTM), a RenderScript or any other heterogeneous computing API, or any other public or proprietary standard graphics or computing API, as will be exemplified by the OpenGL API in the following description of the invention.

GPU 20 may be configured to perform graphics operations to render one or more graphics primitives to display 41 for presentation. It will be appreciated that CPU10, by controlling GPU driver 14, translates OpenGL-defined graphics rendering instructions into graphics rendering commands readable by GPU 20, and then causes GPU 20 to execute some or all of the graphics rendering commands, based on the received one or more graphics rendering commands, including, but not limited to, graphics commands and graphics data (e.g., draw commands, state information, primitive information, texture information, etc.), to render and present the one or more graphics primitives on display 41. A memory 30 configured to store application program instructions capable of running on the CPU10, graphics data required for execution by the GPU 20, and operation result data thereof. For example, GPU 20 may store the fully formed image in memory 30. Memory 30 may include one or more volatile or non-volatile memories or storage devices, such as a Random Access Memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), erasable Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), flash memory, magnetic data media, or optical storage media. Display processor 40 may retrieve the image from memory 30 and output values that illuminate pixels of display 41 to display the image. Display 41 may be a display of computer system 100 that displays graphical image content generated by GPU 20. The display 41 may be a Liquid Crystal Display (LCD), an organic light emitting diode display (OLED), a Cathode Ray Tube (CRT) display, a plasma display, or another type of display device.

Referring to fig. 1, fig. 2 further illustrates a block diagram 200 of an implementation of the critical components CPU10, GPU 20, and memory 30 in the computer system component 100. As shown in fig. 2, the block diagram 200 of an implementation of an embodiment of the present invention primarily includes, but is not limited to, CPU10, GPU 20, memory 30, and their corresponding internal components. Where CPU10 includes application 11, openGL API 13, and GPU driver 14, where each of OpenGL API 13 and GPU driver 14 may serve one or more applications, openGL API 13 and GPU driver 14 may be implemented as hardware units of CPU10 in some examples, and GPU driver 14 may compile one or more graphics rendering instructions of CPU10 into application commands executable by GPU 20. GPU 20 internal structures include, but are not limited to, graphics memory 21, processor cluster 22, texture memory 23. In embodiments of the present invention, graphics memory 21 may be part of GPU 20. Thus, GPU 20 may read data from graphics memory 21 and write data to graphics memory 21 without using a bus. In other words, GPU 20 may process data locally using local storage instead of off-chip memory, such graphics memory 21 may be referred to as on-chip memory. This allows GPU 20 to operate in a more efficient manner by eliminating the need for GPU 20 to read and write data via the bus, which may experience heavy bus traffic. In some examples, GPU 20 may not include a separate memory, but rather utilize an external memory 30 via a bus. The type of the graphic memory 21 is referred to the type of the aforementioned memory 30, and will not be described herein. Processor cluster 22 is to execute a graphics processing pipeline to decode graphics rendering commands and configure the graphics processing pipeline to perform operations specified in the graphics rendering commands. Texture memory 23 refers to a memory for storing textures. During rendering, the memory of the GPU, which may also be referred to as video memory, may be allocated for many different purposes, such as vertex caching, index caching, texture caching, template caching, etc., and then the texture memory 23 is a fingerprint cache. The memory 30 may include an output buffer 31 and a system memory 32. Where the output buffer 31 may be part of the system memory 32 or may be separate from the system memory 32. The output buffer 31 may store rendered image data, e.g., pixel data, with the particular stored data being red, green, blue, alpha (RGBA) components for each pixel, where the "RGB" components correspond to color values and the "a" component corresponds to a destination alpha value (e.g., an opacity value for image compositing). It may also be referred to as a Frame buffer (Frame buffer) or a video memory, and is used to preview the rendering effect of the picture Frame, or may be understood that the rendering effect of previewing the picture Frame may be implemented by a Frame buffer mechanism, where the Frame buffer is a driver interface in a kernel space, and does not have any data operation capability, and does not process data in the middle, but needs support of a real video card drive.

Based on the prior art OpenGL application invocation, CPU10 issues instructions through application 11 to GPU driver 14 via graphics OpenGL API 13, and GPU driver 14 may formulate one or more commands specifying one or more operations for GPU 20 to perform in order to render the primitives, for use in rendering the one or more graphics primitives into a displayable graphics image. When GPU 20 receives the graphics rendering commands from CPU10, GPU 20 may execute the graphics processing pipeline using processor cluster 22 in order to decode the commands and configure the graphics processing pipeline to perform the operations specified in the graphics rendering commands. Specifically, GPU 20 needs to implement a rendering operation on graphics by means of a graphics rendering pipeline in the process of implementing or running an application, where the graphics rendering pipeline includes a fixed pipeline 300 and a programmable pipeline 400, as shown in fig. 3 and 4, respectively, and belongs to a logic structure formed by concatenation, and each stage may also be referred to as a rendering stage. The method is generally divided into five steps of vertex processing, primitive assembling, rasterizing, fragment coloring and testing and mixing, and the module and operation corresponding to each step are shown in fig. 3 and 4 in detail. Comparing the graphics rendering pipeline diagrams shown in fig. 3 and 4, it can be seen that the fixed pipeline differs from the programmable pipeline in that a programmable Shader is added to the programmable pipeline, such as a vertex processor and a fragment processor shown in a circled box in fig. 4, where the vertex processor may also be referred to as a vertex Shader and the fragment processor may also be referred to as a fragment Shader. The user needs to write the code corresponding to these two modules in the application.

It should be noted that, for the relationship between the application Program and the Shader existing in OpenGL, the Program is equivalent to the application Program used by the current rendering pipeline, is a container of the Shader, and can mount multiple shaders; and each Shader corresponds to an application part to replace the editable application of the fixed rendering pipeline. The processing flow of the Shader is that firstly, a Shader script needs to be compiled, then the compiled Shader is mounted on a Program, and the Program is used in the OpenGL rendering to enable the Shader to take effect. That is, shaders are application programs dedicated to implementing different rendering processes, and the Shader rendering algorithm of the GPU can be customized by the shaders, so that the GPU processes each vertex and each pixel point in the graphics data according to the Shader rendering algorithm, thereby rendering the frame of the picture to the display. In addition, since the application program of the fixed pipeline runs on the low-version OpenGL platform and the application program of the programmable pipeline runs on the high-version OpenGL platform, but there is no module with programming capability in the fixed pipeline, and part of the low-version OpenGL function of the running application program does not exist in the high-version OpenGL function library, the application program developed based on the low-version OpenGL in the fixed pipeline cannot run in the high-version OpenGL. If the source codes of the low-version OpenGL application program are rewritten on an interface of the high-version OpenGL, a large amount of source codes of the low-version OpenGL application program need to be modified, and if a plurality of application program source code modification modes cannot be used universally and cannot be processed in batches, the application program source codes need to be processed independently one by one, so that time and labor are wasted.

Based on the above explanation, the embodiment of the present invention expects that the low-version OpenGL function is simulated in the high-version OpenGL before the application program is executed, and is packaged into the dynamic library file. In other examples, the dynamic library file may also be referred to as a "dynamic link library" or a "dynamic link file" or the like, so that when the application program executes to the low-version OpenGL function, the execution of the low-version OpenGL function is completed by calling a function of the same name as the executed low-version OpenGL function, which is simulated by the high-version OpenGL function, in the dynamic library file, so that the low-version OpenGL function in the application program source code does not need to be rewritten, the development time is saved, and the development efficiency is improved. Based on this, referring to fig. 5, a method for adapting a high-version OpenGL function to a low-version application provided by an embodiment of the present invention is shown, where the method includes:

s501: preloading a dynamic library file before starting an application program; the dynamic library file comprises a low-version OpenGL function which is obtained by simulating a high-version OpenGL function and is abandoned in the high-version OpenGL function;

s502: in the running process of the application program, if the executed OpenGL function does not exist in the high-version OpenGL function library, calling a low-version OpenGL function which is simulated in the dynamic library file and is the same as the executed OpenGL function;

s503: and if the corresponding executed OpenGL function exists in the high-version OpenGL function library, directly calling an OpenGL function in the high-version OpenGL function library, which is the same name as the executed OpenGL function.

In some examples, in conjunction with fig. 2, the dynamic library file may be embodied as the dynamic library module 12 shown by a dashed box in fig. 2, and the high-version OpenGL function library may be embodied as the OpenGL API 13 in fig. 2; then in the solution shown in fig. 5, the step shown in S502 refers to the dashed arrow between the application 11 and the dynamic library module 12 in fig. 2, and the step shown in S503 refers to the solid arrow between the application 11 and the OpenGL API 13 in fig. 2.

According to the description of the above scheme, the embodiment of the present invention adds a dynamic library file, so that each of the low-version OpenGL functions discarded in the high-version OpenGL function library is realized by simulating the high-version OpenGL function, and when the application program runs to the low-version OpenGL function to be executed, the same-name function in the dynamic library file is called to complete execution, the discarded low-version OpenGL function in the application program source code does not need to be rewritten, and after the dynamic library file is loaded, the local high-version OpenGL function library can be adapted to run various application programs generated by the low-version OpenGL function, so that the development time is saved, and the development efficiency and compatibility of the application program are improved.

For the technical solution shown in fig. 5, the low-version OpenGL function included in the dynamic library file may be collected by pre-executing the application program, and in some examples, the method further includes:

screening and obtaining a low-version OpenGL function list needing to be simulated by a high-version OpenGL function according to an application program and a local high-version OpenGL function library;

and simulating each low-version OpenGL function in the function list by using a function in the high-version OpenGL function library, and packaging the low-version OpenGL function obtained by simulation into a dynamic library file.

For the above example, specifically, the obtaining, according to the application program and the local high-version OpenGL function library, a low-version OpenGL function list that needs to be simulated by the high-version OpenGL function includes:

comparing the application program with functions in the high-version OpenGL function library, and adding low-version OpenGL functions which are in the application program and do not exist in the high-version OpenGL function library to the function list; or,

and executing an application program in advance to call a high-version OpenGL function library through a graphical API (application programming interface), and adding a low-version OpenGL function in the error report information to the function list.

For the above specific example, in detail, since OpenGL is a detailed specification for graphics API, many functions and their parameter return types are specified, as well as behaviors to be implemented and pipeline operations. Functions used by application programs developed based on OpenGL have corresponding prototypes in OpenGL function library files. For example, functions in an application program developed based on low-version OpenGL include a glBegin function, a glEnd function, and a glVertex3f function, which all have corresponding codes and related data in their corresponding low-version OpenGL function libraries; assuming that the version of the high-version OpenGL function library is 4.6, taking the glBegin function as an example, since the glBegin function belongs to the low-version OpenGL function, the glBegin function does not appear in the high-version OpenGL function library, and optionally, comparing the function in the application program with the function in the high-version OpenGL function library, it is found that the glBegin function does not exist in the high-version OpenGL function library, that is, the glBegin function is a function that needs to be simulated by the high-version OpenGL function and is added to the low-version OpenGL function list that needs to be simulated by the high-version OpenGL function. Optionally, in the process of pre-executing the application program by calling the high-version OpenGL function library through the graphics API interface, since the glBegin function belongs to the low-version OpenGL and does not appear in the high-version OpenGL function library, an error message may be generated in the pre-execution process to indicate that the glBegin function appears in the high-version OpenGL function library, which also indicates that the glBegin function is to be simulated by the high-version OpenGL function and is added to the low-version OpenGL function list to be simulated by the high-version OpenGL function.

For the technical solution shown in fig. 5, in some examples, for a function in the high-version OpenGL function library, simulating each low-version OpenGL function in the function list, and packaging the simulated low-version OpenGL function into a dynamic library file includes:

introducing default shaders of a vertex Shader and a fragment Shader and corresponding input and output parameters before simulating a low-version OpenGL function by using a high-version OpenGL function;

according to the functions defined by the OpenGL functions, simulating each low-version OpenGL function in the function list by using one or more functions in a high-version OpenGL function library, and recording function information used by the high-version OpenGL function in the simulation process by using a global context; the function information includes at least: function call order, function call parameter order;

and packaging the low-version OpenGL function list simulated by the high-version OpenGL function into a dynamic library file.

Specifically, the low-version OpenGL function list that needs to be simulated by the high-version OpenGL function generally includes a function for drawing a basic geometric primitive, a matrix operation and geometric transformation function, a state setting function, and functions of illumination, material, and color types. The function for drawing the basic geometric primitives comprises glVertex3f, glBegin, glEnd, glNorma3f and glVertexPointer; the matrix operation and geometric transformation functions comprise glMatrix Mode, glLoadMatrix, glPushMatrix, glPopMatrix, glTranslatef, glRotatef and glScalef; state setting functions such as glEnable; functions of lighting, material, color type such as glLightfv, glMaterialfv, glColor3f, glColorPointer, etc. Since in the later version of OpenGL 3.3, the graphics rendering pipeline has been changed from a fixed pipeline to a programmable pipeline, and a vertex Shader and a fragment Shader are added in the programmable pipeline, the codes of the two modules need to be output in the high-version OpenGL, and based on the functions of the vertex Shader and the fragment Shader, part of functions in an application program developed by using the low-version OpenGL are abandoned, so that default shaders of vertices and fragments need to be introduced in the simulation function process of the high-version OpenGL, and necessary input and output information is as follows: the vertex shader related variables or parameters include the vertex position and color position, color, view matrix and projection matrix variables modelview _ matrix, project _ matrix, whether to turn on the illumination variable enable _ light, light source related variable light _ position, light _ ambient, light _ direction, light _ specific, material related variable material _ ambient, material _ direction, material _ specific, and fragment shader variable fragColor.

It should be noted that, in some examples, a single low-version OpenGL function needs to be simulated by using multiple high-version OpenGL functions according to the functions defined by the OpenGL function, and the two functions are in a one-to-many relationship. The input and output information of the low-version OpenGL function simulated in the high-version OpenGL has no direct relation with the default shape of the Vertex and the fragment introduced, and when there is a missing or parameter changing function call parameter (or called function call variable) in the high-version OpenGL simulation process and a Shader program is introduced in the high-version OpenGL, a global context, such as an OpenGL adapter context, is introduced to record related data, such as a function call order, a function call parameter order, a simulation Shader program introduced by the high-version OpenGL, a Vertex Buffer Object VBO (Vertex Buffer Object), a Vertex Array Object VAO (Vertex Array Object), and the like, in the high-version OpenGL simulation process. The low-version OpenGL function simulated in the high-version OpenGL may refer to a plurality of parameters in the OpenGL adapter context, and may be sequentially executed according to a call order of the parameters in a specific execution process. And after finishing all low-version OpenGL function lists needing simulation by using the high-version OpenGL functions, uniformly packaging the low-version OpenGL function lists into dynamic library files so as to facilitate subsequent execution and calling.

The process of simulating the low-version OpenGL function by the high-version OpenGL function needs to define required parameters in the OpenGL adapter context, where the required parameters may correspond to the input and output information of the Shader of the aforementioned introduced default vertex and segment, and the parameter code defined in the OpenGL adapter context is implemented as follows:

struct GLContext{

public:

GLuint program;

MatrixType currentMatrix = Project_Matrix;

uint32_t projectMatrixUniform;

uint32_t modeviewMatrixUniform;

vmath::mat4 currentMatrixData;

vmath::vec4 currentColor;

std::vector<Vertex> vertexes;

vmath::vec4 lightPosition,lightAmbient,lightDiffuse,lightSpecular;

vmath::vec4 materialAmbient[2],materialDiffuse[2],materialSpecular[2];

bool enableLight;

}

with reference to the technical solution shown in fig. 5, the present invention describes an operation process of simulating a low-version OpenGL function by using a high-version OpenGL function according to a function defined by a function using glBegin and a glEnd for drawing basic geometric primitives as an embodiment. Similar simulation methods and specific code implementation of other low-version OpenGL functions needing simulation are achieved, and detailed description is omitted.

The first embodiment is as follows: the glBegin function is a function that does not exist in the high-version OpenGL function library, and only exists in the low-version OpenGL function library, and its prototype in the low-version OpenGL is glBegin (GLenum mode), where the mode is a type of primitive to be drawn, and may be a drawing point GL _ POINTS, a drawing LINE segment GL _ LINES, a drawing head-to-tail LINE GL _ LINE _ LOOP, a drawing triangle GL _ TRIANGLES, a drawing quadrangle GL _ qualds, and so on. Simulating this function in high-version OpenGL requires the following steps to be completed: recording an incoming mode type in the glBegin function; 2. using a default rendering program (program) in the adapter; 3. updating data of a shader model matrix and a projection matrix which are currently rendered and writing the data into a rendering program; 4. the current glBegin rendered object is created and its primitive type is set to the incoming mode. In the embodiment of the present invention, the glBegin function implements simulation in the high-version OpenGL, and exemplary code for specific implementation is as follows:

Void _glBegin(uint32_t flag)

{

glUseProgram(glContext.program);

glUniformMatrix4fv(glContext.projection_matrix_uniform,1,GL_TRUE,

&glContext.projection_matrix[0][0]);

glUniformMatrix4fv(glContext.model_matrix_uniform,1,GL_TRUE,

&glContext.model_matrix[0][0]);

glContext.vertexDrawMode = flag;

}

referring to code implementation of the glBegin function in low-version OpenGL, i.e. the source code called the glBegin function, the code implementing the glBegin function in low-version OpenGL is as follows:

void GLAPIENTRY

_mesa_Begin(GLenum mode)

{

GET_CURRENT_CONTEXT(ctx);

struct vbo_context*vbo = vbo_context(ctx);

struct vbo_exec_context*exec = &vbo->exec;

int i;

// check if glBegin was called before and glEnd not called

if(_mesa_inside_begin_end(ctx)){

_mesa_error(ctx,GL_INVALID_OPERATION,"glBegin");

return;

}

if(ctx->NewState)

_mesa_update_state(ctx);

// determining the validity of the input parameter mode

GLenum error = _mesa_valid_prim_mode(ctx,mode);

if(error!= GL_NO_ERROR){

_mesa_error(ctx,error,"glBegin");

return;

}

if(exec->vtx.vertex_size&&!exec->vtx.attr[VBO_ATTRIB_POS].size){

vbo_exec_FlushVertices_internal(exec,FLUSH_STORED_VERTICES);

// current drawing primitive +1

i = exec->vtx.prim_count++;

exec->vtx.mode[i] = mode;

exec->vtx.draw[i].start = exec->vtx.vert_count;

exec->vtx.markers[i].begin = 1;

ctx->Driver.CurrentExecPrimitive = mode;

// marking the currently called function as glBegin ended

ctx->Exec = ctx->BeginEnd;

}

if(ctx->GLThread.enabled){

ctx->CurrentServerDispatch = ctx->Exec;

}elseif(ctx->CurrentClientDispatch == ctx->OutsideBeginEnd){

ctx->CurrentClientDispatch = ctx->Exec;

_glapi_set_dispatch(ctx->CurrentClientDispatch);

}else{

assert(ctx->CurrentClientDispatch == ctx->Save);

}

Comparing the code implementation of the glBegin function simulated in the high-version OpenGL with the source code implementation in the low-version OpenGL, it can be known that both code implementation manners are functions defined based on the glBegin function, but the glBegin function in the high-version OpenGL is a homonymous function simulated based on the high-version OpenGL function library, and the glBegin function in the low-version OpenGL is implemented by calling and driving an internal OpenGL context, so that the two code implementation manners have no comparability, and the function of the glBegin function can be implemented without referring to and modifying the source code of the glBegin function in the process of simulating the low-version OpenGL in function in the high-version OpenGL.

The second embodiment: the glEnd function is a function which does not exist in the high-version OpenGL function library, only exists in the low-version OpenGL function library, the prototype thereof is glEnd, the occurrence of the function means the end of one-time rendering and the glEnd function matches with the glBegin function, it can be understood that the occurrence of one glBegin means that a corresponding glEnd is needed later. Simulating the glEnd function in the high-version OpenGL needs to do the following work: 1. creating a VBO object (VBO object exists only in high version OpenGL), named VBO for example; 2. binding the VBO object; 3. load vertex data object to vbo;4. the method comprises the steps of appointing vbo that the position 0 in the data layout is data of a ternary float and activating, wherein the position 0 in the layout is a vertex position; 5. the method comprises the steps of appointing vbo that the position 1 in data layout is quaternary float data and activating, wherein the position 1 in the layout is a vertex color position; 6. the position No. 2 in the vbo data layout is appointed to be data of a ternary float and is activated, and the position No. 2 in the layout is normal information; 7. calling a glDrawAray function to draw; 8. call glDeleteBuffers to clear bound vbo. Exemplary code for simulating a concrete implementation of the glEnd function in high-version OpenGL is as follows:

void_glEnd()

{

creating an object vbo

glGenBuffers (1, & vbo)// allocating video memory space to vbo

glBindBuffer (GL _ ARRAY _ BUFFER, VBO)// VBO object with type GL _ ARRAY _ BUFFER

// load vertex data object to vbo

glBufferData(GL_ARRAY_BUFFER,glContext.vertexData.size()*sizeof(Vertex),

glContext.vertexData.data(),GL_STATIC_DRAW);

// appointing vbo data layout with position 0 as the data of a ternary float and activating, position 0 as the vertex position

glVertexAttribPointer(0,3,GL_FLOAT,GL_TRUE,0,nullptr);

glEnableVertexAttribArray(0);

// designating vbo data layout with position 1 as a quaternary float data and activating, position 1 as a vertex color position

glVertexAttribPointer(1,4,GL_FLOAT,GL_TRUE,0,(void*)(3*sizeof(float)));

glEnableVertexAttribArray(1);

// appointing vbo data layout with position 2 being the data of a ternary float and activating, position 2 being the normal information

glVertexAttribPointer(2,3,GL_FLOAT,GL_TRUE,0,(void*)(7*sizeof(float)));

glEnableVertexAttribArray(2);

// Call glDrawAray function drawing

glDrawArrays(glContext.vertexDrawMode,0,glContext.vertexData.size());

// Call glDeleteBuffers to clear bound vbo

glDeleteBuffers(1,&vbo);

}

In the example of the first embodiment and the second embodiment, where the glBegin and the glEnd functions are realized by simulating the high-version OpenGL function, each low-version OpenGL function in the low-version OpenGL function list may be completed by using a function simulation in the high-version OpenGL function library, and all the simulated low-version OpenGL functions may be packaged into a dynamic library file, and when the high-version OpenGL application program executes the glBegin and the glEnd functions in the low-version OpenGL, the simulated homonymous functions in the dynamic library file are preferentially executed.

For the technical solution shown in fig. 5, in some examples, the dynamic library file needs to be designated as a preloaded library before being called, and therefore, the preloading the dynamic library file before the application program is started includes:

preloading the dynamic library file in an LD-PRELOAD mode before starting an application program; or,

preloading the dynamic library file by adopting an ELF PLT HOOK mode before starting an application program; or,

and preloading the dynamic library file in an MHOOK mode before starting the application program.

For the above example, specifically, the three manners may be referred to as a HOOK manner, where the HOOK transliteration means that a call of a process to an API function is intercepted, so that an execution flow of the API is diverted to an implemented code segment, and a required function is implemented, where the function may be monitoring and repairing a system bug, or hijacking or other malicious behaviors. The LD _ load is an environment variable applicable to the Linux system, which can affect the links of the application program in the running process, and allows a debugging or a developer to customize the dynamic link library loaded preferentially before the application program runs. This function is mainly used to selectively load the same function in different dynamically linked libraries. By the environment variable, debugging or developing personnel can load other dynamic link libraries between the main program and the dynamic link library, even to cover the normal function library. Therefore, the better function can be used on the basis of no source code by the function, and other programs with specific purposes, such as programs required by debugging, can be injected into the developed application program; regarding the ELF PLT HOOK manner, the most commonly used implementation mechanism is GOT/PLT HOOK, which is mainly implemented by modifying the addresses of Global Offset Table (GOT) and Program Link Table (PLT) sections in the file structure of Executable and Linking Format (ELF). The ELF file format can be used as an executable file and a Shared library format, namely a common SO (Shared Object) file (.so), an Object file (.o), a coredumps file and the like, wherein the GOT/PLT HOOK is mainly used for realizing external calling for replacing a certain SO file and is suitable for Linux series platforms; regarding the MHOOK method, MHOOK adopts a SOCKET receiving and sending method in other process of HOOK, so it is written as a dynamic link library for Windows platform.

In the embodiment of the present invention, for example, the dynamic library file is preloaded in an LD _ PRELOAD manner, and a specific implementation manner is, for example, the glBegin function in the low-version OpenGL, where a dynamic library file encapsulated after simulation in the high-version OpenGL is assumed to be named mygl.so, and a function library of the high-version OpenGL is named gl.so, the following command may be input in a Linux command line to load the dynamic library file mygl.so:

export LD_PRELOAD="./myGL.so"

for the technical solution shown in fig. 5, in some examples, for the step S502, if the OpenGL function to be executed does not exist in the high-version OpenGL function library during the running process of the application program, a low-version OpenGL function that is simulated in the dynamic library file and is named as the OpenGL function to be executed is called, in a specific implementation process, still taking the above-mentioned glBegin function as an example, and in combination with the foregoing implementation manner that PRELOADs the dynamic library file in the LD _ PRELOAD manner, assuming that the application program to be executed on the high-version OpenGL is named as myApp, the following command may be input in the Linux command line to call the application program to be executed myApp:

./myApp

in the execution process of the application myApp, when a glBegin function is executed, as shown in fig. 6, it is first determined whether a glBegin function exists in the high-version OpenGL function library, and if not, a homonymous glBegin function of the low-version OpenGL simulated in the dynamic library mygl.so is called instead of a function in the high-version OpenGL function library gl.so. For the dynamic library file mygl.so, in the process of simulating the glBegin function in the high-version OpenGL, simulation needs to be completed by calling a function in the high-version OpenGL function library gl.so, and therefore the dynamic library file mygl.so needs to be connected to the high-version OpenGL function library gl.so.

For the technical solution shown in fig. 5, in some examples, as for the OpenGL function corresponding to the executed OpenGL function in the high-version OpenGL function library in S503, an OpenGL function in the high-version OpenGL function library, which is the same name as the executed OpenGL function, is directly called, in a specific implementation process, still referring to fig. 6, specifically, if the OpenGL function to be executed by the application myApp exists in the high-version OpenGL function library gl.so, a function in the high-version OpenGL function library gl.so corresponding to the OpenGL function exists directly is called.

Based on the same inventive concept of the foregoing technical solutions, referring to fig. 7, a device 700 for adapting a high-version OpenGL application to a low-version application according to an embodiment of the present invention is shown, where the device 700 includes: a preload section 701, a first calling section 702, and a second calling section 703; wherein,

the preloading part 701 is configured to preload the dynamic library file before the application program is started; the dynamic library file comprises a low-version OpenGL function which is obtained by simulating a high-version OpenGL function and is abandoned in the high-version OpenGL function;

the first calling part 702 is configured to, in a running process of the application program, call a low-version OpenGL function that is simulated in the dynamic library file and is named as the executed OpenGL function, if the executed OpenGL function does not exist in the high-version OpenGL function library;

the second calling portion 703 is configured to directly call an OpenGL function in the high-version OpenGL function library, which is the same name as the executed OpenGL function, if the executed OpenGL function exists in the high-version OpenGL function library.

In some examples, referring to fig. 8, the apparatus 700 further comprises: a screening part 704 and a simulation part 705; wherein,

the screening part 704 is configured to obtain a low-version OpenGL function list to be simulated by a high-version OpenGL function according to the application program and a local high-version OpenGL function library;

the simulation portion 705 is configured to simulate each low-version OpenGL function in the function list by using a function in the high-version OpenGL function library, and package the simulated low-version OpenGL function into a dynamic library file.

In some examples, the filtering portion 704 is configured to:

In some examples, the analog portion 705 is configured to:

according to the functions defined by the OpenGL functions, simulating each low-version OpenGL function in the function list by using one or more functions in a high-version OpenGL function library, and recording function information used by the high-version OpenGL function in the simulation process by using global context; the function information includes at least: function call order, function call parameter order;

In some examples, the preload portion 701 is configured to:

and preloading the dynamic library file in an MHOOK mode before starting an application program.

It is to be understood that, in this embodiment, "part" may be part of a circuit, part of a processor, part of a program or software, or the like, and may also be a unit, and may also be a module or a non-modular.

In addition, each component in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit. The integrated unit can be realized in a hardware mode, and can also be realized in a software functional module mode.

Based on the understanding that the technical solution of the present embodiment essentially or a part contributing to the prior art, or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, and include several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to execute all or part of the steps of the method of the present embodiment. And the aforementioned storage medium includes: a usb disk, a removable hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and various media capable of storing application program codes.

Therefore, this embodiment provides a computer storage medium, where a program for adapting a high-version OpenGL function to a low-version application program is stored, and when the application program is executed by at least one processor, the step of simulating the low-version application program by the high-version OpenGL function in the above technical solution is implemented.

It can be understood that the above exemplary technical solution of the apparatus 700 for adapting a low-version application program from a high-version OpenGL is the same as the technical solution of the method for adapting a low-version application program from a high-version OpenGL, and therefore, for details that are not described in detail in the above technical solution of the apparatus 700 for adapting a low-version application program from a high-version OpenGL, reference may be made to the above description of the technical solution of the method for adapting a low-version application program from a high-version OpenGL. The embodiments of the present invention will not be described in detail herein.

The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.

Claims

1. A method for adapting a high-version OpenGL function to a low-version application program, the method comprising:

if the executed OpenGL function exists in the high-version OpenGL function library, directly calling an OpenGL function which is the same name as the executed OpenGL function in the high-version OpenGL function library;

wherein the method further comprises:

simulating each low-version OpenGL function in the function list by using a function in a high-version OpenGL function library, and packaging the low-version OpenGL function obtained by simulation into a dynamic library file;

wherein, the simulating each low-version OpenGL function in the function list by using a function in the high-version OpenGL function library, and encapsulating the low-version OpenGL function obtained by the simulation into a dynamic library file includes:

2. The method of claim 1, wherein obtaining a list of low-version OpenGL functions to be simulated by a high-version OpenGL function according to an application and a local high-version OpenGL function library by screening comprises:

3. The method of claim 1, wherein preloading the dynamic library file before the application program is started comprises:

4. An apparatus for adapting a high-version OpenGL function to a low-version application, the apparatus comprising: the device comprises a preloading part, a first calling part and a second calling part; wherein,

the second calling part is configured to directly call an OpenGL function in the high-version OpenGL function library, which is the same name as the executed OpenGL function, if the executed OpenGL function exists in the high-version OpenGL function library;

wherein,

the device further comprises: a screening part and a simulation part;

the screening part is configured to obtain a low-version OpenGL function list needing to be simulated by a high-version OpenGL function according to an application program and a local high-version OpenGL function library in a screening mode;

the simulation part is configured to simulate each low-version OpenGL function in the function list by using a function in a high-version OpenGL function library, and package the low-version OpenGL function obtained through simulation into a dynamic library file;

wherein the analog portion is further configured to:

5. The apparatus of claim 4, wherein the preload portion is configured to:

6. A computing device, wherein the computing device comprises: a communication interface, a processor, a memory; the various components are coupled together by a bus system; wherein,

the memory for storing a computer program operable on the processor;

the processor, when executing the computer program, is configured to perform the steps of the method for adapting a high-version OpenGL function to a low-version application program according to any one of claims 1 to 3.

7. A computer storage medium storing a program for a high-version OpenGL function-compliant low-version application, the program, when executed by at least one processor, implementing the steps of the method for the high-version OpenGL function-compliant low-version application as recited in any one of claims 1-3.