[Feature Request] Vulkan support in Bumblebee/Primus

edoantonioco commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

AnAkkk commented 8 years ago

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 commented 8 years ago

I think so.

snj33v commented 8 years ago

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

edoantonioco commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

snj33v commented 7 years ago

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

monotykamary commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

monotykamary commented 7 years ago

@Lekensteyn That is not libglvnd support. __GLVND_DISALLOW_PATCHING=1 prevents GLdispatch in libglvnd from dispatching OpenGL functions that would otherwise point it away from library files that primus already defines (I am assuming the one that requires displaying libGL, PRIMUS_libGLd=${PRIMUS_libGLd:-'/usr/$LIB/libGL.so.1'}) when installed with libglvnd enabled mesa.

snj33v commented 7 years ago

@monotykamary can wayland(EGL) help in this scenario ?

monotykamary commented 7 years ago

@snj33v Hopefully in the near future. We still need to have Intel's open source driver to work together with the NVIDIA binary driver on Wayland for GPU-switching to work as designed, but it should be easier in concept since we can just leave it to the client to simply dump buffers with pixels on the screen.

kamirr commented 6 years ago

So… is there any progress towards making Vulkan working with Bumblebee being made? There already are many games using Vulkan and RPCS3 relies on it heavily. I apparently have no choice but to reboot into Windows to do stuff that should be possible on Linux.

edoantonioco commented 6 years ago

@KoczurekK This doesn't seems to happen anytime soon. For now the only option is to use nvidia-xrun. it's not as convenient as this one, but it provides vulkan support, and better performance than bumblebee. SolusOS is also working on an alternative to this, if you want to take a look at it, but its on an early state. Hopefully wayland will help to improve this whole scenario in the future.

DragonSWDev commented 6 years ago

In X.Org 1.20 there will be server side GLVND. With this hopefully we can get something like Bumblebee, but without additional software (out of the box). Vulkan should be supported too.

But for now the only option is nvidia-xrun. Of course, it's not convenient like Bumblebee or PRIME, but at least Vulkan works.

PierfrancescoArdino commented 6 years ago

The first RC for X.Org 1.20 has been released. Any chance to get something like Bumblebee out of the box? How it should work?

snj33v commented 6 years ago

what do they mean by "VK_PHYSICAL_DEVICE_TYPE_VIRTUAL_GPU" ?

alex9099 commented 6 years ago

Optimus laptops not supporting vulkan on nvidia is an hardware or software issue?

TiZ-HugLife commented 6 years ago

It's a software issue. If you use something like nvidia-xrun or nvidia-prime, you can use Vulkan. You might need to set VK_ICD_FILENAMES to only load the nvidia ICD, but Vulkan works just fine.

Talkless commented 6 years ago

@TiZ-EX1 Any hints how to make it work on Debian, as it does not have nvidia-prime (nor I can find nvidia-xrun via apt-file search) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875959 ?

TiZ-HugLife commented 6 years ago

@Talkless nvidia-xrun isn't in the repos: https://github.com/Witko/nvidia-xrun

JeffLabonte commented 6 years ago

@TiZ-EX1 You made it work on Debian? Never been able to with Fedora!

TiZ-HugLife commented 6 years ago

I kind of did, kind of didn't. Ultimately, I ended up making my own script similar to it and the openvt pull request that was left to languish forever. I have it entangled in a whole bunch of other scripts so I can't put it out there just yet.

ruabmbua commented 6 years ago

I managed to get Rise of the Tomb Raider, a VK based game to run under Arch Linux on my Optimus laptop. I used nvidia-xrun, and had to specify VK_ICD_FILENAMES, because the game would crash otherwise.

I have the feeling, that the game runs a lot smoother compared to its 2015 Windows release. I am so glad, that I can finally say something like this about Linux.

edoantonioco commented 6 years ago

Now that Xorg 1.20 is out (with GLVND), maybe this will allow bumblebee (or any other project) to offer a good alternative for this.

Fincer commented 6 years ago

I am bit worried about missing implementation of proper Vulkan support. Bumblebee is inactive (developers gone, don't care, etc.), and as far as I know, no other similar projects exist. I have been a bumblebee user since 2011.

I could live with several major bugs that exist in the current bumblebee because they don't still make it unusable on many Linux systems. However, lack of Vulkan support will do it in the near future - it means a total dead-end to this project. And it hits many Linux laptop users around the world. Main reasons for this trend are:

Vulkan is taking over OpenGL: It has been around for a few years, getting major improvements and encouraging all developers to use it over OpenGL
Apple is dropping OpenGL support on MacOS, encouraging developers to use other than OpenGL in their multi-platform game projects. This will likely hit Linux (indie) games as well.
DXVK (D3D11-to-Vulkan layer for Wine) is in active development, getting major Vulkan-only improvements for Windows D3D11 games and making official D3D11-to-OpenGL solution less and less important over time
Wine is getting support for D3D12 using Vulkan, not OpenGL
Nvidia (company) has not shown any real interest to implement proper Optimus support on Linux (including battery saving features) for years. It should be clear to anyone that developing a proper implementation is a very, very low priority to them because the real business, many customers & true market is elsewhere. No financial profit -> not a real-life priority.
Vulkan-only titles appearing: Several major Linux games use Vulkan graphics only, including Rise of The Tomb Raider, F1, Thrones of Britannia and so on (most of these are Feral Interactive titles). These games can't be run using bumblebee solution on a Linux laptop, and Intel graphics is really not an option.

In long term, lack of Vulkan support means not only end to the current bumblebee project but hits majority of Linux laptop gamers globally. One can speculate about how this affects general interest for gaming on Linux if majority of Linux laptop users can't really play their games (remember key words here: brand & marketing Linux as a gaming platform).

Personally, I have already tried nvidia-xrun solution as an alternative for bumblebee, but I just end up to get a frozen/tearing KDE5 desktop on discrete Nvidia graphics (yes yes, latest Qt/KDE/Nvidia/Mesa etc. packages have been installed on my Arch Linux), rendering nvidia-xrun solution completely unusable.

ArchangeGabriel commented 6 years ago

One of the points of Vulkan was being able to handle multiple graphics card if I remember correctly. Does that works on any system? If not, then we need someone with the required knowledge to enhance primus with Vulkan support. They are not a lot of people that have this ability and time to put into this.

Fincer commented 6 years ago

For many years, I was happy with the bumblebee project and it has greatly served it purpose. I and many others would have not been able to play many awesome game titles without it. Thanks for giving the chance! This has been a very important project for many of us. :+1:

However, times are changing: I became concerned once I found out that there is a serious underlying issue with the Vulkan API + Linux hybrid-graphics laptops which not much people seem to talk about...

At the time the bumblebee project was originally founded, Linux gaming relied heavily on OpenGL. Since the release of Vulkan API, OpenGL has become less and less important for new native Linux game titles and Windows games running under DXVK or Wine or using solutions alike.

We are not there yet but...

Vulkan API was released quite lately (in 2016), but many game and graphics developers are already seeing benefits of it over OpenGL, some of them dropping OpenGL support as a whole. Future scenario is quite clear: Vulkan will take over OpenGL. We already see it happening.

For the current form of the bumblebee project, this means that it will become completely obsolete, no doubt in that. It is partially obsolete even now, since some game titles rely on Vulkan-only support. Although nvidia-xrun offers a solution to some people, it does't work for all Linux laptop users.

Misunderstanding in the air: Bumblebee should make it very clear that it does not support Vulkan API (OpenGL only)

As far as I understand, there is still some misunderstanding in the air: many people seeking answer whether their Optimus hybrid-graphics laptops can run games on Linux find likely the bumblebee project in their first search results. Although these results can be many years old, it doesn't really matter....we all know old search results are misleading sometimes. And in the case of the bumblebee, not a single optirun or primusrun solution you can ever find with a search engine or in any wiki page apply on running Vulkan stuff.

There is a trap here: many average Linux users may not think that much about underlying OpenGL/Vulkan issues. The bumblebee project is simply a "solution" for them utilizing Nvidia Optimus hybrid-graphics on Linux. Once they realize Vulkan API was actually never supported by this project, they may get disappointed ("Oh, I thought my $1500 Linux laptop could run this game fine but afterwards I found out it does not, what a disappointment and waste of money!").

Although some of these people find alternative solutions viable, there is one thing the bumblebee project can officially do: make it clear that people should not look try any bumblebee-related solutions in attempt to run games or applications which rely on Vulkan API. People do not really need to waste their time in the world of search engines just to find that information or waste their money on a brand-new Optimus laptop just to find out that Vulkan games can't be played using the bumblebee solution.

My suggestion: update the README of this project (if you can). Make it very clear, that this project does not support Vulkan API (at the moment at least). Remember that this issue affects many, many Linux laptop users around the world so by making it clear serves a greater purpose and audience, after all. No more rumors or misleading information, just a simple and explicit statement.

Of course, updating information here is not enough since many many other sites are affected as well. But, it's good start at least.

@ArchangeGabriel

One of the points of Vulkan was being able to handle multiple graphics card if I remember correctly. Does that works on any system? If not, then we need someone with the required knowledge to enhance primus with Vulkan support.

Thanks for pointing this out! That was actually Vulkan API 1.1, released a few months ago. Some more and less informative links that may give the answer:

About devices & drivers, Vulkan API specification states:

Vulkan allows multiple Installable Client Drivers (ICDs) each supporting one or more devices (represented by a Vulkan VkPhysicalDevice object) to be used collectively. The loader is responsible for discovering available Vulkan ICDs on the system. Given a list of available ICDs, the loader can enumerate all the physical devices available for an application and return this information to the application.

@ArchangeGabriel

They are not a lot of people that have this ability and time to put into this.

Yeah, unfortunately. I have found that out, too. I hope someone, capable of doing it, will make it happen. There are some talented people around but, as you said, no time to put into this issue. But this issue has great potential to escalate very seriously in the near future.

Are other projects viable to solve the Vulkan/hybrid-graphics issue on Linux?

Depending on Vulkan API/Xorg/Wayland/GPU Drivers development progress, I am not even sure if the bumblebee project will be the true solution for this hybrid graphics dilemma. I don't know whether any of these other projects are actually working on the Windows-like (application-specific) solution for hybrid graphics on Linux. That would be great but I haven't seen anything related to this so far...if someone can point me in the right direction, that would be awesome! :+1:

Anyway, to support Linux as a operational gaming platform on laptops in the future, Vulkan API + hybrid graphics should be taken into consideration. It can be this project, or any other, but there is demand for this. OpenGL is past, everyone is looking ahead to Vulkan gaming experience.

ArchangeGabriel commented 6 years ago

The current status is:

Bumblebee is not a good solution for most use cases. It does not deliver performances in most situations, and will never do. And it does not support Vulkan currently, and it’s not clear what would be required to achieve this support.
PRIME (a.k.a. Optimus à la Windows) is in very good shape (works OOTB), but relies on using nouveau, which:
1. Does not deliver performances either because of missing reclocking support.
2. Has no Vulkan ICD that I’m aware of.
Reverse PRIME (running everything on the NVIDIA chip) offers good performances, but still has some issues AFAIK (like tearing). And it requires you to restart your session to switch between Integrated and Dedicated. But there is Vulkan at least.
nvidia-xrun is supposed to be somewhere in between Bumblebee and Reverse PRIME, by starting a dedicated session for the NVIDA card, but in addition to your current one. So likely a bit less performances, but you can keep your current session. And Vulkan should work.

Finally, a last possible solution, but one that I never had the time to investigate, would be using virtualisation and GPU-passthrough (vfio/vfio-vga). There are likely downsides, and likely not optimal performances, but several advantages including keeping your session and being able to run a Windows that way.

Fincer commented 6 years ago

@ArchangeGabriel

Thank you for summarising available options for Optimus users. Very handy list!

After all, I found a way to use nvidia-xrun on my laptop. I had little hassle with my KDE 5 + nvidia-xrun setup so I ended up installing Openbox desktop just for Nvidia GPU. Works very well that way. I still keep watching any changes/progress here, however. Well, no more off-topic talking.

gsgatlin commented 6 years ago

If people would like to see Vulkan support in at least one of the bridges (VirtualGL) you may wish to ask about it on their mailing list:

https://groups.google.com/forum/#!forum/virtualgl-users

Talkless commented 6 years ago

After all, I found a way to use nvidia-xrun on my laptop. I had little hassle with my KDE 5 + nvidia-xrun setup so I ended up installing Openbox desktop just for Nvidia GPU.

While I was on Ubuntu I've been using prime-select, so scenario was like this:

sudo prime-select nvidia
logout
login

And no extra desktops needed.

Sadly, we don't have that utility on Debian [0], and naively extracting Ubuntu package didn't work.

It would be even easier if we could just select graphics backend in login manager :) .

