Hello, On Tue, Apr 25, 2023 at 04:40 PM, Kaelyn wrote:
> Hi, > > ------- Original Message ------- > On Tuesday, April 25th, 2023 at 2:15 PM, Andreas Enge <andr...@enge.fr> wrote: > >> Hello Kaelyn, >> >> thanks for your research! > > You're welcome! :) > >> Am Wed, Apr 19, 2023 at 04:07:51PM +0000 schrieb Kaelyn: >> >> > * <https://issues.guix.gnu.org/62176> can be closed when >> > core-updates is merged, since core-updates contains mesa 22.2.4 >> > * Though not exactly mesa-related, >> > <https://issues.guix.gnu.org/61364> can possibly be closed now, and >> > almost certainly once the core-updates merge is completed. (The >> > ticket is a number of workarounds the user applied in early Feb to >> > be able to build their system profile using core-updates, to pick >> > up Mesa 22 for newer hardware support. I'm not sure if any of the >> > patches are still relevant.) >> >> I just closed these two. >> >> > * <https://issues.guix.gnu.org/58887> looks like an alternate way of >> > solving the layer path issues that >> > <https://issues.guix.gnu.org/59453> also addresses. Additionally, it >> > adds two new nonstandard VK_*_PATH variables to vulkan-loader, >> > with at least VK_ILAYER_PATH seeming very similar in functionality >> > to VK_LAYER_PATH and VK_ADD_LAYER_PATH described at >> > <https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md> >> > * <https://issues.guix.gnu.org/58251> would be fixed by >> > <https://issues.guix.gnu.org/59453> > > I feel these two can be closed once 59453 lands, as then the manifests > will have the store path to their corresponding shared objects. I also > think having the full paths in the manifests will lead to fewer > cross-version/cross-package mixing of objects, compared to setting and > using environment variables of directories to search. > I haven't looked at the details, but I'm guessing these can all be closed now? >> > * <https://issues.guix.gnu.org/62313> might need a modification to >> > mesa e.g. to add VDPAU_DRIVER_PATH as a native-search-path (one >> > possible solution; in my home profile I made VDPAU work by setting >> > "VDPAU_DRIVER_PATH=/run/current-system/profile/lib/vdpau"). >> > * <https://issues.guix.gnu.org/48868> appears to be the same >> > VDPAU_DRIVER_PATH issue as <https://issues.guix.gnu.org/62313>. > > For the VDPAU drivers, I plan to do a little more digging and some > experimenting but I suspect defining VDPAU_DRIVER_PATH as a > native-search-path is the best way forward. I'll send a patch once > I've tested a change locally without having my profile set > VDPAU_DRIVER_PATH to /run/current-system/profile/lib/vdpau. > I checked that both 48868 and 62313 were fixed in the recent updates and closed both. Thanks for the patches! John