[Feature Request] Vulkan support in Bumblebee/Primus

[edoantonioco]

Hello, I have tried with windows vulkan demos (on wine staging), the talos principle (which on the logs says than it use the intel card even if I use primusrun, only when trying to run it with the vulkan renderer), and the vulkan caps viewer (which can only sees the intel gpu even if I use primusrun), and it does not work, because when I try "primusrun randomVulkanApp' (for example), it never use the nvidia card, it uses the intel card.

My hardware is intel haswell, nvidia 960m, driver 364.19, Manjaro

[ArchangeGabriel]

Yes, that’s expected. We don’t support Vulkan at all currently, and it’s probably not going to happen any time soon. I’m wondering what’s the status of PRIME on this thought. Is there any native Linux Vulkan demo thing that reports the used card for me to test that?

[edoantonioco]

This is a shame, because for what I have seen PRIME is a technology than its meant mainly for ubuntu-based distros, and I guess than I could modify the Xorg.conf to only use the nvidia card, but on a laptop I also want to use the intel card.
Anyway, I havent found a vulkan demo easy to install without having to compile and etc, but if you want a software than tell you what card you are using, I found two ways, 1st is the talos principle, on the log it will tell you. 2nd, the vulkan hardware capability viewer, on the GUI appears which card it is detecting.
I hope than support for this new API will happen soon

[ArchangeGabriel]