[0] https://bugs.debian.org/875959

Thulinma commented 6 years ago

I'm willing to do some research and make attempts to get Vulkan to work in/with/through Bumblebee. Judging from how nvidia-xrun works internally, it should be possible to have at least some form of solution for Vulkan applications working in Bumblebee. It uses many of the same techniques we do, after all. However, even the first step of finding a Linux application that could be used to test Vulkan with has given me some trouble already. Does anyone know of a (free/small/simple) application that uses Vulkan and could be used to test support?

skoehler commented 6 years ago

Am 15.06.2018 um 16:06 schrieb Bruno Pagani:

nvidia-xrun is supposed to be somewhere in between Bumblebee and Reverse PRIME, by starting a dedicated session for the NVIDA card, but in addition to your current one. So likely a bit less performances, but you can keep your current session. And Vulkan should work.

Is this performance claim backed up by anything? To the best of my knowledge, nvidia-xrun is the cleanest approach. It starts a new X server, where the intel card is basically just used for forwarding the picture to the display connectors. The complete screen image is rendered by the nvidia card. This is well supported by the X server and is well understood. Any hacks, workarounds, or complications raised by having only part of the screen rendered by nvidia (which bumblebee has to support) is avoided.

The nvidia-xrun author claims improved performance compared to bumblebee. And then there also is the fact that it support Vulkan.

