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 <kenn...@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 <jfons...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev