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


On 1 June 2011 07:46, Shariq Hasnain <shariq.hasnain@linaro.org> wrote:
Hi Nigel,

 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 ?


On 29 May 2011 00:35, Nigel Stewart <nstewart@nvidia.com> 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:

GLEW_SUPPORT_OPENGL          (compatibility)

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.

- Nigel

On 5/25/11 12:53 AM, Shariq Hasnain wrote:
Hi All,Nigel,

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.

 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
> and extensions. The memory usage will be minimum and the enum would be filtered
> 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).

2. Expose all desktop GL and ES extensions and core spec and its corresponding
> function pointers(global variables). But then for embedded system there would
> be many global variables( which will be not be required), unnecessary increasing
> the memory usage.

3. Expose all desktop GL and ES extensions and core  spec but try to do some
> compile time optimizations(at compile time as we know that desktop extensions
> 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 <nstewart@nvidia.com <mailto:nstewart@nvidia.com>> wrote:


   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.

   - Nigel

   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 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


       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.