I am trying to build the OpenGL SO lib from android sources (libGLESv2.so) and i would like a little bit more understanding of the internal mechanism of Android OpenGL ES and the flow.
Please correct me where i am wrong:
I know that in windows a developer includes gl.h and static link to OpenGL32(64).lib (which in turn dynamically link to OpenGL32.dll (probably there is a way to dynamic linke to OpenGL32.dll by the developer but that’s not important).
The developer is exposed to the declaration of OpenGL API’s but the implementation which i assume to be HW dependent.
The same scenario, Android: assuming developer import .opengl.GLES20 and calls the following method: GLES20.glTexEnvf(….
I would like to know what’s going on behind the scenes in android (maybe Linux is better for an Android beginner).
the implementation which reside in opengl/java/android/opengl/GLES20.java source calls the native C function glTexEnvf which unlike windows we have it’s implementation which reside in opengl/libagl.
Is it true?
In any case what is the GLES2_dbg library in /libs/GLES20_dbg? i can see there some kind of debug implementation with python scripts… are they to compile OpenGL debug version?
What are the .in files and gl2.cpp file in /libs/GLES20?
Where are the HW calls? does each GPU vendor sends his libGLESv2 implementation for HW calls as i saw the libGLESv2_adreno200.so in my xperia arc?
Please help me understand the flow. If you have a link which explain this structure even in Linux it will be great.
In Windows opengl32.dll contains both a software rasterizer fallback and so called trampolines into the OpenGL-ICD shipping with the GPU driver.
The opengl32.lib ist not really a library but a cross reference for the linker to add entries into the executable that make the OS dynamically link the program against the DLL at runtime.
On Linux in the current implementation the libGL.so ships with the graphics driver and contains the vendor specific implementations. The linkers used in *nix systems don’t rely on an extra crossreferencing .lib but can take the information directly from the .so
On Android the libGLES you see is only a kind of placeholder to make linking possible. But ultimately the GPU vendor provides the proper library, which drops into the place where the phony libGLES resided.
The .in files are nothing special in particular. They are input files used by configure and build systems to build source files from a template (the .in file) with fields filled in by configuration values.