[Mesa-dev] Truncated extensions string

[Patrick Baggett]

I feel like there is some kind of underlying lesson that we, OpenGL app
programmers, should be getting out of this...

What about a psuedo-database of app -> extension list rather than by year?
Surely Quake3 doesn't make use of but <= 10 extensions. I'd imagine the same
holds true for other old games as well. A simple "strings" on their binary
could figure that out...

On Fri, Mar 11, 2011 at 2:14 PM, Kenneth Graunke <kenneth at whitecape.org>wrote:

> On Friday, March 11, 2011 10:46:31 AM José Fonseca wrote:
> > On Fri, 2011-03-11 at 09:04 -0800, Eric Anholt wrote:
> > > On Fri, 11 Mar 2011 10:33:13 +0000, José Fonseca <jfonseca at vmware.com>
> wrote:
> > > > The problem from
> > > >
> > > >
> http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12493.h
> > > > tml
> > > >
> > > > is back, and now a bit worse -- it causes Quake3 arena demo to crash
> > > > (at least the windows version). The full version works fine. I'm not
> > > > sure what other applications are hit by this. See the above thread
> for
> > > > more background.
> > > >
> > > >
> > > > There are two major approaches:
> > > >
> > > > 1) sort extensions chronologically instead of alphabetically. See
> > > > attached patch for that
> > > >
> > > >   - for those who prefer to see extensions sorted alphabetically in
> > > >
> > > > glxinfo, we could modify glxinfo to sort then before displaying
> > > >
> > > > 2) detect broken applications (i.e., by process name), and only sort
> > > > extensions strings chronologically then
> > > >
> > > > Personally I think that varying behavior based on process name is a
> > > > ugly and brittle hack, so I'd prefer 1), but I just want to put this
> > > > on my back above all, so whatever works is also fine by me.
> > >
> > > If this is just a hack for one broken application, and we think that
> > > building in a workaround for this particular broken application is
> > > important (I don't), I still prefer an obvious hack for that broken
> > > application like feeding it a tiny extension string that it cares
> about,
> > > instead of reordering the extension list.
> >
> > There are many versions of Quake3 out there, some fixed, others not, and
> > others enhanced. This means a tiny string would prevent any Quake3
> > application from finding newer extensions. So I think that if we go for
> > the application name detection then we should present the whole
> > extension string sorted chronologically, instead of giving a tiny
> > string.
> >
> > Jose
>
> I agree with José - it's not one broken application, it's a number of old,
> sometimes closed-source games that we can't change.
>
> I'm not sure how changing the sorting solves the problem, anyway - the
> amount
> of data returned would still overflow the buffer, possibly wreaking havoc.
>  I'd
> rather avoid that.
>
> Ian and I talked about this a year ago, and the solution I believe we came
> up
> with was to use a driconf option or environment variable:
>
> If MESA_MAX_EXTENSION_YEAR=2006, then glGetString would only return
> extensions
> created in 2006 or earlier.  The rationale is that if a game came out in
> 2006,
> it won't know about any extensions from 2007 anyway, so advertising them is
> useless.  The fixed-size buffer is also almost certainly large enough to
> handle
> this cut-down list of extensions.
>
> This should be trivial to do now that you already have the years for each
> extension...just store them in the table, rather than in comments, and
> check
> before listing an extension.
>
> A driconf option is nice because it allows this to be overridden in .drirc
> on
> a per-app basis, rather than having to set an environment variable.  It
> might
> be a bit more work though.
>
> --Kenneth
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110311/5eed57d9/attachment.html>