[Mesa-dev] multiple versions in version string

[Nathan Kidd]

On 11-06-20 02:55 PM, tom fogal wrote:
> Nathan Kidd<nathan-ml at spicycrypto.ca>  writes:
>> 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.

Meh, my bad.

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

Any client that wants to push the limits of what's actually available 
need to query extensions if the version number itself doesn't give what 
you want.  If GLEW is *only* looking at the version number it makes 
sense to me that it get expanded to also check specific features via 
extension string.

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

(quoting from your other mail)
> You are correct, rendering is indirect!  I was unaware that direct vs.
> indirect limited *GL* features.  Why is that the case, and what can be
> done?  I'm just using swrast right now, maybe softpipe in the future;
> I'm obviously not concerned with speed, I just need something that
> supports some extensions for use in a regression testing system.

Of course, for indirect rendering every glFoo() function call needs to 
be mapped to (GL)X protocol.  Protocol exists up to OpenGL 1.4.  There 
are some features after that that have protocol specified, I believe 
NVIDIA actually have unofficial protocol up till closer to OpenGL 2.0, 
but the bottom line is there is no official protocol agreed upon for 
later GL versions, therefore GLX clamps the GL version number to 
whatever it can handle.

(Why the protocol doesn't exist is, to the best of my knowledge a matter 
of effort not being invested for features that are considered less 
useful in the lower-performance indirect context. I'm sure others on 
this list have a better knowledge of the history there.)

-Nathan