On Wed Apr 24 08:59:33 2024 +0000, Oscar Barenys wrote:
Hi, first sorry in advance for joining here to ask some question.. but it's somewhat related to work like this, so let me explain.. I'm interested on testing things that depend on DXVK-NVAPI, mainly DLSS content (like NV Path Tracing SDK for ex.) outside of Proton (i.e. using Wine-staging builds, like Kron4ek builds for ex.).. on X11 no problem, but on Wayland wasn't working.. but I learned asking here: https://github.com/jp7677/dxvk-nvapi/issues/165#issuecomment-1983594720 that: "Upstream Wine relies on xrandr providers to assign LUIDs to GPUs.." etc.. etc so the issue was related to adapter LUID being NULL on Wayland and that there was a Proton patch to fix the issue: https://github.com/ValveSoftware/wine/commit/e8801e96fedf67b88e6f3f5d9f9e2d9... following learning that, asked Kron4ek to integrate patch: https://github.com/Kron4ek/Wine-Builds/issues/124 which kindly agreed.. the thing is, the patch pointed doesn't stand the test of time well, and almost every Wine version requires some changes (not very difficult yet).. which I keep doing and posting here: https://github.com/Kron4ek/Wine-Builds/issues/124 the latest one for Wine 9.6 for ex.: https://github.com/Kron4ek/Wine-Builds/issues/124#issuecomment-2049087722 elaboration on the context done, I'm asking two things:
- as the changes needed for the patch seems constant and are due to
PRs/commits like this, "restructuring" WineX11 and WineWayland Vulkan use, I'm asking if makes sense for me on keeping the patch updated or soon this patch will be unneeded with all your changes (i.e. the support will be builtin on Wine or will be integrated in some way).. also, can share if there is much restructuring remaining, i.e. if the patch will survive better, soon? 2) this question is more demanding, as this patch doesn't cover/work when running DLSS content in new "Wine's 9.0 native wayland mode".. i.e. LUID is NULL running DXVK-NVAPI so DLSS doesn't work.. until now, no much interest, but now, that learned that "Wine's native wayland mode supports HDR through DXVK" via VK_hdr_layer (https://github.com/Zamundaaa/VK_hdr_layer), I'm more interested on running DLSS+HDR content via native Wine Wayland.. as I have really no idea of Wine code, can share how much work would be to do a similar patch (for wineWayland?) so exposing LUIDs correctly when running in native wayland mode? are Wine devs interested in doing a "Wine native wayland" LUID fix patch, one for either Proton or Wine Staging relatively soon? I say this, because at least my testing of Proton 9.x (https://github.com/Kron4ek/Wine-Builds/releases/tag/proton-exp-9.0) shows there is no equivalent support/patch for Proton yet.. to end, as said before can post this issue in other "more appropiate" place if wanted/requested.. would love to have a issues site here in Wine gitlab much like Mesa for issues that are not for posting in www.winehq.org/pipermail/wine-users, right? thanks..
This is not the best place to discuss unrelated bugs or patches, or workflow in general. It would be better to either open a Bugzilla entry if there's a bug, or send an e-mail to wine-devel if you want to discuss about downstream workflow, or ask for help / advice about maintaining a patch.
Yes, downstream patch maintenance is sometimes a burden, and I'm sorry these changes are causing trouble. We rebase Proton changes every major release, or when we need to cherry-pick upstream changes, but doing that on every upstream change would be too much time consuming. We are very grateful to the community for doing that work, and happy to help as much as we can, but we also cannot keep track of every patch and conflicts out there.
Then, I wasn't even really aware of that patch (even though github says I'm the author I'm sure I'm not), but it looks reasonable, although probably better done in win32u, and I'll send something after https://gitlab.winehq.org/wine/wine/-/merge_requests/5422 is merged.