I think you’re confused about PRIME. What you cite is Nvidia reverse PRIME. But PRIME is way more than that (take a look at default PRIME function: https://wiki.archlinux.org/index.php/PRIME#PRIME_GPU_offloading).

However, after sleeping a bit, I found the answer by myself: Vulkan won’t work with PRIME currently, at least because they are no Vulkan driver in Mesa at all (and the only one that is coming for sure is Intel, which AFAIU we don’t need here). Nevertheless, it might work in reverse PRIME indeed. But that’s not ideal, granted.

For our purpose, it would take someone adding Vulkan support in Primus just like OpenGL is supported right now. I’m not sure anyone having this capacity is willing to spend time on this, especially given that in the individuals around this project I count at most 2 that could: @karolherbst, but he is busy developing nouveau — which is a far greater priority — and has already stated that he won’t maintain Primus ; a discussion that happened because the other one people I think of, @amonakov, actual Primus dev and maintainer, is almost MIA.

So, I’m sorry about this (not just for you, I would love to see that too), but unless you manage to find someone who can and want to implement this, nothing is going to happen here.

[karolherbst]

@ArchangeGabriel there is an intal vulkan driver already, but I thought that offloading on other GPUs is already builtin into vulkan?

Well, if not, then they always forget the important bits

[ArchangeGabriel]

I know about the Intel driver (first parenthesis in my previous message), but I thought that like in OpenGL case, we don’t care about the Intel part, only Nvidia side. However, you might well be right about offloading, I remember having read something about this and the ability to use very heterogeneous setups in terms of graphic cards. Which probably requires Vulkan on both sides.

So, in the end, if that’s right, maybe we could do something in Bumblebee for Vulkan support (it probably comes down to the --no-xorg option in fact, ensuring driver loading and paths setting, or a modification of it to take Vulkan into account).

[bluca]

Something else to keep an eye on is libglvnd: https://github.com/NVIDIA/libglvnd
Upstream's NVIDIA driver already uses it (coming in Debian as soon as the new versions clear the NEW queue), and work is going on to have Mesa use it.
Once they both do, it might be an alternative to Primus, maybe?

[Amanieu]

Some quick experiments when running vulkaninfo under optirun (I am using the proprietary drivers):

• optirun vulkaninfo will only recognize the Intel GPU.
• DISPLAY=:8 optirun vulkaninfo will recognize both the Intel and Nvidia GPUs.

So it seems that Nvidia's vulkan driver only works if DISPLAY points to an X server running on the Nvidia GPU. Of course this isn't very useful for my laptop since that X server isn't connected to a screen, and no windows appear for graphical applications.

[karolherbst]

@Amanieu that is most likely the case because nvidia isn't loaded and the GPU is off.

What is the output of optirun -b none vulkaninfo?

[Nightbane112]

@Amanieu @karolherbst Maybe something like this perhaps?

Intel HD 4000 , Nvidia GT 730M, Driver ver. 364.19, Antergos

optirun -b none vulkaninfo
http://pastebin.com/11VyuJrz

DISPLAY=:8 optirun -b none vulkaninfo
http://pastebin.com/jsgBVdHq

[ArchangeGabriel]

While running vulkaninfo, I’ve got:

Xlib:  extension "NV-GLX" missing on display ":0".
Xlib:  extension "NV-GLX" missing on display ":0".
WARNING: Haswell Vulkan support is incomplete
anv_device.c:429: FINISHME: Get correct values for VkPhysicalDeviceLimits
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
gen7_pipeline.c:241: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO

And I’ve attached the output of:

• vulkaninfo: vulkaninfo.txt
• optirun -b none vulkaninfo: vulkaninfo_optirun.txt
• DISPLAY=:8 optirun -b none vulkaninfo: vulkaninfo_optirun_display.txt

[karolherbst]

odd that the nvidia GPU isn't found in the case without DISPLAY.

[AnAkkk]

Would that be a bug in the Nvidia driver that Vulkan doesn't work with Optimus laptops? I've tried to contact Nvidia about it, but they didn't reply.

[ArchangeGabriel]

I think so.

[snj33v]

mesa 12.0 now has glvnd support, hope it solves some problems

[edoantonioco]

This seems to be a step forward fixing this
https://devtalk.nvidia.com/default/topic/974876/vulkan/getting-vk_error_incompatible_driver/post/5032419/#5032419

[TiZ-HugLife]

I just tried it with nvidia-378.

optirun -b none vulkaninfo: http://paste.ubuntu.com/23874988
DISPLAY=:8 optirun -b none vulkaninfo: http://paste.ubuntu.com/23874993

vulkaninfo crashes on my system with DISPLAY=:8 set. vulkaninfo: /build/vulkan-PwwbqY/vulkan-1.0.37.0+dfsg1/demos/vulkaninfo.c:978: AppDumpSurfaceFormats: Assertion '!err' failed.

[khalismur]

Bumblebee development is totally dead? Any way to run Vulkan with it?

[snj33v]

no way to run vulkan with bumblebee as now, @edoantonioco comment is interesting

[monotykamary]

I feel like there is some misunderstanding here. If you have nvidia's recent stable driver 378.13, you can run Vulkan without X running perfectly fine with bumblebee. Assuming our main display environment is DISPLAY=:0, running DISPLAY=:1 optirun --no-xorg vulkaninfo | grep GPU will display both integrated and discrete GPU. Mine in particular shows:

GPU id       : 0 (Intel(R) Ivybridge Mobile)
GPU id       : 1 (GeForce GT 640M LE)

In fact, it doesn't matter if you change the environment DISPLAY to 2, 3, or 8 since we've just removed the need to spawn an X server with optirun --no-xorg. What we really care about is displaying it to our main display. Unfortunately we come back to needing the same methods of development for Vulkan as we did for OpenGL.

Either we do screen scaping, which has many drawbacks, or we continue with extension forking. VirtualGL chose to do GLX forking for OpenGL. Primus is essentially the same thing without the overhead requirements for multiple users. However, even primus now doesn't support all OpenGL functions, like the issued glXAllocateMemoryNV and glXFreeMemoryNV.

We basically need a VirtualVulkan to do VulkanX forking and/or a low-client overhead equivalent. Writing all of Vulkan's extensions, with the API still changing and growing, would be very tedious and annoying.

[TiZ-HugLife]

Wasn't GLVND supposed to be an important step toward fixing this sort of thing? And doesn't Vulkan have that kind of functionality just built right in? Where does GLVND fit in, in the scope of what bumblebee and optirun are meant to do? What does it not do that needs to be done?

[monotykamary]

As far as I understand it, libglvnd only arbitrates between multiple drivers/vendors in a way that allows each driver to ship its own OpenGL library without overwriting the main system libGL file. With the removal of libglx symlinks in xorg-server and libglvnd support in mesa, you can install mesa along with nvidia whereas before you would have to remove mesa-libgl for nvidia-libgl and vice-versa. It would allow mesa to call from /usr/lib/libGLX_mesa.so and nvidia to call from /usr/lib/nvidia/libglx.so. Since the OpenGL calls between these drivers can be run on a per-screen basis, it would be possible for you to run 2 X servers for iGPU and dGPU without much configuration. I have succeeded in running both and nvidia-xrun still works as designed.

This doesn't change the state of render offloading. Vulkan does not have this functionality built-in as it does not arbitrate its own API calls to X. As of now, it looks like libglvnd currently only supports OpenGL API calls and not Vulkan.

As to where libglvnd fits in bumblebee... it doesn't? I don't see any updates on bumblebee-devel regarding it so GLX forking seems unchanged. Maybe VirtualGL added updates for it, but I doubt it. Absolutely no updates for primus.

[Lekensteyn]

@monotykamary Some (Arch Linux at least) is patching Bumblebee with #845 for libglvnd support

[Thulinma]

@Lekensteyn As I mentioned on IRC, that sounds good to me. Do you want to do it, or shall I?

[Lekensteyn]

@Thulinma Go for it!

[Sangeppato]

@Thulinma Sorry for the stupid question, but will this work on wayland as well?
Thanks

[JeffLabonte]

@Thulinma I have tried your solution out of curiosity on Rise of the Tomb Raider. The launcher detects the vulkank drivers but the game isn't actually able to start correctly.

One more step towards victory :)

