Re: Moving amber into separate repo?

On Sun, 2022-09-25 at 12:08 +0200, Filip Gawin wrote:
> W dniu: Niedziela, Wrzesień 25, 2022 08:16 CEST, "Eric Engestrom"
> <[email protected]> napisał(a):
>  
> > Hi Filip!
> > 
> > Others have what explained why copying the repo (and everything
> > around it) is not a good idea, so I'll only reply to the other
> > points.
> > 
> > On 2022-09-22 at 22:37 UTC+02:00, Filip Gawin <[email protected]>
> > wrote:
> > > Hi, recently I've seen case of user been using Amber when
> > > hardware was
> > > supported by mainline mesa. This gave me a couple of thoughts.
> > > 
> > > 1) Users don't correlate "Amber" with "Legacy" and probably it's
> > > gonna
> > > be best to always also print "Legacy" together with "Mesa".
> > 
> > Could you explain *where* you would like to do this? I don't see
> > what *users* would see where this would help.
> > 
> > > 2) Not sure if problem of choosing best driver is on mesa's or
> > > distro
> > > maintainer's side, but it became more complicated for
> > > maintainers.
> > 
> > I think we should probably add a couple of lines in the meson.build
> > on the amber branch, like this:
> > 
> > if gallium_drivers.count() != 0 or vulkan_drivers.count() != 0
> > error("You shouldn't package Gallium or Vulkan drivers from the
> > amber branch; please only enable these in the standard Mesa package
> > build.")
> > endif
> > 
> > Do you think that would be enough to resolve the distro packages
> > maintainers' confusion?
> 
> 
> Hi, I think the problem with Amber is that the situation isn't clear.
> Branch appeared from nowhere and without clear goal. (Some commits
> for new drivers landed on it. So it may be giving wrong idea about
> LTS.) Moving into separate repo was my first idea to address this
> problem, but I agree it may not be best solution.
> 
> Overall I think we have problems:
> - branch is difficult to find (adding link in readme of main branch
> and renaming branch?)

I just merged this MR, hopefully that helps *a bit*:
https://gitlab.freedesktop.org/mesa/mesa3d.org/-/merge_requests/145

However, I agree that Amber needs more visibility, and I think linking
to it from README.rst is a good idea.

> - sometimes commits for drivers still supported by main branch are
> modifying gallium, so there's chance of regression (or accidental
> use). (we can disable them, but probably removing is better?)

Amber currently lives on a "normal" stable branch that AFAIU will just
be maintained longer. I don't think we'll end up merging very
controversial stuff there, but I do think that making this a "hard"
separeration into a "this branch is *only* about amber, not other
drivers as well" at some point is a good idea.

Not sure if that point is quite yet, but it might be. I guess this is
more a question for the maintainers.

> - people don't correlate amber and legacy. Here's video with with
> chipset 945g (915g) and lubuntu. https://youtu.be/nCjantxylV4?t=1160
> (btw there's another problem why 945g only advertise gl 1.4) So
> adding "Legacy" or "Legacy driver" after word Mesa my be a good idea.

I think the "Amber" naming was introduced to sound less "scary" than
"Legacy", similar to "perserved in Amber" (you know, like in Jurassic
Park)...

But that might indeed be a bit cryptic for some users. I'm not sure I
think "Legacy" is a whole lot better; it can sound a bit like they
should switch to a "non legacy" driver, but for most users that's not
the case; distros will AFAIK switch the ones that can use another
driver (e.g i965 users) to the appropriate one (Crocus/Iris), and the
rest are kinda stuck with Amber.

In the case of i945/i915g, I think the users are in the unfortunate
situation that no developers cared enough about them to do the heavy
lifting needed for a seamless transition, and someone with the
motivation will have to step up to the task if they want it to
improve...

From a quick peek, it might be as simple as to always exposing
PIPE_CAP_OCCLUSION_QUERY in i915g, matching what we did for i915:

https://gitlab.freedesktop.org/mesa/mesa/-/commit/97217a40f97cdeae0304798b607f704deb0c3558

Alternatively, it might be possible to use MESA_GL_VERSION_OVERRIDE to
pretend instead of hard-coding it. Dunno. As far as I can tell, i915
supporting OpenGL 2.0 was always a a lie anyway, not sure who should be
telling the lie here ;)