[Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
emil.l.velikov at gmail.com
Mon Sep 24 15:26:37 UTC 2018
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.
More information about the mesa-dev