[TiZ-HugLife]

I had some interest in xpra in the past as I was interested in potentially adding scaling filters to 2D games that don't have any but would benefit from them, like Freedom Planet and Momodora. It was brought up on /r/linux as a way to scale applications on HiDPI.

But someone mentioned there that input lag is present--or rather, discrepancy between an input is received and when its result is displayed--and that immediately disqualified it for me as a possibility for anything. Any amount of input lag will cause issues for many gamers and for some will make it entirely unacceptable. Before forging ahead on this, can someone check the input lag situation somehow? I don't know of a precise way to test it and I'm presuming you're all fairly casual gamers. Just play a game--any game--and see if you can feel anything weird. I am competitive in fighting games; if you guys think it feels fine, I'll check it too and see if I think it feels fine.

[CubeTheThird]

Just throwing my 2 cents here. I recently discovered a project on github called run_scaled, which as the name suggests allows easily running an application with a scaling factor, this being through xpra. Although I haven't done extensive testing, I was using it to run a very old game, which originally maxes out at something like 360p. Despite the negligible system requirements for the game, running it at a 2x scale factor appeared to introduce noticeable input latency. This was however through integrated Intel graphics; I hadn't bothered trying to run this through my Nvidia card.

[TiZ-HugLife]

Any input latency at all, IMO, disqualifies xpra from being usable for this purpose. But if it's easily noticeable that's all the worse.

[l4l]

@Thulinma tried your fix with xpra with simple example written in vulkano and it works fine (showed 2 different PhysicalDevice-s).

Also I've attempted to run vkquake with no luck. It failed at this line, as you may guess because it cannot find discrete card (only integrated one). I hope that information could help you

[IngeniousDox]

I asked on DXVK discord server a few weeks ago it would be possible to just use the dGPU in Vulkan directly, and since Vulkan supports multigpu, it should be possible to render on the dGPU and then output on iGPU. Now, don't ask me the details of how and why, since I know nothing about Vulkan. But I think this direction could be better then copying images after the fact.

Here is the convo:

