CN115167949A - Method, device and medium for adapting high-version OpenGL function to low-version application program - Google Patents
Method, device and medium for adapting high-version OpenGL function to low-version application program Download PDFInfo
- Publication number
- CN115167949A CN115167949A CN202211095506.6A CN202211095506A CN115167949A CN 115167949 A CN115167949 A CN 115167949A CN 202211095506 A CN202211095506 A CN 202211095506A CN 115167949 A CN115167949 A CN 115167949A
- Authority
- CN
- China
- Prior art keywords
- version
- function
- opengl
- opengl function
- low
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 65
- 230000008569 process Effects 0.000 claims abstract description 35
- 230000006870 function Effects 0.000 claims description 384
- 230000015654 memory Effects 0.000 claims description 38
- 238000004088 simulation Methods 0.000 claims description 22
- 239000012634 fragment Substances 0.000 claims description 12
- 230000036316 preload Effects 0.000 claims description 9
- 238000004806 packaging method and process Methods 0.000 claims description 8
- 238000012216 screening Methods 0.000 claims description 8
- 238000004891 communication Methods 0.000 claims description 6
- 238000004590 computer program Methods 0.000 claims description 5
- 238000009877 rendering Methods 0.000 description 33
- 238000011161 development Methods 0.000 description 11
- 239000011159 matrix material Substances 0.000 description 11
- 238000012545 processing Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 8
- 239000000463 material Substances 0.000 description 6
- 230000003213 activating effect Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 239000011800 void material Substances 0.000 description 4
- 238000013459 approach Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000005286 illumination Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 101100495270 Caenorhabditis elegans cdc-26 gene Proteins 0.000 description 1
- 241000699670 Mus sp. Species 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000002156 mixing Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44536—Selecting among different versions
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
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 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.
Description
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 version, the OpenGL version used in the current graphics development is higher and higher, and 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 run on 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 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.
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 a 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 homonymous 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, so that the development time is saved, and the development efficiency and 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 of 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 solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.
Referring to FIG. 1, which illustrates a computer system 100 capable of implementing aspects of embodiments of the present invention, it is noted that the illustrated system is but one example of a possible system and that embodiments of the present invention may be implemented in any of a variety of 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 CPU10 may include one or more graphics rendering instructions (which may also be understood as one or more of the graphics contained in a frame of a screen to be rendered), which may conform to a graphics Application Programming Interface (API), such as an open graphics library API (OpenGL API), an open graphics library embedding 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, which will be exemplified by the GL API in the following description of the present invention.
GPU 20 may be configured to perform graphics operations to render one or more graphics primitives to display 41 for presentation. As will be appreciated, CPU10, by controlling GPU driver 14, translates OpenGL-defined graphics rendering instructions into graphics rendering commands that are readable by GPU 20, and then GPU 20 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 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 key components CPU10, GPU 20, and memory 30 in the computer system assembly 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, the CPU10, GPU 20, memory 30, and their corresponding internal components. CPU10 includes an application 11, an OpenGL API 13, and a GPU driver 14, where each of OpenGL API 13 and GPU driver 14 may serve one or more applications, in some examples, openGL API 13 and GPU driver 14 may be implemented as hardware units of CPU10, 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 rather than 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. The 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, which is specifically stored as 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 synthesis). 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 approach, CPU10 issues instructions through application 11 via graphics OpenGL API 13 to GPU driver 14, 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 a graphics rendering command from CPU10, GPU 20 may execute the graphics processing pipeline using processor cluster 22 in order to decode the command and configure the graphics processing pipeline to perform the operation specified in the graphics rendering command. Specifically, GPU 20 needs to implement a rendering operation on graphics by means of a graphics rendering pipeline during implementation or running of an application, and 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, where 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 shading and testing and mixing, and the detail of the module and operation corresponding to each step is shown in fig. 3 and 4. 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, the Shader script needs to be compiled, then the compiled Shader is mounted on the 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", 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 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.
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 according to the application program and a local high-version OpenGL function library to obtain a low-version OpenGL function list needing to be simulated by a high-version OpenGL function;
and simulating each low-version OpenGL function in the function list by using functions in the high-version OpenGL function library, and packaging the low-version OpenGL functions obtained through 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 program interface), and adding a low-version OpenGL function in error reporting 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 and the default Vertex and fragment introduced in the foregoing have no direct relationship, and when there is a missing or changed function call parameter (or called function call variable) in the simulation process of the high-version OpenGL and a Shader program is introduced in the high-version OpenGL, a global context is introduced, for example, an OpenGL adapter context, which is used to record related data such as function call order, function call parameter order, simulation Shader program introduced by the high-version OpenGL, vertex Buffer Object VBO (Vertex Buffer Object), vertex Array Object VAO (Vertex Array Object), and the like in the simulation process of the high-version OpenGL. 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 a required parameter in the OpenGL adapter context, where the part of the parameter 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 glEnd functions for drawing basic geometric primitives as an embodiment. Similar to the simulation methods and specific code implementation of other low-version OpenGL functions needing simulation, 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 GL _ LINES, a drawing head-to-tail LINE GL _ LINE _ LOOP, a drawing triangle GL _ triangle, a drawing quadrilateral GL _ qualds, or the like. 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 implementing the simulation specifically 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 that can be called the glBegin function, the code for 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 (the VBO object exists only in the high-version OpenGL), named VBO for example; 2. binding a VBO object; 3. loading a vertex data object to a vbo;4. appointing the position 0 in the vbo data layout as the data of a ternary float and activating, wherein the position 0 in the layout is the vertex position; 5. appointing the position No. 1 in the layout of the vbo data as the data of a quaternary float and activating, wherein the position No. 1 in the layout is the vertex color position; 6. appointing the position No. 2 in the layout of the vbo data as the data of a ternary float and activating, wherein the position No. 2 in the layout is the normal information; 7. calling a glDrawAray function for drawing; 8. the glDeleteBuffers is called to clean the 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);/allocate 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);
V/specify that position 0 in the vbo data layout is data of a ternary float and activated, position 0 is the vertex position
glVertexAttribPointer(0,3,GL_FLOAT,GL_TRUE,0,nullptr);
glEnableVertexAttribArray(0);
V/appointing the position No. 1 in the vbo data layout as the data of a quaternary float and activating, the position No. 1 is the vertex color position
glVertexAttribPointer(1,4,GL_FLOAT,GL_TRUE,0,(void*)(3*sizeof(float)));
glEnableVertexAttribArray(1);
V/specify that position 2 in the vbo data layout is data of a ternary float and activated, and position 2 is 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 by adopting 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 an application program.
For the above example, specifically, the three manners may be referred to as a HOOK manner, where the HOOK transliteration means intercepting a call of a process to an API function, so that an execution flow of the API is diverted to a code segment to be implemented, thereby implementing a required function, where the function may be monitoring and repairing a system bug, or hijacking or other malicious behavior. 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 mode, MHOOK adopts a SOCKET receiving and sending method in HOOK in other processes, so it is written as a dynamic link library for Windows series platforms.
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.
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 solution, referring to fig. 7, an apparatus 700 for adapting a low-version application program by a high-version OpenGL according to an embodiment of the present invention is shown, where the apparatus 700 includes: a preloading part 701, a first calling part 702 and a second calling part 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:
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.
In some examples, the analog portion 705 is configured to:
introducing default shaders of a vertex Shader and a fragment Shader and corresponding input and output parameters thereof 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 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.
In some examples, the preload section 701 is configured to:
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.
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 partly contributes to the prior art, or all or part of the technical solution may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling 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 U disk, a removable hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other 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 the application program, when executed by at least one processor, implements the steps of the method for simulating a low-version application program by the high-version OpenGL function in the above technical solution.
It can be understood that, the above exemplary technical solution of the apparatus 700 for adapting to a low-version application program of a high-version OpenGL version belongs to the same concept as the above technical solution of the method for adapting to a low-version application program of a high-version OpenGL version, and therefore, for details that are not described in detail in the above technical solution of the apparatus 700 for adapting to a low-version application program of a high-version OpenGL version, reference may be made to the above description of the technical solution of the method for adapting to a low-version application program of a high-version OpenGL version. 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 (10)
1. A method for adapting a high-version OpenGL function to a low-version application program, the method comprising:
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 name 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.
2. The method of claim 1, further comprising:
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.
3. The method of claim 2, 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:
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.
4. The method of claim 2, wherein simulating each low-version OpenGL function in the function list by using a function in a high-version OpenGL function library, and packaging the simulated low-version OpenGL function as a dynamic library file comprises:
introducing default shaders of a vertex Shader and a fragment Shader and corresponding input and output parameters thereof 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 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.
5. The method of claim 1, wherein preloading the dynamic library file before the application program is started comprises:
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.
6. An apparatus for adapting a high-version OpenGL function to a low-version application program, the apparatus comprising: 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.
7. The apparatus of claim 6, further comprising: a screening part and a simulation part; wherein,
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.
8. The apparatus of claim 6, wherein the preload portion is configured to:
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 an application program.
9. 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 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, 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 5.
10. A computer storage medium storing a program for adapting a high-version OpenGL function to a low-version application, the program, when executed by at least one processor, implementing the steps of the method for adapting a high-version OpenGL function to a low-version application as claimed in any one of claims 1-5.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211095506.6A CN115167949B (en) | 2022-09-08 | 2022-09-08 | Method, device and medium for adapting high-version OpenGL function to low-version application program |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211095506.6A CN115167949B (en) | 2022-09-08 | 2022-09-08 | Method, device and medium for adapting high-version OpenGL function to low-version application program |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115167949A true CN115167949A (en) | 2022-10-11 |
CN115167949B CN115167949B (en) | 2022-12-06 |
Family
ID=83482362
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211095506.6A Active CN115167949B (en) | 2022-09-08 | 2022-09-08 | Method, device and medium for adapting high-version OpenGL function to low-version application program |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115167949B (en) |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2418576A1 (en) * | 2010-08-11 | 2012-02-15 | Sony Computer Entertainment Europe Ltd. | Multi-platform development tool and method |
US20160011890A1 (en) * | 2013-03-19 | 2016-01-14 | Huawei Technologies Co., Ltd. | Compatibility method and apparatus |
CN108509240A (en) * | 2018-03-09 | 2018-09-07 | 广东欧珀移动通信有限公司 | Picture method for drafting and Related product |
US10074206B1 (en) * | 2017-05-23 | 2018-09-11 | Amazon Technologies, Inc. | Network-optimized graphics library for virtualized graphics processing |
CN110659024A (en) * | 2019-08-21 | 2020-01-07 | 北京达佳互联信息技术有限公司 | Graphic resource conversion method, apparatus, electronic device and storage medium |
CN112764797A (en) * | 2021-01-06 | 2021-05-07 | 浙江大华技术股份有限公司 | Software compatibility detection method and device, electronic device and storage medium |
CN113485773A (en) * | 2021-06-24 | 2021-10-08 | 锐捷网络(苏州)有限公司 | Data processing method, device and system |
CN113838180A (en) * | 2020-06-24 | 2021-12-24 | 华为技术有限公司 | Rendering instruction processing method and related equipment thereof |
CN114661324A (en) * | 2022-03-14 | 2022-06-24 | 稿定(厦门)科技有限公司 | Compiling and rendering method and device of special effect plug-in and storage medium |
-
2022
- 2022-09-08 CN CN202211095506.6A patent/CN115167949B/en active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2418576A1 (en) * | 2010-08-11 | 2012-02-15 | Sony Computer Entertainment Europe Ltd. | Multi-platform development tool and method |
US20160011890A1 (en) * | 2013-03-19 | 2016-01-14 | Huawei Technologies Co., Ltd. | Compatibility method and apparatus |
US10074206B1 (en) * | 2017-05-23 | 2018-09-11 | Amazon Technologies, Inc. | Network-optimized graphics library for virtualized graphics processing |
CN108509240A (en) * | 2018-03-09 | 2018-09-07 | 广东欧珀移动通信有限公司 | Picture method for drafting and Related product |
CN110659024A (en) * | 2019-08-21 | 2020-01-07 | 北京达佳互联信息技术有限公司 | Graphic resource conversion method, apparatus, electronic device and storage medium |
CN113838180A (en) * | 2020-06-24 | 2021-12-24 | 华为技术有限公司 | Rendering instruction processing method and related equipment thereof |
CN112764797A (en) * | 2021-01-06 | 2021-05-07 | 浙江大华技术股份有限公司 | Software compatibility detection method and device, electronic device and storage medium |
CN113485773A (en) * | 2021-06-24 | 2021-10-08 | 锐捷网络(苏州)有限公司 | Data processing method, device and system |
CN114661324A (en) * | 2022-03-14 | 2022-06-24 | 稿定(厦门)科技有限公司 | Compiling and rendering method and device of special effect plug-in and storage medium |
Non-Patent Citations (1)
Title |
---|
王有禄等: "Android***下基于NDK方式的图形开发", 《计算机***应用》 * |
Also Published As
Publication number | Publication date |
---|---|
CN115167949B (en) | 2022-12-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10949944B2 (en) | System and method for unified application programming interface and model | |
CN107209923B (en) | Hybrid rendering in graphics processing | |
US9117302B2 (en) | Switching between direct rendering and binning in graphics processing using an overdraw tracker | |
CN108027955B (en) | Techniques for storage of bandwidth-compressed graphics data | |
EP3420536A1 (en) | Start node determination for tree traversal for shadow rays in graphics processing | |
US20150348224A1 (en) | Graphics Pipeline State Object And Model | |
CN113342703B (en) | Rendering effect real-time debugging method and device, development equipment and storage medium | |
US10417791B2 (en) | Multi-step texture processing with feedback in texture unit | |
CN115357516B (en) | Method, device and equipment for debugging rendering problem and storage medium | |
EP3178061A1 (en) | High order filtering in a graphics processing unit | |
CN113256764A (en) | Rasterization device and method and computer storage medium | |
US20160180548A1 (en) | Indefinite texture filter size for graphics processing | |
CN114972607A (en) | Data transmission method, device and medium for accelerating image display | |
CN106575428B (en) | High order filtering in a graphics processing unit | |
CN113393585A (en) | Rendering problem positioning method and device, positioning equipment and storage medium | |
CN116909511A (en) | Method, device and storage medium for improving double-buffer display efficiency of GPU (graphics processing Unit) | |
CN115167949B (en) | Method, device and medium for adapting high-version OpenGL function to low-version application program | |
US10157443B1 (en) | Deferred batching of incremental constant loads | |
CN117472336B (en) | Code generating device based on program API, method, equipment and medium thereof | |
Wang | XNA-like 3D Graphics Programming on the Raspberry Pi |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address | ||
CP03 | Change of name, title or address |
Address after: Room 301, Building D, Yeda Science and Technology Park, No. 300 Changjiang Road, Yantai Area, China (Shandong) Pilot Free Trade Zone, Yantai City, Shandong Province, 265503 Patentee after: Xi'an Xintong Semiconductor Technology Co.,Ltd. Address before: Room T1 301, Taiwei intelligent chain center, No. 8, Tangyan South Road, high tech Zone, Xi'an, Shaanxi 710065 Patentee before: Xi'an Xintong Semiconductor Technology Co.,Ltd. |