Last steam-manjaro version with pvkrun, does not run the dedicated gpu and vulkan #77
Comments
|
Could you share the output with the environment variable |
|
This is the result: `Manjaro steam native configuration found! (steam:2798): Gtk-WARNING **: 20:58:21.609: Unable to locate theme engine in module_path: "murrine", (steam:2798): Gtk-WARNING **: 20:58:21.632: Unable to locate theme engine in module_path: "murrine", (steam:2798): Gtk-WARNING **: 20:58:21.632: Unable to locate theme engine in module_path: "murrine", (steam:2798): Gtk-WARNING **: 20:58:21.632: Unable to locate theme engine in module_path: "murrine", (steam:2798): Gtk-WARNING **: 20:58:21.649: Unable to locate theme engine in module_path: "adwaita", (steam:2798): Gtk-WARNING **: 20:58:21.650: Unable to locate theme engine in module_path: "adwaita", (steam:2798): Gtk-WARNING **: 20:58:21.653: Unable to locate theme engine in module_path: "murrine", (steam:2798): Gtk-WARNING **: 20:58:21.653: Unable to locate theme engine in module_path: "murrine", (steam:2798): Gtk-WARNING **: 20:58:42.343: gtk_disable_setlocale() must be called before gtk_init() |
|
So we can see: the nvidia driver is loaded, however it does not report a device. From the output, I can see, that you didn't remove Loading the nvidia driver twice (once unwrappend and once wrapped) can cause the wrapped driver to not work (and the unwrapped driver never works on optimus laptops in any case). The "real" error message is |
|
I deleted the json file and tried running pvkrun steam, but it showed the same above mentioned error again. Something very curious: I ran lutris with pvkrun, it detects my nvidia gpu with no problems. Then, without closing lutris, I ran pvkrun steam, and it also correctly detected my nvidia gpu. But of course, if I close steam and lutris, and then run only pvkrun steam, it doesn't start nvidia and again shows the error. [zimudec@zimudec ~]$ VK_LOADER_DEBUG=info pvkrun lutris Without closing lutris: [zimudec@zimudec ~]$ VK_LOADER_DEBUG=info pvkrun steam (steam:7774): Gtk-WARNING **: 20:52:37.110: Unable to locate theme engine in module_path: "murrine", (steam:7774): Gtk-WARNING **: 20:52:37.112: Unable to locate theme engine in module_path: "murrine", (steam:7774): Gtk-WARNING **: 20:52:37.112: Unable to locate theme engine in module_path: "murrine", (steam:7774): Gtk-WARNING **: 20:52:37.112: Unable to locate theme engine in module_path: "murrine", (steam:7774): Gtk-WARNING **: 20:52:37.114: Unable to locate theme engine in module_path: "adwaita", (steam:7774): Gtk-WARNING **: 20:52:37.114: Unable to locate theme engine in module_path: "adwaita", (steam:7774): Gtk-WARNING **: 20:52:37.116: Unable to locate theme engine in module_path: "murrine", (steam:7774): Gtk-WARNING **: 20:52:37.116: Unable to locate theme engine in module_path: "murrine", (steam:7774): Gtk-WARNING **: 20:52:45.026: gtk_disable_setlocale() must be called before gtk_init() |
|
When you run |
|
you can also try to run |
[zimudec@zimudec ~]$ pvkrun steam (steam:3150): Gtk-WARNING **: 20:52:02.951: Unable to locate theme engine in module_path: "murrine", (steam:3150): Gtk-WARNING **: 20:52:02.954: Unable to locate theme engine in module_path: "murrine", (steam:3150): Gtk-WARNING **: 20:52:02.954: Unable to locate theme engine in module_path: "murrine", (steam:3150): Gtk-WARNING **: 20:52:02.954: Unable to locate theme engine in module_path: "murrine", (steam:3150): Gtk-WARNING **: 20:52:02.966: Unable to locate theme engine in module_path: "adwaita", (steam:3150): Gtk-WARNING **: 20:52:02.967: Unable to locate theme engine in module_path: "adwaita", (steam:3150): Gtk-WARNING **: 20:52:02.972: Unable to locate theme engine in module_path: "murrine", (steam:3150): Gtk-WARNING **: 20:52:02.972: Unable to locate theme engine in module_path: "murrine", (steam:3150): Gtk-WARNING **: 20:52:11.039: gtk_disable_setlocale() must be called before gtk_init() When I run only I checked with darkest dungeon and sleeping dogs definitive edition with proton GE-5.5-1 (both run without issue over the older version of steam-manjaro with Will I have to do the same for each game? will there be a more elegant solution? why does this affect only steam? (well it might affect another app as well and I haven't checked yet) |
[zimudec@zimudec ~]$ ENABLE_PRIMUS_LAYER=1 optirun -b none steam (steam:7098): Gtk-WARNING **: 21:12:19.580: Unable to locate theme engine in module_path: "murrine", (steam:7098): Gtk-WARNING **: 21:12:19.605: Unable to locate theme engine in module_path: "murrine", (steam:7098): Gtk-WARNING **: 21:12:19.605: Unable to locate theme engine in module_path: "murrine", (steam:7098): Gtk-WARNING **: 21:12:19.605: Unable to locate theme engine in module_path: "murrine", (steam:7098): Gtk-WARNING **: 21:12:19.620: Unable to locate theme engine in module_path: "adwaita", (steam:7098): Gtk-WARNING **: 21:12:19.621: Unable to locate theme engine in module_path: "adwaita", (steam:7098): Gtk-WARNING **: 21:12:19.624: Unable to locate theme engine in module_path: "murrine", (steam:7098): Gtk-WARNING **: 21:12:19.624: Unable to locate theme engine in module_path: "murrine", (steam:7098): Gtk-WARNING **: 21:12:28.288: gtk_disable_setlocale() must be called before gtk_init() With that steam command it starts perfectly with the dedicated gpu! unlike with pvkrun steam (result shown above). I tested sleeping dogs which requires vulkan to work, and it seems to run without any problems, without any launch parameters in properties. With |
|
Yes, probably we need to get more debug output from Regarding adding |
|
Yes, this version of steam messes around with the Here are my observations: When changing a game's run command to Running and vulkan application with that environment fails, as we don't use the |
|
This is the issue, I opened against the steam-runtime: ValveSoftware/steam-runtime#274 |
|
I also opened this issue about a problem with libglvnd 1.3 and steam. It may be related to the LD_LIBRARY_PATH problem. This causes me other problems running certain games mentioned. https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/211 This issue of pvkrun, primus and steam, I have always tested them with libglvnd 1.1, so as not to mix the 2 problems. |
|
I add to the above: Some time ago, rise of tomb raider native to linux worked fine, but recent tests (independent of the version of steam and libglvnd), it fails showing the following error:
I sent the dump file delivered by tomb raider to Feral, and they tell me that the cause of the error seems to be related to the vulkan libraries of the operating system. They gave me possible solutions, but without success. They can't give me any more help because they don't support manjaro. This may have some indirect bearing on this whole primus, steam and vulkan thing. |
|
... I also have both the tomb raiders (rise and shadow) and they both work flawlessly on my system. However I always add "pvkrun" to the individual games and not to steam as a whole. The crash message itself will not be really useful, you will probably have to start the game in a debugger to get a stack trace. "the errors seems to be related to the vulkan libraries" can mean anything (from "driver not found" to "segfault inside a vulkan driver"). Do you have standard output from that game starting? |
Using that methodology, running How can I debug the .dmp file and deliver a readable result of what is inside? |
|
Ok, so this looks like, we don't even reach primus_vk from the game. I don't know how one would open .dmp files. That's a fileformat called minidump, which you would first need to convert into a regular coredump and then maybe inspect with gdb. Luckily enough, Rise of the Tomb Raider is pretty easy to start manually, and the startscript has an option for inserting gdb right before the game launches: When the segfault hits, gdb will prevent the program from crashing and allow you to get a backtrace with the |
|
I believe I got an idea what could be wrong in your case. I have found the sources for manjaro's bumblebee here: https://gitlab.manjaro.org/packages/community/bumblebee, but I can't find the sources for the (OpenGL)-primus package. Can you show me where the source code for the manjaro package for (OpenGL)-primus is, so I can validate my theory? |
i ran the command and then typed `[zimudec@zimudec Rise of the Tomb Raider]$ STEAM_RUNTIME=1 GAME_LAUNCH_PREFIX="gdb --args" pvkrun ./RiseOfTheTombRaider.sh For help, type "help". |
I do not understand, in what path can I find the source code? Is it any of these? [zimudec@zimudec Rise of the Tomb Raider]$ locate primus |
|
When using Regarding the sources of the primus package: No, these are files installed on your system by the primus package. What I wanted to know is where I can find information on how the primus package is built for your distribution (so, what source code variant goes in it? Are there special tweaks by the packager, ...). Does manjaro have all packages contained in archlinux or it it a totally separate package repository? E.g. for archlinux I can find the sources for the primus package here: https://github.com/archlinux/svntogit-community/tree/packages/primus/trunk these show me, that for archlinux there is a "register_cleanup"-hook inserted and additionally, a |
I ran run using that command, but on the screen I got the error "Failed to load steamui.so". Apparently that error is triggered when using STEAM_RUNTIME = 1. However, if I wait a while, the game runs anyway, and shows the segfault error. So I press the button to make the error disappear, I go to the terminal, and it is not stopped. I type bt and it returns No Stack. I tried the same procedure with STEAM_RUNTIME = 0, the game starts faster and does not give steamui.so error, but bt returns No Stack as well. |
Maybe you mean this? https://www.archlinux.org/packages/community/x86_64/primus/ |
|
Thanks for the gdb output, ok I think we need to remove the So just moving the signalwrapper out of the way (e.g. by renaming it to Regarding the 2 source links: The lower link is the "original" source repository. I already know that. I wanted to know, if there are manjaro-specific adjustments. The upper link shows me the archlinux package. That's where I got this svntogit-link from. Are you sure that this is also the source for manjaro? Does manjaro just take all packages from archlinux without modification, when there is not specific manjaro source? |
|
I managed to run the procedure and got the trace. I don't know what the cause is: |
I get it. The packages from the pacman repositories are, I understand, compiled only. I only know about the aur repository from non-compiled sources. I also do not know if before being compiled and uploaded to the pacman repository, they are given special treatment. |
|
In the stack trace the source line numbers are missing, even for primus_vk. Could you compile primus-vk with debug symbols (and tell me the commit you are using), so we can see the line numbers of the two primus frames? Activating debug symbols is done with the Even without line numbers, we can already see that the crash itself happens in the in the |
Regarding the first paragraph, I am very lost. Regarding the second paragraph, I ran the same command above, prepending I added Questions:
|
I've seen in the backtrace that there is a vulkan layer named
Yes, I believe it is. As far as I know, this layer is intended to allow a user to sort a specific graphic device to the front to suggest to an application application to use it. With primus_vk you don't need this, as primus_vk only exposes on graphics device, the "hybrid"-graphics device, to the application. Primus_vk itself needs to see both the internal and the dedicated device, so having
Yes, we should understand why the mesa layer crashes what the assumptions there are, why they are wrong and report a bug to mesa, if we are sill certain that this is a mesa bug. But for that we need the debug symbols. Without line numbers this back trace doesn't help us much further. I'll try to help you as much as I can being unfamiliar with arch. I found this wiki article which seems to fit what we want to do: https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces (Currently: getting debug symbols for the package where Judging from the backtrace alone, we could be somewhere in this function: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/vulkan/device-select-layer/device_select_layer.c#L357
Right now, I don't think that this is a problem caused by the game and the game only has legitimate usage of the Vulkan API. If understanding why |
Sorry, I hadn't had time to review. The truth is I am familiar with Linux, but not so advanced. I missed a lot at this point, especially on a conceptual level. I'm going to test the package creation first, with the instructions given. Once the creation works, I will have to install it with pacman, right? as if it were a downloaded package ready to install? If I install and something fails to boot, I assume that from terminal with F2 I could restore the package by installing the one I had previously, right? I have not yet updated to the latest version of manjaro, therefore, not the latest version of table either. Will it cause problems if this version is more current than the one installed? as a test? |
Yes, you install the package exactly the same way you would install a manually downloaded one. Essentially, the packages that you download have most likely been created the same way using
Yes, I doubt that changing something in mesa can prevent the system from booting completely (and thereby preventing access to the ttys). If the GUI fails, the ttys are the easiest way to restore your system. I'd suggest you download the mesa package that is currently installed from here: https://archive.archlinux.org/packages/m/mesa/
Probably not, upgrading mesa usually works very smoothly. However we want to reproduce the error that occurred with that version of mesa that is currently installed on your system, so it would be best if you would build exactly the version that is currently installed. I'd recommend that you go through the history (https://github.com/archlinux/svntogit-packages/commits/packages/mesa/trunk/PKGBUILD) and look for the exact mesa version that you are currently using and try to build debug symbols for that version. |
Can't find a file! |
|
... I would have needed The |
Do you have the source code for that file? So is it correct?: |
|
Ok... so |
I did the above, but after |
|
Ok, we hit the segfault directly after we hit our breakpoint, but the function is not null. I still don't understand why we segfault probably, we need to look at the disassembly: .... sorry that it take so many roundtrips, but debugging is sadly kind-of interactive... |
Don't worry, I understand perfectly. I still want to know the real cause of the problem instead of just looking for an alternative path. |
|
... Thanks for the next round: in this disassembly section I can see, that there doesn't happen anything suspicious. Judging from the address in the segfault-backtrace, which ends with I believe that the function that is pointed to here is I believe the jump that we will take (which leads to the segfault) is the one at address This should allow us to determine, if the function is missing (in that case the nvidia driver might have misbehaved) or if there is a function where the segfault happens inside. |
|
Let's see if what I understood is correct: |
|
Thanks for the gdb output. I believe this confirms the theory that at least one ICD is not returning I believe this is mesa's fault, as in this case mesa is not compatible with vulkan 1.1. Vulkan ICDs compatible with Vulkan 1.1 need to implement However there is still something that I don't understand: the mesa device select layer has to see that the extension So next gdb, let's validate the theory that the vulkan-loader thinks the extension is disabled. The memory-addresses I see from your output seem stable, so assuming that you didn't recompile anything, I can just specify literal addresses which seems easier to me. If the addresses changed, you would need to update the address in the commands accordingly. EDIT: So it would be nice, if you run also this, so we can check which functions mesa returns on your system, with the extensions/api version requested by the game: |
I have the following version installed, both in 64 and 32 bits: vulkan-icd-loader 1.2.151-1 I don't know if it is related, but I have the following content in the file /usr/share/vulkan/icd.d/nv_vulkan_wrapper.json:
This right?:
|
|
Thanks for the gdb output. I believe I was able to reproduce the problem locally. The problem occurs when the mesa layer is inserted "below" primus-vk. On my system it was always inserted above primus-vk, so I didn't experience any problems. I forced the layer ordering and could reproduce the segfault. Short story what is happens (with annotations about what happens with the fix):
Could you please try out the fix, I have pushed here: https://github.com/felixdoerre/primus_vk/tree/mesa_layer_fix ? |
Great! how can i test this fix? primus I installed it (and install or update it) normally by pacman. The current version I have of pacman is: primus_vk 1.5-1 Should I download that version and compile to install the modified package like I did with mesa? Why in your system are the layers loaded in a different order from mine? |
|
The layers are loaded in the order the the filesystem lists the corresponding json files. So this could be anything, from the order we installed packages in to filesystems structuring the on-disk layout of the directory contents differently.
I'd suggest the "quick and dirty" way: just clone this repository and checkout the corresponding branch, run If you really want a package I guess you could download https://github.com/archlinux/svntogit-community/blob/packages/primus_vk/trunk/PKGBUILD and adjust the versions/hashes in that file, but I don't really know how arch packaging works so I will probably only be of little help. The difference between this package and the mesa package, is that you want to really change the contents of the package and not just the configuration options, so it might be more difficult. |
I downloaded the zip from the url, entered and ran by terminal make, and it returned the following: I installed some vulkan libraries for developers, and was able to compile. Now I do the tests. EDIT: When compiling it generated the file How I should proceed? |
|
That's ok, copy |
haha I'm learning a lot here. I copied the compiled file to /usr/lib/libprimus_vk.so.1 I ran the game command again, and it threw me the following: The launcher did not start |
|
I don't really understand what goes wrong here. Probably we will need line numbers/debug symbols in libvulkan, to understand better why here an invalid call to free happens. So could you please choose the corresponding version for libvulkan from here: https://github.com/archlinux/svntogit-packages/commits/packages/vulkan-icd-loader/trunk and compile your vulkan-loader with debug symbols? |
|
I did the following: 1- I downloaded the same version that I have installed I ran the command to test tomb rider and I have the following: Is it correct? |
|
Yes, perfectly. However I still don't understand what's wrong. I think the loader should never go into |
|
Good news! I had a hunch on what could be different on your setup vs. my setup and changed the order the drivers where loaded in. This allowed me to reproduce the new problem locally. This might be a vulkan-loader bug. I will open an issue there and ask about it. Understanding the problem allowed me to create a workaround. I pushed it here: https://github.com/felixdoerre/primus_vk/tree/mesa_layer_fix |
I did the following:
Sure, starting steam with optirun, just with steam and adding the pvkrun parameter to the game. Both work :D In this thread we apparently discovered a couple of bugs in libraries external to primus_vk, right? |
Regarding bugs in other components:
In any case, I will merge the "mesa_layer_fix"-branch into master, so these problems should not occur anymore, even if the vulkan loader does not fix anything. |
Well, this was an extra setting for better compatibility :) well, in addition to the above, with the steam-manjaro update, due to the primus problem (if I remember correctly), you cannot start steam with pvkrun directly, since it does not detect the dedicated gpu. But with optirun it works without problem, if not, start without optirun or pvkrun, and use pvkrun in the launch parameters for each game separately. |
I think we are mixing 3 different things here:
I believe the state for steam is that it breaks the activation of (OpenGL)-primus. When launching steam with And from the discussion in the steam-runtime repository I got that it only will get worse: When Steam (or individual games) will run inside a "pressure vessel" (a container) both (OpenGL)-primus and primus-vk can not work, as they both will not be installed/available from within the container. Additionally, also bumblebee is not available from within the container, so powering on the gpu from within the container is not possible. Getting that to work will require active work from the steam-runtime repository to "copy/install" primus and primus_vk inside the container and mount the bumblebee socket when it is detected outside, which will be hard. Also they seem to be very reluctant to fix (I'd sill call this behavior a bug, with or without primus and primus-vk) the situation for the current runtime-variant. |
What does it mean that |
That means that applications that use Vulkan as graphics API will be accelerated through primus-vk (modern games or directx9/10/11/12 emulated through dxvk), and applications that use OpenGL (older applications or directx9/10/11 emulated through the implementation provided by wine) will run only on the integrated graphics card. |
Interesting, I think I have not come across that case. But it is clear then that this can happen to me with optirun. After this journey, what do we do with this issue? do we consider it solved? |
|
I think we have understood all behavior and have tried to report that to the corresponding repositories. I am not sure if they will fix/improve anything, but I think from primus_vk nothing more can be done and we should consider this ticket solved. |
The latest version of steam-manjaro (1.0.0.66-1) still shows an error when trying to run vulkan:
I go back to the previous version (1.0.0.61-7) and pvkrun with vulkan, steam and optimus works without problems.
I do not know the cause of the problem, I need guidance.
The text was updated successfully, but these errors were encountered: