[Mesa-dev] Truncated extensions string

[Brian Paul]

On Fri, Mar 11, 2011 at 2:23 PM, Patrick Baggett
<baggett.patrick at 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 <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
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>