Including GLEW in Mesa

[José Fonseca-2]

Hi,

Mesa and Gallium3D include a big number of test and sample OpenGL apps.
A good portion depends on Glut so it could be built on many platforms.
Unfortunately, several samples which demonstrate recent OpenGL
functionality call extensions entry points directly, which is not
guaranteed to work on all platforms. GLEW library perfectly fills this
gap, providing a uniform compatibility layer, and therefore allowing to
build these sample apps with very little changes.

To make it easy to build the samples I plan to integrate the GLEW source
code directly into Mesa:
- include/GL/glew.h
- include/GL/glxew.h
- include/GL/wglew.h
- src/glew/LICENSE.txt
- src/glew/glew.c
- src/glew/glewinfo.c
- src/glew/visualinfo.c

This is just the barely needed to build the samples (no code
autogeneration harness or documentation). I don't expect we will need to
update the glew code, but if we do, we would send the patches upstream.

Let me know if there's any issue with this.

Jose


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Brian Paul-3]

José Fonseca wrote:

> Hi,
>
> Mesa and Gallium3D include a big number of test and sample OpenGL apps.
> A good portion depends on Glut so it could be built on many platforms.
> Unfortunately, several samples which demonstrate recent OpenGL
> functionality call extensions entry points directly, which is not
> guaranteed to work on all platforms. GLEW library perfectly fills this
> gap, providing a uniform compatibility layer, and therefore allowing to
> build these sample apps with very little changes.
>
> To make it easy to build the samples I plan to integrate the GLEW source
> code directly into Mesa:
> - include/GL/glew.h
> - include/GL/glxew.h
> - include/GL/wglew.h
> - src/glew/LICENSE.txt
> - src/glew/glew.c
> - src/glew/glewinfo.c
> - src/glew/visualinfo.c
>
> This is just the barely needed to build the samples (no code
> autogeneration harness or documentation). I don't expect we will need to
> update the glew code, but if we do, we would send the patches upstream.
>
> Let me know if there's any issue with this.

That sounds fine.  My own solution has been the extfuncs.h header but
it'd be nicer to use GLEW.

-Brian


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

 >> GLEW library perfectly fills this gap, providing a uniform compatibility
 >> layer, and therefore allowing to build these sample apps with very little changes.

Jose,

What is the timeframe for the next Mesa release?

There have been a few fixes since GLEW 1.5.1
And perhaps some new extensions too.

- Nigel

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[José Fonseca-2]

On Thu, 2009-01-22 at 08:01 -0800, Nigel Stewart wrote:

> >> GLEW library perfectly fills this gap, providing a uniform compatibility
>  >> layer, and therefore allowing to build these sample apps with very little changes.
>
> Jose,
>
> What is the timeframe for the next Mesa release?
>
> There have been a few fixes since GLEW 1.5.1
> And perhaps some new extensions too.
>
> - Nigel

Nigel,

We'll commit to a non-master branch for the time being, so it won't be
included in the soon-to-be-released Mesa 7.3, but it can be
merged/cherry-picked in time for the next release.

I've only barely started the sample migration to glew -- I'll keep this
info in mind and update glew to a subversion snapshot if I run into
issues.

Jose


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Ian Romanick-4]

On Thu, 2009-01-22 at 13:15 +0000, José Fonseca wrote:

> Hi,
>
> Mesa and Gallium3D include a big number of test and sample OpenGL apps.
> A good portion depends on Glut so it could be built on many platforms.
> Unfortunately, several samples which demonstrate recent OpenGL
> functionality call extensions entry points directly, which is not
> guaranteed to work on all platforms. GLEW library perfectly fills this
> gap, providing a uniform compatibility layer, and therefore allowing to
> build these sample apps with very little changes.
>
> To make it easy to build the samples I plan to integrate the GLEW source
> code directly into Mesa:
> - include/GL/glew.h
> - include/GL/glxew.h
> - include/GL/wglew.h

Since we're not intending to be the install-source of GLEW on people's
system, I think the GLEW header files should go in src/glew/include.
The Makefiles in progs/* can just add -I$(topdir)/src/glew/include to
CFLAGS.

> - src/glew/LICENSE.txt
> - src/glew/glew.c
> - src/glew/glewinfo.c
> - src/glew/visualinfo.c
>
> This is just the barely needed to build the samples (no code
> autogeneration harness or documentation). I don't expect we will need to
> update the glew code, but if we do, we would send the patches upstream.
>
> Let me know if there's any issue with this.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

>> To make it easy to build the samples I plan to integrate the GLEW source
>> code directly into Mesa:
>> - include/GL/glew.h
>> - include/GL/glxew.h
>> - include/GL/wglew.h
>
> Since we're not intending to be the install-source of GLEW on people's
> system, I think the GLEW header files should go in src/glew/include.
> The Makefiles in progs/* can just add -I$(topdir)/src/glew/include to
> CFLAGS.

We're planning to do a similar thing for NVIDIA Cg Toolkit - bundling
the GLEW source into the example program source tree.  One issue we
encountered with GLEW is that it has a large footprint as a static
link library. (static link to avoid conflict with system-installed GLEW)

I have some ugly #ifdef magic to subset the OpenGL entry points
supported by a particular GLEW build, which relies on making a
list of defines for use at build-time.  I'm not sure if there
is broader interest in such a feature in GLEW, but I thought I'd
mention it.  It keeps the example binary sizes to a minimum,
keeping the size of our installers and RPMs within reason.

I think the ideal thing (for Cg anyway) would be to generate a
custom glew.c for each little example.  It would have the benefit
of keeping each example program self-contained within one
directory, rather than "reaching out" in the way proposed here
for the Mesa examples.

- Nigel

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Marcelo E. Magallón]

On Thu, Jan 22, 2009 at 2:16 PM, Nigel Stewart <nstewart@...> wrote:

> We're planning to do a similar thing for NVIDIA Cg Toolkit - bundling
> the GLEW source into the example program source tree.  One issue we
> encountered with GLEW is that it has a large footprint as a static
> link library. (static link to avoid conflict with system-installed GLEW)

Doesn't your linker remove the unused symbols from the final binary?

Marcelo

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

> Doesn't your linker remove the unused symbols from the final binary?

Marcelo,

        Unfortunately while the symbols are unused by the application,
        they're all used by glewInit(), along with all the strings
        that are required for the lookups.

- Nigel

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Brian Paul-3]

Ian Romanick wrote:

> On Thu, 2009-01-22 at 13:15 +0000, José Fonseca wrote:
>> Hi,
>>
>> Mesa and Gallium3D include a big number of test and sample OpenGL apps.
>> A good portion depends on Glut so it could be built on many platforms.
>> Unfortunately, several samples which demonstrate recent OpenGL
>> functionality call extensions entry points directly, which is not
>> guaranteed to work on all platforms. GLEW library perfectly fills this
>> gap, providing a uniform compatibility layer, and therefore allowing to
>> build these sample apps with very little changes.
>>
>> To make it easy to build the samples I plan to integrate the GLEW source
>> code directly into Mesa:
>> - include/GL/glew.h
>> - include/GL/glxew.h
>> - include/GL/wglew.h
>
> Since we're not intending to be the install-source of GLEW on people's
> system, I think the GLEW header files should go in src/glew/include.
> The Makefiles in progs/* can just add -I$(topdir)/src/glew/include to
> CFLAGS.

Or, couldn't we simply omit the glew headers from 'make install'?

-Brian


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[José Fonseca-2]

On Thu, 2009-01-22 at 12:49 -0800, Brian Paul wrote:

> Ian Romanick wrote:
> > On Thu, 2009-01-22 at 13:15 +0000, José Fonseca wrote:
> >> Hi,
> >>
> >> Mesa and Gallium3D include a big number of test and sample OpenGL apps.
> >> A good portion depends on Glut so it could be built on many platforms.
> >> Unfortunately, several samples which demonstrate recent OpenGL
> >> functionality call extensions entry points directly, which is not
> >> guaranteed to work on all platforms. GLEW library perfectly fills this
> >> gap, providing a uniform compatibility layer, and therefore allowing to
> >> build these sample apps with very little changes.
> >>
> >> To make it easy to build the samples I plan to integrate the GLEW source
> >> code directly into Mesa:
> >> - include/GL/glew.h
> >> - include/GL/glxew.h
> >> - include/GL/wglew.h
> >
> > Since we're not intending to be the install-source of GLEW on people's
> > system, I think the GLEW header files should go in src/glew/include.
> > The Makefiles in progs/* can just add -I$(topdir)/src/glew/include to
> > CFLAGS.
>
> Or, couldn't we simply omit the glew headers from 'make install'?

Yeah, this is possible. I really don't care much either way, but putting
in mesa/include/GL would save me the trouble of modifying all samples'
makefiles.

Jose


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders