[vtk-developers] [LONG]Core-promoted OpenGL extensions management in VTK

Moreland, Kenneth kmorel at sandia.gov
Tue Feb 13 19:32:08 EST 2007


> >  It also means that users might run into other promoted extensions
that
> have not yet been hand coded in.
> 
> No, so far I went through the appendices of the OpenGL spec, and went
> through all of the extensions promoted as core features, up to OpenGL
2.0.

OK, so you have all the promotions up to OpenGL 2.0.  What about when
OpenGL 2.1 is released six months from now (or whenever)?  What about
OpenGL 2.2?

> > It would be nice if there was a mechanism so that if someone
identified
> and coded a promotion, they could use it without having to modify VTK
and
> then be able to submit it for inclusion into the repository.
> 
> Can you explain me more about that? What do you have in mind?

When I originally designed vtkgl.h and vtkOpenGLExtensionManager, I knew
that the OpenGL extensions would be constantly changing, as is their
nature.  I didn't want to commit to spending the rest of my career
updating the extension manager, and even if I did there would be an
inevitable lag between the time new extensions came into existence and I
updated the VTK code.  The issue is compounded for those who only use
the official releases of VTK.

Thus, I made sure that the extension manager could easily adapt to
changing extensions.  New extensions are defined (theoretically) by
simply using new specification files (the glext.h header file and its
friends).  If the VTK versions of these files are lagging behind or a
user wants to use a brand new extension that is not yet defined in any
of these header files, a user can use their own specification files.
You can even point CMake to header files outside of the VTK source if so
desired.  Sometimes there are some parse issues with the header file
(see below), but overall the system works as described.

So, the issue I am trying to bring up is the promotion mechanism does
not yield as well to changes to the extensions/versions.  Every time a
new OpenGL version comes out, someone has to go through the fairly time
consuming process writing all the code to map the promoted extension's
functions to the new version.  If someone needs a promotion that is not
yet supported, there is no way to implement the promotion short of
hacking up the VTK source until the promotion is implemented.

I don't have a solution for either problem.  I'm just bringing up the
issue.

> 
> > * There is no documentation for the promoted extensions.
> 
> You mean in the code I attached to my email, right? Because on the
other
> hand, there is some documentation in the OpenGL spec. Each appendix
about
> some specific OpenGL version lists the set of extensions that were
> promoted as core OpenGL features.
> 
> http://www.opengl.org/documentation/specs/
> http://www.opengl.org/registry/doc/glspec21.20061201.pdf

I haven't seen the promotion information in the specs before (never
looked).  I guess that is sufficient, but it's too bad the information
is not in a more easily digestible form, such a table mapping version to
promoted extension.  It's also not immediately obvious what functions
are promoted from what extensions.

Again, I'm not suggesting anything better, just making an observation.

> > * Consider multiple promotions.
> 
> I was only talking about extension promoted as core feature, not
> intermediate promotion. In the spec, there is only one version of each
> extension which is promoted as core feature.

Fair enough.

> > I don't think there should be any issue in updated the glext.h
headers
> in VTK, but keep in mind that when you do you may need to make changes
to
> ParseOGLExt to get it to load correctly.
> 
> Ok, I am not in an hurry for touching ParseOGLExt :-)

Sorry, I didn't mean to scare you.  Chances are that you can just
replace the OpenGL header files and everything will work, so I would go
ahead and just try it.  I just raised a warning because ParseOGLExt is
not a full C parser (and needs extra information anyway) so it relies a
lot on the way in which enumerations and prototypes are defined.  As
long as all the new extensions follow the same format, everything is
fine.  The OpenGL folks are pretty good about maintain that because
there are several other independent API's that also rely on the
structure remaining constant.

-Ken




More information about the vtk-developers mailing list