[Mesa-dev] multiple versions in version string

tom fogal tfogal at sci.utah.edu
Mon Jun 20 11:55:46 PDT 2011


Nathan Kidd <nathan-ml at spicycrypto.ca> writes:
> On 11-06-20 01:22 PM, tom fogal wrote:
> > I am trying to get some regression tests to run in Xvfb.  On my
> > workstation, the GL_VERSION string from this is:
> >
> >    1.4 (2.1 Mesa 7.7.1)
[snip]
> > In any case, the above version string breaks projects like GLEW
[snip]
>  From section "3.3.2 GLX Versioning" of the GLX 1.4 spec:
>
> "The version string is laid out as follows:
>
> <major version.minor version><space><vendor-specific info>
>
> Both the major and minor portions of the version number are
> of arbitrary length. The vendor-specific information is
> optional. However, if it is present, the format and contents are
> implementation specific. "

Yes, I know how the version string works in this regard.  Side note,
you quoted from the GLX spec, but I am actually discussing *GL* version
here, not GLX; in any case, the rules are the same as far as I know.

> So any app that confuses the vendor-specific info for the version
> major.minor has a bug (though one I've seen before).

The issue is that VBOs *are* supported, but Mesa is not advertising
as such.  VBOs might not be such a huge deal.  Replace "VBO" with any
other popular feature, i.e. glCreateProgram et al.  We, as I'm sure
many others, have applications that simply don't work without some
extensions or a base OpenGL version of something or other.

The "(...)" part of the version string is perhaps a red herring
for what I'm trying to bring up: GLEW is telling applications that
functionality is not available when it is.  The GLEW methodology is
based on the beginning (i.e. specified component) of the version
string.  At least for Mesa 7.7.1, such logic appears to be a bad idea.

> In the context of debugging problems with indirect GLX those
> parenthetical versions are quite helpful.

I did not mean to imply they should be removed (though they have
been removed for other reasons in more recent versions of Mesa); I
really don't care what's there after the initial version number (as I
can't/shouldn't, as per the spec).  However, with this version of Mesa,
it seems at first glance that one should just ignore the version number
/completely/.

I was pinging the ML to be sure while I did some of my own testing; if
the version number is not useful in Mesa's 7.7.1 release, I will want
to propose a change to GLEW or at least hack the in-tree GLEW on one of
our projects to be more lenient.

-tom


More information about the mesa-dev mailing list