On 24 September 2018 at 01:55, Marek Olšák <mar...@gmail.com> wrote: > On Fri, Sep 21, 2018 at 11:34 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> On 21 September 2018 at 00:42, Timothy Arceri <tarc...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
