[Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions

[Jose Fonseca]

On 24/09/18 01:55, Marek Olšák wrote:
> On Fri, Sep 21, 2018 at 11:34 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 21 September 2018 at 00:42, Timothy Arceri <tarceri at itsqueeze.com> wrote:
>>> On 20/9/18 11:09 pm, Ian Romanick wrote:
>>>>
>>>> On 09/19/2018 11:36 PM, Federico Dossena wrote:
>>>>>
>>>>> As most of you are probably aware of, id2 and id3 games store GL
>>>>> extensions in a buffer that's too small for modern systems. This usually
>>>>> leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the
>>>>> creator of this commit didn't know is that some id3 games (the more
>>>>> "recent" ones) don't crash, they just truncate the string. As a result
>>>>> of this commit, these games can't detect some extensions and therefore
>>>>> don't work properly.
>>>>
>>>>
>>>> It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not
>>>> set, so why not just set it?  Doesn't that fix the problem?
>>>
>>>
>>> There is no driconfig option for this currently. Personally I'd rather just
>>> sort the extensions (even if it was only for 32bit builds of Mesa) rather
>>> than adding a bunch of code and extra entry's into driconfig.
>>>
>>> Or are you saying you would prefer we do nothing and people should use
>>> MESA_EXTENSION_MAX_YEAR be required to use?
>>>
>> As mentioned in my other reply there seems to be two type of problems
>> when dealing with some idtech games:
>>   - blind copy - leading to crashes
>>   - copy + truncation - leading to "missing" extensions
> 
> Since the change causes incorrect rendering and it's impossible to
> associate that with the need to set MESA_EXTENSION_MAX_YEAR, the env
> var doesn't help. You need to be a professional driver developer in
> order to guess that the env var should be set. I certainly wouldn't
> guess that. I didn't even know that the extension list is not sorted
> by year anymore.
> 
> The driconfig approach is fragile. You can't identify the list of
> affected apps because you don't have or test all apps and they may
> just show incorrect rendering, which is inconclusive. Building a list
> of affected apps for driconfig is a huge effort that nobody will
> realistically do. I prefer minimizing the number of workarounds in
> driconfig as much as possible.
> 
> Marek

I agree FWIW.

The sorting by year is a bit of a nuisance, but unfortunately the 
problem won't disappear by wishing it away.

IMHO, only sorting on some apps is just adding complexity to the workaround.

Restricting to 32bit makes sense though, as it makes a clear transition 
path, since I suppose no 64 bit app is affected, and I suppose one day 
(far in the future perhaps, on specially on Windows) 32 bit will go out 
of use.

Jose