ogl-sample
[Top] [All Lists]

Re: glext.h updates for OpenGL shading language???

To: "Marcelo E. Magallon" <marcelo.magallon@xxxxxxxxxxx>, ogl-sample@xxxxxxxxxxx
Subject: Re: glext.h updates for OpenGL shading language???
From: John Stone <johns@xxxxxxxxxxx>
Date: Mon, 12 Jan 2004 16:49:39 -0600
Cc: John Stone <johns@xxxxxxxxxxx>
In-reply-to: <20040112211159.GA2369@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20040108161702.G19766@xxxxxxxxxxxxxxxxxx> <20040112211159.GA2369@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: ogl-sample-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.19i
Hi Marcelo,
  I looked at GLEW and it looks like a nice solution for a lot of people.
I'd love to use it, or something like it.  I'd looked at it in the past, 
and I just checked on it again today as per your suggestion.  I came up with 
some issues that are important to me personally that would need attention 
before I'd be able to use GLEW instead of the the code I already have:

  1) Doesn't support several extensions I've already been using for a long
     time.  This being the case, I might as well continue with my existing 
     code.

     In particular:
       a) Not an extension per se, but I'd still have to manually 
          get pointers for functions like glTexImage3D() on Win32 
          (since they APIs >= GL 1.1, which is all that's guaranteed there..)
          I don't see any support for this in GLEW (from what docs I've read)
 
       b) GLX_SGIS_multisample      (old SGI-specific multisample extensions,
                                     older revs of IRIX lack support
                                     for the ARB extension)
          GL_SUN_read_video_pixels  (Sun XVR-4000 multisample readback funcs)
          GLX_SUN_video_resize      (XVR-4000 video resize)

  2) Uses global variables.  Implicitly thread-unsafe.  Can also be unsafe 
     in some dynamically loaded libraries.  Should use some other method 
     of extension availability enumeration.  See 3) below.

  3) I can't see how this system could work properly when opening several 
     OpenGL windows on a multi-display system where different heads are 
     driven by different graphics accelerators that support different 
     extensions or have different extension function pointers.  
     I know this is not a typical use-case, but I have to deal with this 
     in my application soon, and I don't want to be fighting
     with someone else's library to make this work.
     If I'm completely missing something obvious, tell me.  
     Creating multiple GL windows on multiple X displays (or even Win32 
     displays) is an issue I'll have to deal with shortly.  It'd be great
     if GLEW handled this gracefully.

  4) Yet another library to have to compile, test, and link against on
     each of about 8 platform builds I have to do.
     As it stands, I already have to make patched/fixed versions of several 
     well known libraries like FLTK, Tcl/Tk, and others to fix or workaround
     bugs in the officially released versions they provide, particularly
     when building on new platforms.
     In short, I already have too many library dependencies in my opinion...
     
  5) The included makefiles were probably written on Linux and fail
     immediately when used with a standard make utility.
     (i.e. not GNU make): 
     % make
     make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen

     If you develop code on Linux or MacOS, its easy to fall into using
     Makefile constructs that only work with GNU's make....


  6) When run with GNU make, it goes and downloads all of the latest 
     extensions.  While cute, this takes a while and might be a rude 
     surprise if one is compiling on a laptop or something.  
     (I'm thinking of end-users of VMD that know nothing about OpenGL, but
      might want to compile VMD from source....)

     At the end, the build failed:
     FINISHED --16:33:05--
     Downloaded: 4,682,041 bytes in 279 files
     sed -i -e '7s/\<ATI_/GL_ATI_/' registry/ATI/texture_env_combine3.txt
     sed: illegal option -- i
     gmake: *** [registry/.dummy] Error 2

  6) The problems in 5) are a perfect example of why I don't use libraries 
     unless I really need them.  Most of the free software on the net these 
     days is written on Linux and hasn't been tested on non-Linux machines.  
     Since my software has to run on Linux, Solaris, IRIX, AIX, HP-UX, 
     Tru-64, Windows, and MacOS X, I don't want to have a build fail and 
     have to be fixing someone else's Makefiles or 'sed' script if I can 
     avoid it.  

     Also, special compiler options (i.e. 64-bit versus 32-bit builds) 
     are typically a stumbling block for most packages that were originally 
     developed on PC's or other 32-bit only platforms.  I build both 32-bit 
     and 64-bit binaries on IRIX and Solaris, with more platforms coming as 
     time goes on.  I don't know if GLEW has this problem, but its one of 
     the things I hate having to manually fix when I'm building libraries 
     like Tcl/Tk that have broken configure/Makefile setups.  You might try
     building GLEW in both 32-bit and 64-bit mode and see that it compiles 
     and links right.. :)
     
Anyway, I'd love to use GLEW or some extension library that does the same
sort of thing.  I don't like maintaining my own extension code, but at the
present time it appears to be a necessary evil until something comes along
that addresses the issues I list above and does what my existing code already
does for me.  

If GLEW can fix/address the issues above, I could easily see ditching the code
I've already written and start using it instead.  Until then, I don't have
much choice really.  If you need someone to test your code on many platforms,
I have basically one of each of the major platforms here.  You'll need to
fix the non-portable Makefile and 'sed' problems first though.

Thanks,
  John Stone
  johns@xxxxxxxxxxx



On Mon, Jan 12, 2004 at 10:11:59PM +0100, Marcelo E. Magallon wrote:
> Hi,
> 
> On Thu, Jan 08, 2004 at 04:17:03PM -0600, John Stone wrote:
> 
>  >   Is there any chance we'll see updated glext.h/glxext.h/wglext.h
>  > headers posted to the OpenGL SDK site any time soon?:
>  >   http://oss.sgi.com/projects/ogl-sample/sdk.html
>  >     
>  > Specifically, I'd like to see an updated glext.h that includes the
>  > new OpenGL 1.5 ARB extensions for the OpenGL shading language.  (i.e.
>  > glUseProgramObjectARB(), glUniform3fvARB(), ..... and the various
>  > GL_ARB_vertex_shader GL_ARB_fragment_shader GL_ARB_shader_objects
>  > #defines....)
> 
>  I hope it's ok for me to plug this here: take a look at GLEW,
>  http://glew.sf.net/, a library that eases the use of OpenGL extensions.
>  Disclaimer: I'm one of the authors of that library.  It includes
>  support for currently available OpenGL extensions, with a couple of
>  exceptions (SGI extensions to GLX, IIRC).  It's very easy to use, very
>  portable, and we have paid attention to portability.  It works on
>  Windows, Linux, MacOS and IRIX.
> 
>  HTH,
> 
>     Marcelo

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns@xxxxxxxxxxx                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078

<Prev in Thread] Current Thread [Next in Thread>