I have further extended OpenGL ES support to GLEW.
I have generated glew having enum and function entry points of both OpenGL and OpenGL ES.
The code can be cloned using:
git clone git://git.linaro.org/people/shariqhasnain/glew-es_core.git
This glew src code is rebased on the latest glew-1.7.0 version. So it's better to clone then pull on my previous change set.
Following are the various ways in which glew can be used:
- glew.h will give the enum and entrypoints from both OpenGL and OpenGL ES.
- If the flag GLEW_NO_ES is enabled then only desktop OpenGL is present (OpenGL ES get excluded).
- To include pure OpenGL ES we need to define the flag GLEW_ES_ONLY before include the header file glew.h. This will internally include the file glesew.h. However glesew.h should not be explicitly included by the application.
-The EGL is made optional in glew lib.If the flag GLEW_INC_EGL is enabled then EGL is part of glew lib. The header file eglew.h needs to be included.
To test(for OpenGL ES 2.0) I have added a temporary config file Makefile.arm-linux in the last commit.Loading of OpenGL ES lib and getting the function pointers have been added for Linux. To link with OpenGL ES 2.0 or 1.1 the flags GLEW_USE_LIB_ES20 or GLEW_USE_LIB_ES11 need to be enabled respectively. (The later plan is to pass the lib path via Makefile instead of defining it in glew.c through these flags).
- The file "Makefile.arm-linux" (added in config folder) is present to compile glew for ARM Linux
Steps for building glew for ARM-Linux ES 2.0:
1. export following environment variables:
COMPILER_PATH : Path of the compiler
INC_PATH : Include files path
LIB_PATH : Opengl/egl/x11 library path
ADDITIONAL_LIB_DEPENDENCY_PATH: Path for any additional dependencies of the libs.
2. Build command :
- To build generic(INCLUDING entry point and enums of desktop and ES OpenGL) glew for OpenGL ES 2.0 along with EGL(need to include eglew.h in application):
make BUILD_GLEW_ES20=yes BUILD_GLEW_EGL=yes
- To build generic glew for OpenGL ES 2.0 without EGL(need to include egl.h in application):
- To build glew for Desktop OpenGL(INCLUDING entry point and enums of ES)
- To build glew for Desktop OpenGL(EXCLUDING entry point and enums of ES)
- If needed to run using emulator on desktop kindly remove '-mfpu=vfp -mfloat-abi=softfp' from makefile.arm-linux
glewinfo and visualinfo provide support for ES also(at present only for Linux using X11)
Since need to provide support for both desktop OpenGL and OpenGL ES, only those functions which are common to both OpenGL 1.1 and OpenGL ES 1.0 are NOT defined as function pointers.
glewContextIsSupported /glewIsSupported has been fixed.
Thing need to be done:
- Pass OpenGL ES library path via Makefile.
- GLAPIENTRY and GLAPIENTRY defines need to be changed to support all desktop and ES platform properly.(Right now the desktop definition is being used which works fine for Linux.)
- Loading of OpenGL ES and/or EGL for other OS.
- Proper Makefile need to be added.
Kindly provide your feedback.
Hi All, Nigel,
In continuation of adding OpenGL ES support to GLEW lib, I have made few more changes.
The change sets add support for the case of GLEW_ES_ONLY(i.e. only supporting OpenGL ES).
The following have been done:
- glesew.h is created for targeting only OpenGL ES case.
- eglew.h is created for EGL.
- glesew.h in included via glew.h (if GLEW_ES_ONLY is defined glesew.h get included, so only glew.h needs to be included by apps).
- All the ES and EGL related initializations are done in glew.c file itself.
Next step is to create a general GLEW (supporting desktop + optional ES) .
The code can be cloned using(same repository):
git clone git://git.linaro.org/people/shariqhasnain/glew-es_core.git
ShariqOn 1 June 2011 07:46, Shariq Hasnain <email@example.com> wrote:
Looking at the various cases to be supported I agree it's better to generate different header files instead of filling glew.h file with #ifdef.
I will first generate the header glesew.h and eglew.h which will be used as the header for GLEW support for ES_ONLY cases (simpler for starting).
I have one doubt by GLEW_SUPPORT_OPENGL do you mean support for OpenGL(desktop) core + extensions support ?
ShariqOn 29 May 2011 00:35, Nigel Stewart <firstname.lastname@example.org> wrote:
These are good questions. I don't have a firm opinion one
way or another yet, but some comments...
I can see the appeal in code being able to simply #include
<GL/glew.h> and target either desktop OpenGL or ES, I guess
with defines for GLEW_ES_ONLY or GLEW_NO_ES for projects
targeting purely one or the other.
In terms of linking, libGLEW (desktop + optional ES) and a
libGLEWes lighter weight ES-only flavor. I guess that would
mesh reasonably with MX. The default stock-standard GLEW
would be a works-everywhere proposition, unless specifically
built to exclude ES or whatever else.
In fact, I tend to use a subset of GLEW specifically
to minimize the binary size of a whole bunch of programs
that link GLEW statically. This branch exists in the
Sourceforge GLEW git repository as subset. It adds the
burden of having to specify the set of desired extensions
at compile-time. (Which I find workable)
The challenge in this scheme would be to generate glew.h
in a manner that completely and correctly limits the
enums and entry points based on GLEW_ES_ONLY and GLEW_NO_ES.
And maintaining that going forward. I don't think there
is much support in the current perl scripts to cross-check
lists of enums etc against other lists, along with the
complication that a lot of core OpenGL stuff in GLEW is done
via extensions, rather than explicitly for each OpenGL version.
An alternative might be to have a ES wrangler header GL/glesew.h
that gets used either explicitly by direct #inclusion or
implicitly via glew.h when GLEW_ES_ONLY is defined. That
leaves a simpler problem of conditionally compiling glew.h
for GLEW_NO_ES - wrapping the ES-specifics only.
It probably makes sense to do the GLEW_ES_ONLY scenario first -
targeting mobile deployment, and GLEW_NO_ES second as a "nice to
Another way to factor the defines might be:
With the default being GLEW_SUPPORT_OPENGL if neither of the
others specified, and in principle any combination being
supportable. But I think generating separate headers for
each supported combination (and multiplexing via glew.h)
might be better than #ifdefing glew.h like crazy.
In all of this it's ES 2.0 that's of more interest, I'm
neutral about ES 1.0, don't mind much either way.
On 5/25/11 12:53 AM, Shariq Hasnain wrote:
The plan is that applications would use only a single header "glew.h" for ES and desktop.
> GLEW usage for ES should be as similar to that of desktop GLEW.
> and extensions. The memory usage will be minimum and the enum would be filtered
But how the extensions can be exposed, there are few option:
1. There could be 2 lib one exposing ONLY desktop and the other ONLY ES core
> automatically. But then the applications (which targets both desktop and ES
> and wants to check extensions from both) has to take care that it compiles
> for both for which it might need to use some macro(may be same macro which
will be used inside GLEW lib).> function pointers(global variables). But then for embedded system there would
2. Expose all desktop GL and ES extensions and core spec and its corresponding
> be many global variables( which will be not be required), unnecessary increasing
> the memory usage.
> compile time optimizations(at compile time as we know that desktop extensions
3. Expose all desktop GL and ES extensions and core spec but try to do some
> are not supported by ES and vice-versa) so that memory usage can be decreased.
> But how much it can be done need to be checked.
For the 2 and 3 case we need to take care of variables coming from both desktop and ES.
Any suggestion ?
On 24 May 2011 00:37, Nigel Stewart <email@example.com <mailto:firstname.lastname@example.org>> wrote:The earlier option was downloading all the extensions recursively from www.khronos.org <http://www.khronos.org> <http://www.khronos.org>. even when specified the path
I looked over the changes, changes seem uncontroversial to me.
My git wizardry is a bit limited, but I'll have a bit of a think
about the correct way to selectively bring changes into the
GLEW repository, such as --include vs --no-parent for wget.
So the idea is for glew.h to expose BOTH desktop GL and
ES together? And glewInit will detect and load the
relevant API? The idea is to filter all the enums to
ensure they're not duplicated? Just wondering.
Keep up the good work.
On 5/23/11 6:03 AM, Shariq Hasnain wrote:
Hi All, Nigel,
In continuation of the discussion I had regarding adding ES and EGL support to GLEW,I have done the following things :
1 - Added core files of ES and EGL.
The OpenGL ES version 1.0 and EGL version 1.1 are added in the auto/src folder in the files glew_head_es.h and eglew_head.h respectively.
The egl header file 'egl.h' for version 1.0 is not present in khronos website(Actually it is there but it contains the egl.h for version 1.3), so this version has not been added.
The higher versions of ES and EGL are added in core_es and core_egl folders respectively.
2- The ES and EGL extensions specs are downloaded and parsed to create the desciptors.
To create the descriptors files from the extensions files two new scipts are added:
update_ext_egl.sh and update_ext_es.sh.
Also the update_registry.sh has been modified to use "--include" option instead of the earlier "--no-parent" options.
The source code can be cloned using "git clone /git://git.linaro.org/people/shariqhasnain/glew-es_core.git <http://git.linaro.org/people/shariqhasnain/glew-es_core.git>
Kindly go through it and provide your feedback.
My next plan is to generate the header files having ES and EGL support.
glew.h will have ES related stuff and eglew.h will be generated similar to glxew.h/wglew.h.