I have not managed to make nvidia-xrun work on my system. I have given up for the moment. So I have not done any benchmarks.

PierfrancescoArdino commented 6 years ago

@Thulinma have you tried vkcube or vkmark ?

Fincer commented 6 years ago

@Thulinma

However, even the first step of finding a Linux application that could be used to test Vulkan with has given me some trouble already. Does anyone know of a (free/small/simple) application that uses Vulkan and could be used to test support?

Well, there may be some as @PierfrancescoArdino already suggested:

Demo	Description
vkcube	Simple cube rendering demo. If you use Arch/Manjaro or variant, check AUR package vkcube-git.
vkmark	A Vulkan benchmark test suite. Available on AUR, too. It has the same cube testing scenario than vkcube.
Other demos

Screenshots

#### vkcube ![vkcube-runtime](https://i.imgur.com/1riA8PG.png) #### vkmark ![vkmark-runtime](https://i.imgur.com/VSKjtvQ.png)

@skoehler

I have not managed to make nvidia-xrun work on my system. I have given up for the moment. So I have not done any benchmarks.

Somewhat long reply

Not sure which is your desktop environment or what's your issue, but I couldn't get it work with KDE5 either (tearing, frozen icons & panels, black boxes etc.). I didn't find any relevant issues on Witko/nvidia-xrun GitHub issue tracker and I couldn't find any relevant log entries on my computer either. Thus I gave [Openbox](https://en.wikipedia.org/wiki/Openbox) a try, using it only on TTY2 with `nvidia- xrun` (command is: `nvidia-xrun openbox-session`). I prefer Openbox because it is very lightweight, small size and does not hog extra resources (unlike running another KDE5/Plasma session). The only issue I have is that switching between TTY1 (Intel) & TTY2 (Nvidia) causes graphical-intense applications on TTY2 not to be rendered (they appear as black). This behavior occurs only when switching between TTY sessions. Very nasty issue, but I can't do much about it.

@Talkless

It would be even easier if we could just select graphics backend in login manager :) .

Yeah, this is traditional, but bit cumbersome approach. I found it bit inconvenient and pretty much agree with Luca Boccassi.

ArchangeGabriel commented 6 years ago

Is this performance claim backed up by anything? To the best of my knowledge, nvidia-xrun is the cleanest approach. It starts a new X server, where the intel card is basically just used for forwarding the picture to the display connectors. The complete screen image is rendered by the nvidia card. This is well supported by the X server and is well understood. Any hacks, workarounds, or complications raised by having only part of the screen rendered by nvidia (which bumblebee has to support) is avoided.

Yes of course: you are still running two X servers at a time, so there is a (small, DE/WM-depending) cost. But yes, it is likely the cleanest implementation of Optimus outside PRIME, by using Reverse PRIME in an Bumblebee-like setup. And it has indeed performances and Vulkan on its side.

Bumblebee-Project / Bumblebee