On 09/06/2015 03:46 PM, Kenneth Graunke wrote: > On Sunday, September 06, 2015 10:06:38 PM Marek Olšák wrote: >> On Sun, Sep 6, 2015 at 8:38 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> On 3 September 2015 at 20:33, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>>> On Thu, Sep 3, 2015 at 3:30 PM, Marek Olšák <mar...@gmail.com> wrote: >>>>> >>>>> 2) Using LIBGL_DRIVERS_PATH won't use the correct drirc file. The only >>>>> remaining solution to that is to kill LIBGL_DRIVERS_PATH. >>>> >>> I'm confused ... what does LIBGL_DRIVERS_PATH has to do with the >>> location of drirc ? Afaict it has always been solely about the >>> location of the dri module(s). >> >> If you install Mesa 10.6, its drirc will go to /etc/drirc. If you >> later build Mesa 11.0 and use LIBGL_DRIVERS_PATH, you'll get Mesa 11.0 >> drivers with drirc from Mesa 10.6. As a result, Unigine Heaven with >> tessellation won't work. >> >>> Imho inexperienced users should not thinker with this env var, should >>> they ? If they do and things go bad, it's their own fault. >> >> Inexperienced users use whatever they find on the internet. Either >> drirc or LIBGL_DRIVERS_PATH must go. They can't co-exist. If people >> can use the env var, they will. >> >> Marek > > Honestly, I'm mostly upset about the reason most of these exist. 90% of > the workarounds we've ever had are entirely because of Unigine's demos. > > Their bug reporting mechanism is a forum with a broken registration page, > and they actively ignore contact from driver teams at both AMD and Intel. > > Their demos had bugs, they've since fixed the bugs - they've even > produced updated builds containing most of those bug fixes. They just > can't be bothered to update the links on their website to point to those > builds, so the general public can obtain working software. > > Shame on them. They should be embarassed. > > Other than Unigine, we have relatively few workarounds. #extension > directives anywhere is a fairly innocuous bug. Topogun may even be > fixed by now. We've been able to simply produce drivers that obey the > specification, and the majority of applications have worked just fine. > > I dislike compiling in workarounds because it's an arms race. Various > Unity 4 based games detect "Intel" and apply workarounds, breaking their > rendering unless you set UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS or > change the GL vendor name. IIRC these workarounds aren't even for the > Linux driver, and until all the games get rebuilt, we're stuck with the > issue. KWin disables functionality due to historic bugs in Mesa. > > This patch series is about making broken software work for people who > build their own drivers, but can't be bothered to install them > correctly. I find it immensely sad that we have to care.
Do we? I feel like they're an awfully small portion of our users, and as SteamOS grows, they're only going to diminish. "Doctor it hurts when I do this." > But given that we do have to care, this may be the right thing to do. > I understand where you're coming from, and I'm tired of fielding bugs > about this as well. Although I'm complaining loudly, I'm not NAK'ing > your patch series. If other folks are for it, then that's fine. I'm NAK'ing it. The enables were put into a system control file was so that distros could add enables for additional applications outside Mesa releases. I recall Redhat (Dave?) and Ubuntu being vocal about this. I suspect that this is a feature that Valve will want well, but I haven't verified this. Going from zero to the big hammer is not the answer. Several smaller hammers have been proposed. Try the small ones first. If the problem is what people "find on the internet," then make sure the correct instructions are the first search hit. Do we even have a link to "the" drirc on our wiki anywhere? Doing things to fix the fundamental problem will help prevent future, similar problems. Just caving in and making a choice that is only beneficial in the short-term is not going to help our long-term situation. The workaround were intended to be stop-gap solutions so that users could get applications working while we worked with application developers to fix their apps. This has worked with a lot of applications that people actually use. Putting what amounts to permanent workarounds in the driver (i.e., making it harder for the application developer to even see that their app is broken) won't help that. Not only that, but if the problem is that people don't have the right enables for a brand-new feature that's not even in a shipping version of Mesa, then this problem will just fix itself pretty quickly. Is this really so dire that we can't have a tiny bit of patience? Ken says "it's an arms race," and he's right. The only way to win is not to play. We also had an agreement when we started adding these workarounds that it would be controlled by an external, visible file. As soon as the file is either non-external or non-visible, that agreement is violated. > LIBGL_DRIVERS_PATH is an extremely convenient feature for developers; > I'd like to see it stay. > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