Dox | GTX970 | 396.51.02 07/26/2018
Can you intercept the vulkan calls from another application, insert your own vulkan layer that lets you call the vulkan calls to your dGPU in your laptop, while outputing to the iGPU of your laptop?
Using MultiGPU etc

Plagman 07/26/2018
yeah, that's what something like primus used to do with opengl
you'd have the app talk to the dgpu vulkan device, and when they call vkQueuePresent, copy their image to the other device and present it there
but this stuff is really best handled by the window system? does PRIME not work at the moment?

Dox | GTX970 | 396.51.02 07/26/2018
yeah, but we are talking about it in the context of bumblebee.
Do you think it would be possible to have something like optirun / primusrun, but then vulkanrun that would take the vulkan calls and make it on the dGPU while outputing on iGPU?
Ofc, it would be much better if Nvidia finally gets offload capability aswell.

Plagman 07/26/2018
ah, I see, NVIDIA
yeah it's doable with vulkan, i'd rather they would fix it at the driver level though

So yeah, it would be better if nvidia finally get offload capability, but for Vulkan it might already be possible to do something similar.

[IngeniousDox]

Oh, and good news: I also asked on nvidia linux dev forum, and Aaron Plattner responded that they are working on it, I have asked for a rough estimate on when it would be available (Doubt he can answer, but hopefully something vague):

https://devtalk.nvidia.com/default/topic/957981/linux/prime-render-offloading-on-nvidia-optimus/post/5276433/#5276433

[hamed-abdy]

