GLEW support for OpenGL ES /EGL.
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
GLEW support for OpenGL ES /EGL.
by Shariq Hasnain
::
Rate this Message:
Dear All,
I was thinking for extending the glew lib to support OpenGL ES and EGL similarly to that of OpenGL and WGL/GLX. Since OpenGL ES is popularly used in embedded domain it will be a good idea to do so. -It will provide run time determination of OpenGL ES/EGL extension supported in the target platform. -This will also make the porting of OpenGL applications using glew to OpenGL ES easier as the GLEW related code need not be modified individually for each applications. The idea is to have: - Run time check for OpenGL ES core/extension functions similar as existing OpenGL core/extension support in GLEW library. - Run time check for EGL core/extension functions similar as existing GLX/WGL support in GLEW library. - Since EGL is used for Graphics resource management in embedded, GLX and WGL support will not be provided. Kindly provide your feedback. Thanks, Shariq ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Nigel Stewart-2
::
Rate this Message:
Hi Shariq,
There was some previous discussion about ES and EGL: http://sourceforge.net/mailarchive/message.php?msg_id=25658645 http://sourceforge.net/mailarchive/message.php?msg_id=25660636 http://sourceforge.net/mailarchive/message.php?msg_id=25781001 http://sourceforge.net/mailarchive/message.php?msg_id=25964732 http://sourceforge.net/apps/mediawiki/openreng/index.php?title=External_Library_Dependencies#GLEW https://openreng.svn.sourceforge.net/svnroot/openreng/dependencies/_glew/ In a nutshell I think we agree that GLEW ought to support ES and EGL. But nobody has stepped up to do the work yet. I havn't done a diff with the openreng fork for a while, to be clear about that. But it could be a useful starting point. - Nigel On 2/2/11 3:46 AM, Shariq Hasnain wrote: > Dear All, > > I was thinking for extending the glew lib to support OpenGL ES and EGL similarly to that of OpenGL and WGL/GLX. > Since OpenGL ES is popularly used in embedded domain it will be a good idea to do so. > -It will provide run time determination of OpenGL ES/EGL extension supported in the target platform. > -This will also make the porting of OpenGL applications using glew to OpenGL ES easier as the GLEW related code need not be modified individually for each applications. > > The idea is to have: > - Run time check for OpenGL ES core/extension functions similar as existing OpenGL core/extension support in GLEW library. > - Run time check for EGL core/extension functions similar as existing GLX/WGL support in GLEW library. > - Since EGL is used for Graphics resource management in embedded, GLX and WGL support will not be provided. > > > Kindly provide your feedback. > > Thanks, > Shariq > ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Shariq Hasnain
::
Rate this Message:
Hi Nigel/All, After going through the code I have found that significant work has been done for adding the OpenGL ES 2.0 support to glew lib. However still few things are missing like adding the runtime entrypoint for OpenGL ES extension functions, adding support for EGL to glew. However for sometime there has been no update. So I would like to extend the implementation further. Kindly provide your feedback. Thanks, Shariq On 5 February 2011 13:33, Nigel Stewart <nstewart@...> wrote: Hi Shariq, ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Nigel Stewart-2
::
Rate this Message:
> However for sometime there has been no update. So I would like to extend the implementation further.
> Kindly provide your feedback. Sounds good. One suggestion I have is adding GLES_VERSION_1_0, GLES_VERSION_1_1, GLES_VERSION_2_0. The headers are available over at khronos.org: http://www.khronos.org/registry/gles/ Also, EGL_VERSION_1_0, EGL_VERSION_1_1, EGL_VERSION_1_2, EGL_VERSION_1_3, EGL_VERSION_1_4. http://www.khronos.org/registry/egl/ After that it's a matter of parsing extension specs, and so on. - Nigel > On 5 February 2011 13:33, Nigel Stewart <nstewart@... <mailto:nstewart@...>> wrote: > > Hi Shariq, > > There was some previous discussion about ES and EGL: > > http://sourceforge.net/mailarchive/message.php?msg_id=25658645 > http://sourceforge.net/mailarchive/message.php?msg_id=25660636 > http://sourceforge.net/mailarchive/message.php?msg_id=25781001 > http://sourceforge.net/mailarchive/message.php?msg_id=25964732 > > http://sourceforge.net/apps/mediawiki/openreng/index.php?title=External_Library_Dependencies#GLEW > https://openreng.svn.sourceforge.net/svnroot/openreng/dependencies/_glew/ > > In a nutshell I think we agree that GLEW ought to > support ES and EGL. But nobody has stepped up to > do the work yet. I havn't done a diff with the > openreng fork for a while, to be clear about that. > But it could be a useful starting point. > > - Nigel > > > On 2/2/11 3:46 AM, Shariq Hasnain wrote: > > Dear All, > > I was thinking for extending the glew lib to support OpenGL ES and EGL similarly to that of OpenGL and WGL/GLX. > Since OpenGL ES is popularly used in embedded domain it will be a good idea to do so. > -It will provide run time determination of OpenGL ES/EGL extension supported in the target platform. > -This will also make the porting of OpenGL applications using glew to OpenGL ES easier as the GLEW related code need not be modified individually for each applications. > > The idea is to have: > - Run time check for OpenGL ES core/extension functions similar as existing OpenGL core/extension support in GLEW library. > - Run time check for EGL core/extension functions similar as existing GLX/WGL support in GLEW library. > - Since EGL is used for Graphics resource management in embedded, GLX and WGL support will not be provided. > > > Kindly provide your feedback. > > Thanks, > Shariq > > > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Shariq Hasnain
::
Rate this Message:
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. even when specified the path "http://www.khronos.org/registry/gles/". The source code can be cloned using "git clone git://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. Thanks, Shariq
On 18 February 2011 22:01, Nigel Stewart <nstewart@...> wrote:
------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Nigel Stewart-2
::
Rate this Message:
Sariq,
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>. even when specified the path "http://www.khronos.org/registry/gles/". > > 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. > > > Thanks, > Shariq > > > On 18 February 2011 22:01, Nigel Stewart <nstewart@... <mailto:nstewart@...>> wrote: > > However for sometime there has been no update. So I would like to extend the implementation further. > Kindly provide your feedback. > > > Sounds good. > > One suggestion I have is adding GLES_VERSION_1_0, GLES_VERSION_1_1, > GLES_VERSION_2_0. > > The headers are available over at khronos.org <http://khronos.org>: > http://www.khronos.org/registry/gles/ > > Also, EGL_VERSION_1_0, EGL_VERSION_1_1, EGL_VERSION_1_2, > EGL_VERSION_1_3, EGL_VERSION_1_4. > > http://www.khronos.org/registry/egl/ > > After that it's a matter of parsing extension specs, and so on. > > - Nigel > > > On 5 February 2011 13:33, Nigel Stewart <nstewart@... <mailto:nstewart@...> <mailto:nstewart@... <mailto:nstewart@...>>> wrote: > > Hi Shariq, > > There was some previous discussion about ES and EGL: > > http://sourceforge.net/mailarchive/message.php?msg_id=25658645 > http://sourceforge.net/mailarchive/message.php?msg_id=25660636 > http://sourceforge.net/mailarchive/message.php?msg_id=25781001 > http://sourceforge.net/mailarchive/message.php?msg_id=25964732 > > http://sourceforge.net/apps/mediawiki/openreng/index.php?title=External_Library_Dependencies#GLEW > https://openreng.svn.sourceforge.net/svnroot/openreng/dependencies/_glew/ > > In a nutshell I think we agree that GLEW ought to > support ES and EGL. But nobody has stepped up to > do the work yet. I havn't done a diff with the > openreng fork for a while, to be clear about that. > But it could be a useful starting point. > > - Nigel > > > On 2/2/11 3:46 AM, Shariq Hasnain wrote: > > Dear All, > > I was thinking for extending the glew lib to support OpenGL ES and EGL similarly to that of OpenGL and WGL/GLX. > Since OpenGL ES is popularly used in embedded domain it will be a good idea to do so. > -It will provide run time determination of OpenGL ES/EGL extension supported in the target platform. > -This will also make the porting of OpenGL applications using glew to OpenGL ES easier as the GLEW related code need not be modified individually for each applications. > > The idea is to have: > - Run time check for OpenGL ES core/extension functions similar as existing OpenGL core/extension support in GLEW library. > - Run time check for EGL core/extension functions similar as existing GLX/WGL support in GLEW library. > - Since EGL is used for Graphics resource management in embedded, GLX and WGL support will not be provided. > > > Kindly provide your feedback. > > Thanks, > Shariq > > > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > > > ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Nigel Stewart-2
::
Rate this Message:
> So the idea is for glew.h to expose BOTH desktop GL and
> ES together? Sariq, Just thinking out loud here. So if I wanted a codebase that was "pure" about only depending on OpenGL _or_ OpenGL ES (but not both), would there be an #ifdef for excluding one or both? Seems awkward to do with all the duplicated enums, for example. - Nigel > Sariq, > > 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>. even when specified the path "http://www.khronos.org/registry/gles/". >> >> 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. >> >> >> Thanks, >> Shariq >> >> >> On 18 February 2011 22:01, Nigel Stewart<nstewart@...<mailto:nstewart@...>> wrote: >> >> However for sometime there has been no update. So I would like to extend the implementation further. >> Kindly provide your feedback. >> >> >> Sounds good. >> >> One suggestion I have is adding GLES_VERSION_1_0, GLES_VERSION_1_1, >> GLES_VERSION_2_0. >> >> The headers are available over at khronos.org<http://khronos.org>: >> http://www.khronos.org/registry/gles/ >> >> Also, EGL_VERSION_1_0, EGL_VERSION_1_1, EGL_VERSION_1_2, >> EGL_VERSION_1_3, EGL_VERSION_1_4. >> >> http://www.khronos.org/registry/egl/ >> >> After that it's a matter of parsing extension specs, and so on. >> >> - Nigel >> >> >> On 5 February 2011 13:33, Nigel Stewart<nstewart@...<mailto:nstewart@...> <mailto:nstewart@...<mailto:nstewart@...>>> wrote: >> >> Hi Shariq, >> >> There was some previous discussion about ES and EGL: >> >> http://sourceforge.net/mailarchive/message.php?msg_id=25658645 >> http://sourceforge.net/mailarchive/message.php?msg_id=25660636 >> http://sourceforge.net/mailarchive/message.php?msg_id=25781001 >> http://sourceforge.net/mailarchive/message.php?msg_id=25964732 >> >> http://sourceforge.net/apps/mediawiki/openreng/index.php?title=External_Library_Dependencies#GLEW >> https://openreng.svn.sourceforge.net/svnroot/openreng/dependencies/_glew/ >> >> In a nutshell I think we agree that GLEW ought to >> support ES and EGL. But nobody has stepped up to >> do the work yet. I havn't done a diff with the >> openreng fork for a while, to be clear about that. >> But it could be a useful starting point. >> >> - Nigel >> >> >> On 2/2/11 3:46 AM, Shariq Hasnain wrote: >> >> Dear All, >> >> I was thinking for extending the glew lib to support OpenGL ES and EGL similarly to that of OpenGL and WGL/GLX. >> Since OpenGL ES is popularly used in embedded domain it will be a good idea to do so. >> -It will provide run time determination of OpenGL ES/EGL extension supported in the target platform. >> -This will also make the porting of OpenGL applications using glew to OpenGL ES easier as the GLEW related code need not be modified individually for each applications. >> >> The idea is to have: >> - Run time check for OpenGL ES core/extension functions similar as existing OpenGL core/extension support in GLEW library. >> - Run time check for EGL core/extension functions similar as existing GLX/WGL support in GLEW library. >> - Since EGL is used for Graphics resource management in embedded, GLX and WGL support will not be provided. >> >> >> Kindly provide your feedback. >> >> Thanks, >> Shariq >> >> >> ----------------------------------------------------------------------------------- >> This email message is for the sole use of the intended recipient(s) and may contain >> confidential information. Any unauthorized review, use, disclosure or distribution >> is prohibited. If you are not the intended recipient, please contact the sender by >> reply email and destroy all copies of the original message. >> ----------------------------------------------------------------------------------- >> >> >> > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > glew-coders mailing list > glew-coders@... > https://lists.sourceforge.net/lists/listinfo/glew-coders ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Shariq Hasnain
::
Rate this Message:
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 ? Thanks, Shariq On 24 May 2011 00:37, Nigel Stewart <nstewart@...> wrote: Sariq, ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Nigel Stewart-2
::
Rate this Message:
Shariq,
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 have". Another way to factor the defines might be: GLEW_SUPPORT_OPENGL (compatibility) GLEW_SUPPORT_OPENGL_ES GLEW_SUPPORT_OPENGL_CORE 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 ? > > > Thanks, > Shariq > > > > On 24 May 2011 00:37, Nigel Stewart <nstewart@... <mailto:nstewart@...>> wrote: > > Sariq, > > 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 > "http://www.khronos.org/registry/gles/". > > 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> > <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. > > > Thanks, > Shariq ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Shariq Hasnain
::
Rate this Message:
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 ? Thanks, Shariq On 29 May 2011 00:35, Nigel Stewart <nstewart@...> wrote: Shariq, ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Shariq Hasnain
::
Rate this Message:
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 Thanks, Shariq On 1 June 2011 07:46, Shariq Hasnain <shariq.hasnain@...> wrote: Hi Nigel, ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Shariq Hasnain
::
Rate this Message:
Hi All,
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): make BUILD_GLEW_ES20=yes - To build glew for Desktop OpenGL(INCLUDING entry point and enums of ES) make - To build glew for Desktop OpenGL(EXCLUDING entry point and enums of ES) make BUILD_NO_ES=yes - 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. Thanks, Shariq On 1 July 2011 00:27, Shariq Hasnain <shariq.hasnain@...> wrote: Hi All, Nigel, ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Nigel Stewart-2
::
Rate this Message:
Hi Shariq,
Indeed this has come a long way. I took some time to dig into some of the details, and ponder the possibilities. Random thoughts as follows: 1. Do I need to get a device such as a Trim Slice[1] or a Beagle Board[2] in order to test and maintain an ES-supporting GLEW going forward? Do you have any suggestions about what would be a good choice in terms of Ubuntu for ARM? I have some preference for Tegra2, but also some preference for stability and keeping admin to a minimum. 2. Is it typical these days to cross-build arm binaries from desktop machines, or actually do development on SoCs such as Tegra2? A mixture of both? Would the GLEW build need to support both modes? Does Linux on ARM have perl and everything else needed to download the OpenGL registry, regenerate the GLEW sources, and rebuild a libGLEW.so? 3. I "pulled" (I think!) the linaro.org repository into the GLEW git reprository as the "es" branch.[3] I'm doing some fiddling in my local repro to harmonize a few things with the master branch, to make the diff a bit manageable. 4. My first concern is whether there are changes here likely to, (or possibly) break things on the desktop side of things. I noticed some ES extensions in the glewinfo output, for example. But I'll be looking into that broader issue in more detail. 5. My understanding of ES on iOS is that there is no shared library to load extensions from. Possibly there is an API function? I don't actually own an iPad, but I guess this is as good an excuse as any... 6. To emulate ARM Linux on a PC, QEmu? - Nigel [1] http://trimslice.com/web/ [2] http://beagleboard.org/ [3] http://glew.git.sourceforge.net/git/gitweb.cgi?p=glew/glew;a=shortlog;h=refs/heads/es On 10/11/11 6:59 AM, Shariq Hasnain wrote: > Hi All, > > 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 <http://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): > make BUILD_GLEW_ES20=yes > > - To build glew for Desktop OpenGL(INCLUDING entry point and enums of ES) > make > > - To build glew for Desktop OpenGL(EXCLUDING entry point and enums of ES) > make BUILD_NO_ES=yes > > - 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 > 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. > > Thanks, > Shariq > 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 <http://git.linaro.org/people/shariqhasnain/glew-es_core.git> > > Thanks, > Shariq > > > > On 1 June 2011 07:46, Shariq Hasnain <shariq.hasnain@... <mailto:shariq.hasnain@...>> 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 ? > > Thanks, > Shariq > > > > On 29 May 2011 00:35, Nigel Stewart <nstewart@... <mailto:nstewart@...>> wrote: > > Shariq, > > 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 > have". > > Another way to factor the defines might be: > > GLEW_SUPPORT_OPENGL (compatibility) > GLEW_SUPPORT_OPENGL_ES > GLEW_SUPPORT_OPENGL_CORE > > 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 ? > > > Thanks, > Shariq > > > > On 24 May 2011 00:37, Nigel Stewart <nstewart@... <mailto:nstewart@...> <mailto:nstewart@... <mailto:nstewart@...>>> wrote: > > Sariq, > > 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> <http://www.khronos.org>. even when > specified the path > > "http://www.khronos.org/registry/gles/". > > 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> > <http://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. > > > Thanks, > Shariq > > > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: GLEW support for OpenGL ES /EGL.
by Shariq Hasnain
::
Rate this Message:
Hi Nigel,
Below I have mentioned my view: On 18 October 2011 23:34, Nigel Stewart <nstewart@...> wrote: Hi Shariq, Glew for ES can run on SoCs like beagle board(TI OMAP3), panda(TI OMAP4) etc. It can also run on notebooks supporting OpenGL ES (basically ARM) like Trim Slice. It can also be run on Linux desktop using OpenGL ES emulator.But many OpenGL ES extensions will not be available. I expect all ARM based system to be stable, the preference should be to keep admin to a min and for which good support is available. If you prefer Tegra 2 you can look into Toshiba AC100 (for which ubuntu support is provided) or Trim slice itself. https://wiki.ubuntu.com/ARM/
Arm binaries are cross-build on dekstop and then run on SoCs.So in this case no need to support perl in SoCs. For notebook we need to compile and run it there itself(native compiling). For ARM Ubuntu there would not be any issue in generating the lib or running perl script.
The ES support is not expected to break anything on the desktop OpenGL side. However the generic glew lib support all OpenGL and OpenGL ES core verisons and extensions. So glewinfo will provide info about all of these. If GLEW_NO_ES flag is enabled then the lib should be similar to current glew lib without OpenGL ES support.
Did some search but not able to get much info.Need to check more. Anybody has any idea about iOS ?
QEmu can be used to run ARM Linux. But not sure if OpenGL ES acceleration will work properly. https://wiki.linaro.org/Platform/DevPlatform/QemuOpenGLES
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
| Free embeddable forum powered by Nabble | Forum Help |
