On Fri, Mar 11, 2011 at 2:23 PM, Patrick Baggett <baggett.patr...@gmail.com> wrote: > I feel like there is some kind of underlying lesson that we, OpenGL app > programmers, should be getting out of this...
Yeah, don't expect the GL_EXTENSIONS string to always fit in your fixed-size buffer. :) BTW, OpenGL 3.0 deprecates the glGetString(GL_EXTENSIONS) query. Instead, query GL_NUM_EXTENSIONS then call glGetStringi() for each extension. > 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... Let's not over-engineer this. We don't want a database of apps/games in Mesa. I'm leaning toward sorting the ext list by year as Jose proposed and then sort the list in glxinfo. -Brian > 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 > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
