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

[Emil Velikov]

On 24 September 2018 at 01:55, Marek Olšák <maraeo at gmail.com> 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.
>
I believe you're missing the part that there are _two_ distinct problems.

I do agree that building a driconfig database is:
 a) fragile (unless Nvidia shares with us their data), and
 b) huge effort for questionable benefit

As I said, reverting is perfectly fine  ... just sent a patch that does that.

-Emil