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

[Kenneth Graunke]

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.

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.

LIBGL_DRIVERS_PATH is an extremely convenient feature for developers;
I'd like to see it stay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150906/85ddc976/attachment.sig>