Re: [utah-glx-dev] standardized GL_RENDERER strings

[Brian P. <br...@pr...>]

Ralph Giles wrote:
> 
> On Wed, 9 Feb 2000, Brian Paul wrote:
> 
> > Here's the proposed format:
> >
> >       "[Mesa | SI] [DRI | UtahGLX] <card> <version> <card-specific>"
> >
> > "Mesa" indicates it's a Mesa-based renderer.  "SI" might indicate
> > an SI-based renderer.
> 
> That sounds good to me.
> 
> > <version> is a version number for the driver.  I propose a YYYYMMDD
> > format.  If we used a "major.minor.patch" scheme I'm not sure what
> > the numbers would indicate since the Mesa version can already be
> > queried with GL_VERSION.  With YYYYMMDD users can get an idea of
> > how old the driver is and be able to compare it to others.
> 
> The comment I have here is that the only thing it really makes sense to
> put here is a compile date, and that's only somewhat helpful in figuring
> out code versions. One can track cvs this way, but should we ever get
> around to making a release, there would be no mechanism for saying you
> used a particular tarball, which can be a great help in debugging.
> 
> The best thing I can think of to remedy this is to specify both a driver
> version and a build date. e.g. cvs-20000202 or 0.9.1-20000314. One would
> want to split based on a unique character, so the parsing wouldn't be that
> much harder. I'd be happy with just a build date though; I only wanted to
> point out the issue.

I don't want to over-engineer this.  I still think YYYYMMDD (intended
to be a release number) is sufficient (i.e. better than nothing).
The idea is that someone could go to the UtahGLX or DRI web site,
look at the build number for the latest drivers, and be able to
easily determine if they are up to date.


> Re Keith's comment, I read 20000202 as a date, but maybe that's because I
> use stamps like that all the time. The zeros are intimidating. :)
> 
> Re Emil's comment, I agree we should use standard punctuation if one's
> being pushed, and we should *definitely* use big-endian date ordering.
> Note that running all the digits together is also spec, according to the
> referenced page.

I'm leaning toward no punctuation.


> > <card-specific> (the remainder of the string) can be anything which
> > might further describe the hardware, such as amount of memory, SLI
> > mode, etc.  The format of this part is dependant on <card>.
> 
> Can this contain whitespace?

Yes.  Everything past the version number is card-specific.

-Brian