See architecture
- mesa-dri can be used together with nvidia-driver
- Consumers can depend on the latest GLX/EGL headers
- Less rebuilds due to changes in dependencies
Differential D25020
graphics/mesa-libs: enable libglvnd support jbeich on May 27 2020, 7:44 AM. Authored by
Details
See architecture
Diff Detail
Event TimelineThere are a very large number of changes, so older changes are hidden. Show Older Changes
Comment Actions
Comment Actions
Comment Actions Hi! Apart from the comments inline in the review, we also need to figure out how to handle mesa. Currently, the patch adds a build dependency in mesa-libs on libglvnd, and other ports depend on libglvnd through Uses/gl.mk. However, libglvnd will need mesa (or another OpenGL provider) to be installed. With the suggested patch this is only pulled in by accident by the dependency on libgbm.so in a few ports. This means that simple installs might not have all the packages needed to work. This needs to be fixed, most likely by an explicit runtime dependency on mesa in libglvnd, or through Uses/gl.mk. This will mean that users of nVidia drivers will have two OpenGL implementations, but that is already the case today. If/when the ports tree gains a requires/provides, this can be revisited. Over all, there are several things that need to be fixed in order for this to be accepted, and it has to be thoroughly tested as well, since it is a very large change to how the graphics stack is working.
Comment Actions No difference from mesa-libs. xorg-server and wlroots still depend on mesa-dri and mesa-dri depends on mesa-libs (via libglapi). Why one would want mesa-libs but not mesa-dri?
Assuming NVIDIA users don't want mesa-dri is a mistake. Barring bugs in kernel drivers it should be possible to use Intel/AMD and NVIDIA at the same time e.g., with multiple displays or one display connected to multiple GPUs.
What are these? I agree with maintainership, the rest is misunderstanding.
Comment Actions
Comment Actions Hi! Comment Actions Based on the amount of QA required, big would be Xorg update, medium would be Mesa update and small are libglvnd, libX11, libwayland, etc. libglvnd offloads updates risk due to API changes away from Mesa. For example, Mesa has Intel/AMD, X11/Wayland/Vulkan and drm-kmod (legacy, 4.1[16], 5.*) but in Xorg has CSM/UEFI, UMS/KMS, non-x86, many DDX, nvidia-driver versions, legacy/devd/libinput, slave/consumer ports. In short, as you go up the graphics stack the implicit QA via consumers diminishes.
11.4 packages use rP536699 instead of /quarterly but updates use /quarterly which is a moving target (i.e., can be fixed/reverted).
Makes sense given only 1 month is left while exp-run hasn't even started (antoine@ doesn't scale).
Review/test in advance then (EDIT: during the waiting period). I can't respect maintainer which doesn't respect me. |