After updating my system xpra solution does not work anymore.
Terminal output is as the same as when it was working but xpra log file (:8.log) has been changed as follows:
error running (['xprop', '-display', ':8', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such file or directory
[31m2018-08-24 13:03:06,706 Error: failed to connect to display :8 [0m
[31m2018-08-24 13:03:06,706 could not connect to X server on display ':8' after 3 seconds [0m

[sysrq-reisub]

Hey, Proton was just released by Valve and it can run windows games in steam through DXVK which relies on Vulkan, since it is not a good solution to game on an integrated gpu, I hope more devs are going to make it a real thing.

[snj33v]

doitsujin/dxvk@34152a0

[felixdoerre]

I have implemented a draft version of something like Primus for Vulkan: https://github.com/felixdoerre/primus_vk
However it has still a few technical limitation that should be resolved as best as possible. What do you think of it?

[cyberconan]

Hi felixdoerre! I'm trying to test your code in ArchLinux. I did these changes in these files:

• nv_vulkan_wrapper.cpp: I changed nvDiver path to "/usr/lib/libGLX_nvidia.so.0"
• primus_vk.cpp: I added: #include "vk_layer_utils.h" (if not, I can't compile)
• primus_vk.json: I changed "library_path" to my compiled libprimus_vk.so.
• nvidia_icd.json: I changed "library_path" to my compiled libnv_vulkan_wrapper.so

Well, next I'm tryed to test with dolphin emulator launching with this:
ENABLE_PRIMUS_LAYER=1 optirun dolphin-emu

[sáb sep 22 17:51:01 2018] bbswitch: enabling discrete graphics
[sáb sep 22 17:51:01 2018] nvidia-nvlink: Nvlink Core is being initialized, major device number 238
[sáb sep 22 17:51:01 2018] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  396.54  Tue Aug 14 19:02:34 PDT 2018 (using threaded interrupts)
[sáb sep 22 17:51:01 2018] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  396.54  Tue Aug 14 23:08:44 PDT 2018

Now I can change in graphic configuration OpenGL to Vulkan and shows in configuration my GeForce 840M, wow! But when I'm going to test a game dolphin crash with core dump. In dmesg I see this errors:

[sáb sep 22 17:51:05 2018] Emuthread - Sta[31551]: segfault at 10 ip 00007f56522c414d sp 00007f566abe9100 error 4 in libGLX_nvidia.so.396.54[7f5652205000+c9000]
[sáb sep 22 17:51:05 2018] Code: 00 00 49 89 bc 24 a0 00 00 00 c6 07 2a 44 89 ea 66 c7 47 02 03 00 49 83 84 24 b0 00 00 00 0c 44 89 f6 49 ff 84 24 98 00 00 00 <48> 8b 43 10 48 8d 5c 24 10 8b 40 04 c6 47 01 2a 88 07 e8 4c 2b 00 
[sáb sep 22 17:51:05 2018] audit: type=1701 audit(1537631467.051:118): auid=1000 uid=1000 gid=1000 ses=1 pid=31519 comm=456D75746872656164202D20537461 exe="/usr/bin/dolphin-emu" sig=11 res=1
[sáb sep 22 17:51:05 2018] audit: type=1130 audit(1537631467.064:119): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@17-31587-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[sáb sep 22 17:51:06 2018] nvidia-modeset: Unloading
[sáb sep 22 17:51:06 2018] nvidia-nvlink: Unregistered the Nvlink Core, major device number 238
[sáb sep 22 17:51:06 2018] bbswitch: disabling discrete graphics
[sáb sep 22 17:51:06 2018] pci 0000:03:00.0: Refused to change power state, currently in D0
[sáb sep 22 17:51:07 2018] audit: type=1131 audit(1537631468.421:120): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@17-31587-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Any advice or is too soon to try launch a game with your Vulkan layer? Thanks!!!

[cyberconan]

Good news! @felixdoerre code really works!! Now we can use Vulkan in our laptops with Bumblebee/Primus. 🥇

[NerosTie]

It doesn't work with The Talos Principle. When I switch to the Vulkan API, I have Fatal error: cannot display mode. I don't have this issue if I use the Intel GPU.

(but yes, it does work with Dolphin-emu!)

Edit: Well, the Nvidia driver has been updated (410.57) and now it works with The Talos Principle! 🎉

[Nautigsam]

I tried the xpra solution with a recent game (Frostpunk). It works but the performances are very poor. I can not even see my mouse cursor.

[PierfrancescoArdino]

@Nautigsam have you tried primus_vk? It is a Primus like implementation but for Vulkan. It actually works well using in combination with proton

[Nautigsam]

@PierfrancescoArdino Nope, the game won't launch. I get the same kind of error: wine: Unhandled page fault on read access to 0x00000000 at address 0x7f6b8c37c715 (thread 0029).
I tried to test with vkcube. It works but the framerate is very inconsistent.

[Thulinma]

@felixdoerre Your primus_vk solution looks more promising than the xpra solution, nicely done! It might be worth shipping this with Bumblebee and trying to streamline the setup somewhat to be more user friendly.

@Lekensteyn Do you have any thoughts on (or time for) this? I'd be happy to work on it, but as my sporadic replies to this issue have indicated, my time is quite limited these days 🙁. So somebody else might get it done faster than me. But if nobody else picks this up, I will take a look at it as soon as I have a free moment.

[ArchangeGabriel]

@felixdoerre Thanks for your work! This seems to be working OOTB, which is nice. I hope to get some available free time soon, and maybe then we could release Bumblebee 4.0 and advertise this nice addition. Is there any downside in setting the env var all the time, including for OpenGL apps? If not then maybe pvkrun could become the default loader (Bumblebee 4.0 was to replace virtualgl by primus as the default bridge, but maybe we can go further). Though optirun -b primus and primusrun aren’t exactly the same thing, so would need to check some stuff.

[felixdoerre]

@ArchangeGabriel Thank you very much for pushing this forward. aI don't see any downside in always setting the env-var to enable the primus-vk layer. For pure OpenGL apps this shouldn't change anything, as the variable is evaluated by the vulkan loader which such a purge OpenGL application should not load.

[ArchangeGabriel]

Great, so we could default to “pvkrun” instead. Still need to see how/if replacing the underlying logic of optirun with primusrun/pvkrun is doable.