[Mesa-dev] [PATCH 1/2] dri/common: embed drirc into driver binaries

[Ian Romanick]

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.velikov at gmail.com> wrote:
>>> On 3 September 2015 at 20:33, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Thu, Sep 3, 2015 at 3:30 PM, Marek Olšák <maraeo at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150908/144a31a9/attachment.sig>