Re: Moving amber into separate repo?
W dniu: Niedziela, Wrzesień 25, 2022 08:16 CEST, "Eric Engestrom"
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 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?)
- 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?)
- 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.
Re: state of EGL support on MacOS?
Reading through the mesa source, it seems that GLX uses hardware OpenGL support on Darwin that was supplied by Apple initially in 2010, and updated since (apple subdir in glx). But if I am reading it correctly (and I easily might not be), the EGL implementation on mesa does not use Apple hardware support, but instead software rendering. So — even though mesa with EGL will build on Darwin, performance would be very much below GLX, so best avoided. I have patched the gtk4 source to avoid requiring EGL for now, and forced GLX to be used always. If I’m way off here, appreciate anyone putting me on the right path. Best, Ken > On Sep 12, 2022, at 9:50 PM, Ken Cunningham > wrote: > > Hello, first post. > > I would like to ask about the status of EGL support in mesa for MacOS > systems, whether it is mature and robust and usable at present for software > builds. I know it can be toggled on in the mesa build on Darwin systems, and > it generates. EGL headers and libraries. But is seems to be little used at > present, as far as I can see. > > Why: > > I help maintain ports at MacPorts. Many of these use the gtk3 x11 version of > the software, using an x11 server like xorg-server or XQuartz to display > them. (A lesser number of software projects can use the gtk3 quartz interface > instead.) > > Lately, perhaps related to wayland, it seeems a number of software projects, > eg gtk4, have been written assuming that x11 software will have EGL headers > and libraries available, with GLX as a fallback. > > If there are no EGL headers and support libraries available, these projects > don’t readily compile without a fair bit of surgery to #ifdef out the assumed > EGL support. It would be much easier to just use EGL instead, from mesa or > otherwise, if it is robust. > > Thanks, > > Ken
