[Mesa-dev] Truncated extensions string
cbandy at jbandy.com
Fri Mar 11 16:09:21 PST 2011
On 03/11/2011 02:14 PM, Kenneth Graunke 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>
>>>> The problem from
>>>> 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
> 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.
I'm just a lurker on the list, but this approach seems the most sane to me.
Keeping the code/table in a format useful to developers seems more
important than supporting legacy applications. In my opinion, a user of
old, closed or binary applications can flip some switches to use the
> 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.
I suspect that the performance of any implementation is insignificant,
since this kind of query happens very few times in an application?
> 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.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev