[Mesa-dev] Truncated extensions string

[Chris Bandy]

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> 
> 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.
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
latest mesa.
> 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.
>
> --Kenneth
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev