Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 574886 - virtual/vulkan: add vulkan support
Summary: virtual/vulkan: add vulkan support
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal with 5 votes (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-16 14:37 UTC by Jonas Jelten
Modified: 2019-02-09 18:06 UTC (History)
18 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
vulkan loader git repo ebuild (vulkan-base-9999.ebuild,2.66 KB, text/plain)
2016-03-08 19:36 UTC, Manuel Lauss
Details
media-libs/vulkan-icd-loader-1.0.5.0.ebuild (vulkan-icd-loader-1.0.5.0.ebuild,1.23 KB, text/plain)
2016-03-23 15:56 UTC, Timo Rothenpieler
Details
media-libs/vulkan-icd-loader-1.0.11.0.ebuild (vulkan-icd-loader-1.0.11.0.ebuild,1.23 KB, text/plain)
2016-05-19 01:37 UTC, Mike Lothian
Details
media-libs/vulkan-base-9999 Updated ebuild (vulkan-base-9999.ebuild,2.83 KB, text/plain)
2016-05-19 01:38 UTC, Mike Lothian
Details
vulkan-base-9999 update v2 (vulkan-base-9999.ebuild,2.69 KB, text/plain)
2016-05-19 06:07 UTC, Manuel Lauss
Details
vulkan-base-9999 v3 (vulkan-base-9999.ebuild,3.26 KB, text/plain)
2016-06-14 17:45 UTC, Manuel Lauss
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Jelten 2016-02-16 14:37:44 UTC
Vulkan has been released: https://www.khronos.org/vulkan/

This should probably function as a meta-bug to properly integrate Vulkan into gentoo.

We should add the http://vulkan.lunarg.com/ tools, provide the vulkan use flag, figure out if a "backend switch" like libGL requires is needed, and more to come.
Comment 1 Mart Raudsepp gentoo-dev 2016-02-20 19:14:43 UTC
The x11 team will happily steward this work, as it is closely related to mesa and co (at least for intel). I'm sure outside current project member help is surely very welcome and dependent on that we can see where to go from there - some sort of subproject of desktop or x11 or just all under x11. Though the project name is starting to show age and sound wrong at modern times with wayland and co as well :D
Keeping under maintainer-wanted@ assignee imho until any actual work is progressing and entering trees, to hopefully attract more interested parties meanwhile.

Regarding "backend switch", this should be a bit easier with the ICD stuff Vulkan has, I believe, but I haven't investigated all the technical details for Gentoo context yet.

I don't know about a virtual/vulkan need as of yet, or more exactly how an "any API implementation required" would be expressed (such a virtual is probably the most likely scenario though).
Comment 2 Manuel Lauss 2016-03-08 19:36:10 UTC
Created attachment 427764 [details]
vulkan loader git repo ebuild

live ebuild for Khronos/LunarG Vulkan loader, validation layer and example sources.
Comment 3 Manuel Lauss 2016-03-08 19:37:20 UTC
I've attached a cobbled-up ebuild which fetches the Khronos/LunarG Vulkan loader and installs it into the recommended directories.  Works for me(tm), have fun.
Comment 4 Luke A. Guest 2016-03-19 13:29:55 UTC
AMD has released an archive full of Ubuntu deb's last night, they are here http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Beta-Driver-for-Vulkan-Release-Notes.aspx
Comment 5 Timo Rothenpieler 2016-03-23 15:54:19 UTC
A virtual for Vulkan might not be required, instead the Vulkan-ICD-Loader from https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers could be packaged, providing libvulkan.so.1 and the Vulkan headers.

Drivers then install their Vulkan ICD files to /etc/vulkan/icd.d, and the ICD loader in libvulkan.so reads that file and loads the appropriate backend driver.

I'm not sure how that loader handles multiple available drivers and multilib environments, but if that needs special handling an eselect module should be possible.
Comment 6 Timo Rothenpieler 2016-03-23 15:56:35 UTC
Created attachment 428838 [details]
media-libs/vulkan-icd-loader-1.0.5.0.ebuild

More concise ebuild that only installs the loader and headers.
Comment 7 xpue 2016-03-23 17:50:22 UTC
Theoretically multiple gpus from different vendors should work together on same system through icd.
Comment 8 Timo Rothenpieler 2016-03-23 18:27:38 UTC
I'm more worried about the icd file the driver installs.
The NVidia one just points to libGLX_nvidia.so.0 without a path, which means it will only work as long as nvidia is eselected for opengl, as it won't be in ld.so.conf otherwise.
Comment 9 Manuel Lauss 2016-03-23 18:45:00 UTC
(In reply to Timo Rothenpieler from comment #8)
> I'm more worried about the icd file the driver installs.
> The NVidia one just points to libGLX_nvidia.so.0 without a path, which means
> it will only work as long as nvidia is eselected for opengl, as it won't be
> in ld.so.conf otherwise.

glvnd might help here. the newest nvidia driver package already suffixes their
libraries with _nvidia  (e.g. lib{GLX,EGL}_nvidia.so), so these are safe
to put into /usr/lib.  Mesa needs to catch up with this and then the whole
eselect-opengl thing can disappear at all.
Comment 10 Luke A. Guest 2016-03-23 19:59:55 UTC
(In reply to Timo Rothenpieler from comment #5)
> A virtual for Vulkan might not be required, instead the Vulkan-ICD-Loader
> from https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers could
> be packaged, providing libvulkan.so.1 and the Vulkan headers.
> 
> Drivers then install their Vulkan ICD files to /etc/vulkan/icd.d, and the
> ICD loader in libvulkan.so reads that file and loads the appropriate backend
> driver.
> 
> I'm not sure how that loader handles multiple available drivers and multilib
> environments, but if that needs special handling an eselect module should be
> possible.

The whole point of Vulkan is that it handles multiple multi-vendor gpu's well. Each vendor installs it's icd file in the above dir, the application will enumerate all available cards and use any or all of them. Having to select between them is not the way.
Comment 11 Luke A. Guest 2016-03-23 20:04:40 UTC
I would recommend a new ebuild x11-drivers/xf86-video-amdgpu-pro which then pulls in the GL/CL binary libs and enforces the dependencies and blocks ati-drivers, which should then be deprecated.
Comment 12 Mike Lothian 2016-05-19 01:37:07 UTC
Created attachment 434654 [details]
media-libs/vulkan-icd-loader-1.0.11.0.ebuild

Updated ebuild
Comment 13 Mike Lothian 2016-05-19 01:38:27 UTC
Created attachment 434656 [details]
media-libs/vulkan-base-9999 Updated ebuild

This version compiles for me, I'm still having issues with Vulkan however
Comment 14 Manuel Lauss 2016-05-19 06:07:46 UTC
Created attachment 434660 [details]
vulkan-base-9999 update v2

This is the ebuild I currently use, and it does work fine with the nvidia blob:

$ vulkaninfo
===========
VULKAN INFO
===========

Vulkan API Version: 1.0.13

INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_threading.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_object_tracker.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_swapchain.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_parameter_validation.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_image.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_device_limits.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_unique_objects.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_core_validation.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /home/mano/.local/share/vulkan/implicit_layer.d/steamoverlay_i386.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /home/mano/.local/share/vulkan/implicit_layer.d/steamoverlay_x86_64.json, version "1.0.0"
INFO: [loader] Code 0 : Found manifest file /etc/vulkan/icd.d/nvidia_icd.json, version "1.0.0"
Instance Extensions and layers:
===============================
Instance Extensions     count = 4
        VK_KHR_surface                  : extension revision 25
        VK_KHR_xcb_surface              : extension revision  6
        VK_KHR_xlib_surface             : extension revision  6
        VK_EXT_debug_report             : extension revision  2

[...]
Comment 15 Luke A. Guest 2016-05-24 17:44:37 UTC
I wanted to add that I have managed to crowbar the latest beta drivers into a workable state. I've also tried the above vulkan-base v2.

My overlay is https://github.com/Lucretia/vulkan-overlay
Comment 16 Chí-Thanh Christopher Nguyễn gentoo-dev 2016-05-24 17:55:41 UTC
If you want, we can give you access to the x11 project overlay. Then you could maintain your ebuilds there, and we could proxy commit what is suitable for the main tree.

join #gentoo-desktop on irc.freenode.net if you are interested.
Comment 17 Timo Rothenpieler 2016-05-24 17:59:38 UTC
I'd prefer if the ebuilds could stay split.
Not everything needs the full set of Vulkan-Tools in that ebuild. So one just for the ICD loader and one for the rest, or one with useflags that default to off for stuff like the demos or development tools.
Comment 18 Luke A. Guest 2016-05-24 18:21:26 UTC
I'd rather do testing i this overlay for now, although I'm happy to donate what I've done.

As for vulkan-base, there does need to be 3 ebuilds. There needs to be a way to install for someone who is building only and doesn't intend to use the tools and for those of us that need the tools to build other things.
Comment 19 Manuel Lauss 2016-06-14 17:45:24 UTC
Created attachment 437546 [details]
vulkan-base-9999 v3

I've updated the vulkan-base ebuild a bit to account for changes in the upstream build system and have added USE flags: "headers" to install C header files, "layers" to build and install the Vulkan validation layers, and "tools" to build and install the vulkaninfo tool.  Unsetting "tools" results in a faster build because glslang and spirv-tools aren't required.
Setting no use flag will simply build and install the libvulkan.so library and create the vulkan/icd.d directories.
Comment 20 Jan-Matthias Braun 2016-07-21 16:12:25 UTC
Hi!

Using the nvidia proprietary driver (in version 367.35, using kms and glvnd) and either the vulkan-base ebuild from this bugreport, or the one from the fireburn overlay mentioned in bug #580148, the vulkaninfo tool is not listing any surface formats:

Presentable Surface formats:
============================
None found

Demos like vulkancube fail with 
    demo_init_vk: Assertion `!err && gpu_count > 0' failed.

Other programs claim that they cannot set the display mode, or similar.

Do you have any ideas what might be wrong on my two systems? One is equipped with a GT 630 (GF108), which is supposed to be supported, and the other with a NVS 5400M (GF108M), for which I am actually unsure, although I would assume it to be supported.

Thanks,

Jan
Comment 21 kisak42 2016-07-21 19:36:53 UTC
(In reply to Jan-Matthias Braun from comment #20)
> Hi!
> 
> Using the nvidia proprietary driver (in version 367.35, using kms and glvnd)
> and either the vulkan-base ebuild from this bugreport, or the one from the
> fireburn overlay mentioned in bug #580148, the vulkaninfo tool is not
> listing any surface formats:
> 
> Presentable Surface formats:
> ============================
> None found
> 
> Demos like vulkancube fail with 
>     demo_init_vk: Assertion `!err && gpu_count > 0' failed.
> 
> Other programs claim that they cannot set the display mode, or similar.
> 
> Do you have any ideas what might be wrong on my two systems? One is equipped
> with a GT 630 (GF108), which is supposed to be supported, and the other with
> a NVS 5400M (GF108M), for which I am actually unsure, although I would
> assume it to be supported.
> 
> Thanks,
> 
> Jan

The 'F' in GF108 indicates the chipset is from the Fermi generation. nVidia's proprietary driver does not support Vulkan on Fermi.
Comment 22 Jan-Matthias Braun 2016-07-22 11:07:57 UTC
(In reply to kisak42 from comment #21)
> (In reply to Jan-Matthias Braun from comment #20)
> > Hi!
> > 
> > Using the nvidia proprietary driver (in version 367.35, using kms and glvnd)
> > and either the vulkan-base ebuild from this bugreport, or the one from the
> > fireburn overlay mentioned in bug #580148, the vulkaninfo tool is not
> > listing any surface formats:
> > 
> > Presentable Surface formats:
> > ============================
> > None found
> > 
> > Demos like vulkancube fail with 
> >     demo_init_vk: Assertion `!err && gpu_count > 0' failed.
> > 
> > Other programs claim that they cannot set the display mode, or similar.
> > 
> > Do you have any ideas what might be wrong on my two systems? One is equipped
> > with a GT 630 (GF108), which is supposed to be supported, and the other with
> > a NVS 5400M (GF108M), for which I am actually unsure, although I would
> > assume it to be supported.
> > 
> > Thanks,
> > 
> > Jan
> 
> The 'F' in GF108 indicates the chipset is from the Fermi generation.
> nVidia's proprietary driver does not support Vulkan on Fermi.

Hah---that is a somewhat final diagnosis which saves me a lot of time. Thanks a lot.
Funny, because the double checked the Khronos list of supported devices [1], which explicitly lists a NVIDIA GeForce GT 630.

Alright, sorry for the noise!

Cheers,

Jan

[1] https://www.khronos.org/conformance/adopters/conformant-products
Comment 23 George Diamantopoulos 2016-07-27 18:55:41 UTC
Should this be updated with multilib support? I'm getting:

ERROR: ld.so: object '/home/gd/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

when running Dota2 with the "-vulkan" switch...
Comment 24 Luke A. Guest 2016-07-27 19:26:54 UTC
(In reply to George Diamantopoulos from comment #23)
> Should this be updated with multilib support? I'm getting:
> 
> ERROR: ld.so: object
> '/home/gd/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from
> LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
> 
> when running Dota2 with the "-vulkan" switch...

It already installs both 64 and 32 bit vulkan drivers:


ls -l /usr/lib32/vulkan/vendors/amdgpu-pro/amdvlk32.so 
-rwxr-xr-x 1 root root 10620056 Jul  6 19:47 /usr/lib32/vulkan/vendors/amdgpu-pro/amdvlk32.so

ls -l /etc/vulkan/icd.d/
total 8
-rw-r--r-- 1 root root 160 Jul  6 19:47 amd_icd32.json
-rw-r--r-- 1 root root 160 Jul  6 19:47 amd_icd64.json
Comment 25 George Diamantopoulos 2016-07-29 13:01:42 UTC
I think the files you're listing are provided by AMD's proprietary driver, and not this proposed package.

Here's what I have:

rincewind ~ # find /usr -iname 'libvulkan*'
/usr/lib64/libvulkan.so.1.0.21
/usr/lib64/libvulkan_intel.so
/usr/lib64/libvulkan.so
/usr/lib64/libvulkan.so.1
/usr/lib32/libvulkan_intel.so

If I update the v3 ebuild with the multilib-minimal eclass and functions, then I get:

rincewind ~ # find /usr -iname 'libvulkan*'
/usr/lib64/libvulkan.so.1.0.21
/usr/lib64/libvulkan_intel.so
/usr/lib64/libvulkan.so
/usr/lib64/libvulkan.so.1
/usr/lib32/libvulkan.so
/usr/lib32/libvulkan.so.1.0.21
/usr/lib32/libvulkan_intel.so
/usr/lib32/libvulkan.so.1

But I'm not sure if ldconfig is right, everything is listed as libc6 only:

rincewind ~ # ldconfig -p | grep -i vulk
        libvulkan_intel.so (libc6,x86-64) => /usr/lib64/libvulkan_intel.so
        libvulkan_intel.so (libc6) => /usr/lib32/libvulkan_intel.so
        libvulkan.so.1 (libc6) => /usr/lib64/libvulkan.so.1
        libvulkan.so.1 (libc6) => /usr/lib32/libvulkan.so.1
        libvulkan.so (libc6) => /usr/lib64/libvulkan.so
        libvulkan.so (libc6) => /usr/lib32/libvulkan.so

BTW, the dota2/steam error I reported in my previous post is unrelated.
Comment 26 George Diamantopoulos 2016-07-29 13:05:09 UTC
Update: with my ugly hacked ebuild (I have no idea what I'm doing) dota2 now fails with:

failed to dlopen "librendersystemvulkan.so" error=libvulkan.so.1: wrong ELF class: ELFCLASS32
Comment 27 Luke A. Guest 2016-07-30 00:58:40 UTC
(In reply to George Diamantopoulos from comment #25)
> I think the files you're listing are provided by AMD's proprietary driver,
> and not this proposed package.

Yes that's what my ebuild is for, amd's stuff.
Comment 28 Luke A. Guest 2016-08-27 15:54:54 UTC
(In reply to Timo Rothenpieler from comment #5)

> Drivers then install their Vulkan ICD files to /etc/vulkan/icd.d, and the
> ICD loader in libvulkan.so reads that file and loads the appropriate backend
> driver.
> 
> I'm not sure how that loader handles multiple available drivers and multilib
> environments, but if that needs special handling an eselect module should be
> possible.

Ok, there will be a problem where there are 2 vulkan drivers for the same hardware, i.e. AMDGPU-Pro and the radv driver, there will be a similar issues for open vs closed on nv cards too. There will need to be an eselect which sets between open vs closed.
Comment 29 Peter Asplund 2016-09-23 18:14:47 UTC
Any progress on this one so far? (sorry for asking)
Comment 30 C. Wijtmans 2016-09-23 20:49:02 UTC
I need the vulkan libs and headers for my development. The ebuild in overlays are messy not quality worth.
Comment 31 Luke A. Guest 2016-09-25 18:52:58 UTC
(In reply to Peter Asplund from comment #29)
> Any progress on this one so far? (sorry for asking)

I assume you're asking me?

I've just pushed the latest ebuild's to https://github.com/Lucretia/vulkan-overlay

It includes RADV which is why it's taken a while to do. I've had to downgrade some packages to get the binary libdrm from AMD to install.
Comment 32 Peter Asplund 2016-10-25 21:24:28 UTC
Great, I'll check out the overlay. Since the RADV is in main Mesa now (the 13_rc), hopefully that's good enough for starting to work with the SDK.

The 1.0.31 was released today as well.
Comment 33 C. Wijtmans 2016-11-02 19:25:02 UTC
Please note there is no need for virtual/vulkan, only dev-libs/vulkan for vulkan development.
Comment 34 Peter Asplund 2016-11-05 21:59:19 UTC
Hi again, I just wanted to give a heads up that I'm seeing this issue when using the Mesa RADV + amdgpu + vulkan-base (vulkaninfo/vulkancube):

https://lists.freedesktop.org/archives/mesa-dev/2016-October/130774.html

I don't understand what to do about it (even though I've read it a couple of times), so I just wanted to leave it here :)
Comment 35 Matt Turner gentoo-dev 2016-11-15 01:35:03 UTC
I've added media-libs/vulkan-loader to the tree.

It doesn't provide tools, demos, or the validation layers (the latter I really want to provide by default).

I don't know if a virtual is the right thing to do, since unlike OpenGL (with conflicting libGL.so) vulkan drivers are able to be installed side-by-side.
Comment 36 C. Wijtmans 2016-11-15 17:16:38 UTC
(In reply to Matt Turner from comment #35)
> I've added media-libs/vulkan-loader to the tree.
> 
> It doesn't provide tools, demos, or the validation layers (the latter I
> really want to provide by default).
> 
> I don't know if a virtual is the right thing to do, since unlike OpenGL
> (with conflicting libGL.so) vulkan drivers are able to be installed
> side-by-side.

yeah a virtual may not be necessary, however knowing reality it may be required to get the desktop to select the proper vulkan driver. I wish to have more vulkan packages for development in portage.
Comment 37 Manuel Lauss 2016-11-15 17:39:22 UTC
(In reply to C.J. Wijtmans from comment #36)
> (In reply to Matt Turner from comment #35)
> > I've added media-libs/vulkan-loader to the tree.
> > 
> > It doesn't provide tools, demos, or the validation layers (the latter I
> > really want to provide by default).
> > 
> > I don't know if a virtual is the right thing to do, since unlike OpenGL
> > (with conflicting libGL.so) vulkan drivers are able to be installed
> > side-by-side.
> 
> yeah a virtual may not be necessary, however knowing reality it may be
> required to get the desktop to select the proper vulkan driver. I wish to
> have more vulkan packages for development in portage.

I need to check again, but last I tried (with 1.0.30), I was able to have both
the intel and nvidia icd active and valid at the same time. vulkaninfo ran just fine, and so did talos principle.
Comment 38 Andrei Slavoiu 2016-11-15 18:35:19 UTC
(In reply to Matt Turner from comment #35)
> I've added media-libs/vulkan-loader to the tree.

What packages are supposed to depend on this? I expected mesa[vulkan] to RDEPEND on it but that is not the case.
Comment 39 Matt Turner gentoo-dev 2016-11-15 18:40:36 UTC
(In reply to Andrei Slavoiu from comment #38)
> (In reply to Matt Turner from comment #35)
> > I've added media-libs/vulkan-loader to the tree.
> 
> What packages are supposed to depend on this? I expected mesa[vulkan] to
> RDEPEND on it but that is not the case.

That's an open question. leio suggested that mesa[vulkan] (or the nvidia drivers, or any other vulkan driver) should RDEPEND on vulkan-loader.

That makes sense to me, but I'm still not sure what's the best way to ensure vulkan drivers are installed. E.g., what should vulkan applications RDEPEND on?

Ideas welcome.
Comment 40 Timo Rothenpieler 2016-11-15 18:42:31 UTC
Games and applications using Vulkan would depend on it.
The drivers have no need for the Vulkan loader.
Comment 41 Timo Rothenpieler 2016-11-15 18:48:31 UTC
> That's an open question. leio suggested that mesa[vulkan] (or the nvidia
> drivers, or any other vulkan driver) should RDEPEND on vulkan-loader.
> 
> That makes sense to me, but I'm still not sure what's the best way to ensure
> vulkan drivers are installed. E.g., what should vulkan applications RDEPEND
> on?
> 
> Ideas welcome.

Maybe a virtual would make sense for that purpose.
It would depend on the loader, and on any of the various vulkan drivers.


Also, unrelated: It would be nice if the ebuild in the tree would have a 9999 variant, specially as the ebuild itself is already prepared for that, and all it needs is a symlink.
Comment 42 Emily Mills 2016-11-15 19:23:23 UTC
My opinion: Vulkan applications should RDEPEND on media-libs/vulkan-loader. (They'll need this either way.) media-libs/vulkan-loader should RDEPEND on vulkan drivers based on VIDEO_CARDS.
Comment 43 Timo Rothenpieler 2016-11-15 19:25:27 UTC
(In reply to Adam Mills from comment #42)
> My opinion: Vulkan applications should RDEPEND on media-libs/vulkan-loader.
> (They'll need this either way.) media-libs/vulkan-loader should RDEPEND on
> vulkan drivers based on VIDEO_CARDS.

That seems like a bad idea, as it would make adding new Vulkan drivers harder, as they'd have to be added to the potentialy multiple versions of the loader ebuild.
Comment 44 Emily Mills 2016-11-15 20:08:23 UTC
(In reply to Timo Rothenpieler from comment #43)
> (In reply to Adam Mills from comment #42)
> > My opinion: Vulkan applications should RDEPEND on media-libs/vulkan-loader.
> > (They'll need this either way.) media-libs/vulkan-loader should RDEPEND on
> > vulkan drivers based on VIDEO_CARDS.
> 
> That seems like a bad idea, as it would make adding new Vulkan drivers
> harder, as they'd have to be added to the potentialy multiple versions of
> the loader ebuild.

It's a valid point. I think what it boils down to is which of the following two scenarios do we expect to be more common. I'm certainly not qualified to answer.

1) Support is added for new Vulkan drivers.
2) A new version of the vulkan-loader ebuild is released which requires a newer version of each Vulkan driver.
Comment 45 Jan Henke 2016-11-15 20:23:04 UTC
Sorry to interrupt, but the ebuild fails to build on my system. I have emerged mesa 13.0.1 with the Intel Vulkan driver, but I need the vulkan-loader to do anything useful. The build fails already when cmake tries to configure the source tree.

emerge --info '=media-libs/vulkan-loader-1.0.30.0::gentoo'
Portage 2.3.0 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop/gnome/systemd, gcc-4.9.3, glibc-2.22-r4, 4.6.6-gentoo-r1 x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.6.6-gentoo-r1-x86_64-Intel-R-_Core-TM-_i7-5500U_CPU_@_2.40GHz-with-gentoo-2.2
KiB Mem:     8141176 total,    946404 free
KiB Swap:   10485756 total,  10485756 free
Timestamp of repository gentoo: Tue, 15 Nov 2016 16:15:01 +0000
sh bash 4.3_p48
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:          4.3_p48::gentoo
dev-java/java-config:     2.2.0-r3::gentoo
dev-lang/perl:            5.22.2::gentoo
dev-lang/python:          2.7.10-r1::gentoo, 3.4.3-r1::gentoo
dev-util/cmake:           3.5.2-r1::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.21.7::gentoo
sys-apps/sandbox:         2.10-r1::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            4.9.3::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers)
sys-libs/glibc:           2.22-r4::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.de.gentoo.org/gentoo-portage
    priority: -1000

personal-overlay
    location: /usr/local/portage/personal-overlay
    sync-type: git
    sync-uri: https://github.com/janhenke/personal-overlay
    masters: gentoo
    priority: 250

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.3/conf"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://mirror.netcologne.de/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo"
LANG="de_DE.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa amd64 bash-completion berkdb bluetooth bzip2 cairo cdda cdr clang cli colord cracklib crypt cups cxx dane dbus dri dri3 dts dvd dvdr eds egl emboss encode evo exif fam firefox flac fortran fuse gdbm gif glamor gles gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk gtk3 gtkstyle iconv icu idn introspection ipv6 java jpeg kerberos lcms ldap libnotify libsecret lldb mad mmx mmxext mng modules mp3 mp4 mpeg multilib nautilus ncurses nfs nfsv41 nfsv42 nls nptl ogg opencl opengl openmp opus ovmf pam pango pcre pdf pie png policykit ppds pulseaudio python readline samba sdl sdl2 seccomp session source speex spell sse sse2 ssl startup-notification svg symlink syslog systemd tcpd theora threads tiff tracker truetype udev udisks unicode upower usb v4l vaapi vim-syntax vorbis vpx vulkan wayland webm webp wxwidgets x264 x265 xattr xcb xml xv xvid zeroconf zlib zsh-completion" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="libinput" KERNEL="linux" L10N="de de-DE en en-GB vi vi-VN" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de de_DE en en_GB vi vi_VN" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" QEMU_SOFTMMU_TARGETS="x86_64" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

emerge -pqv '=media-libs/vulkan-loader-1.0.30.0::gentoo'                                                                                             
[ebuild  N    ] media-libs/vulkan-loader-1.0.30.0  ABI_X86="(64) -32 (-x32)"

Full build log is at https://gist.github.com/janhenke/5a044ffef1a3722deb7289b156427b00
Comment 46 Timo Rothenpieler 2016-11-15 20:25:17 UTC
You should sync again, that was already fixed.
It's trying to build the layers while it shouldn't.
Comment 47 Jan Henke 2016-11-15 20:30:14 UTC
Thanks, that fixed the build indeed. It would be nice to have all parts of the upstream build eventually.
Comment 48 C. Wijtmans 2016-11-16 14:29:51 UTC
Well i gave it a shot but got stuck at the vulkan-headers ebuild. I dont know enough about it to make it a quality ebuild. vulkan-headers is needed for spirv-tools which is needed for dev-libs/vulkan.
https://github.com/cjwijtmans/vulkan-overlay
If it helps anyone.
Comment 49 C. Wijtmans 2016-11-16 14:30:13 UTC
Dont have the time or energy atm either.
Comment 50 Andrei Slavoiu 2016-11-17 01:32:00 UTC
(In reply to Timo Rothenpieler from comment #40)
> Games and applications using Vulkan would depend on it.
> The drivers have no need for the Vulkan loader.

Unfortunately it's not that easy. While drivers don't need the loader they are useless without it. And all the games that have vulkan renderer are only available through Steam, and that doesn't integrate with portage so they will not be able to depend on the loader.
Comment 51 Timo Rothenpieler 2016-11-17 09:45:29 UTC
(In reply to Andrei Slavoiu from comment #50)
> Unfortunately it's not that easy. While drivers don't need the loader they
> are useless without it. And all the games that have vulkan renderer are only
> available through Steam, and that doesn't integrate with portage so they
> will not be able to depend on the loader.

The Steam ebuild should depend on the loader then, like it depends on X and a bunch of other dependencies right now.
If the user manually installed Steam in his/her homedir, it's not portages responsibility to install its dependencies.
Comment 52 James Le Cuirot gentoo-dev 2016-11-17 10:42:31 UTC
Don't worry about Steam, I'll deal with it somehow. If Vulkan usage in games can be detected by a dependency on some library or by grepping for some string then I can do it dynamically in esteam. Otherwise I'll probably make it a flag in steam-client-meta. I haven't played with Vulkan yet but I could do soon, I play the Talos Principle.
Comment 53 Mart Raudsepp gentoo-dev 2017-01-03 03:26:48 UTC
(In reply to Matt Turner from comment #39)
> (In reply to Andrei Slavoiu from comment #38)
> > (In reply to Matt Turner from comment #35)
> > > I've added media-libs/vulkan-loader to the tree.
> > 
> > What packages are supposed to depend on this? I expected mesa[vulkan] to
> > RDEPEND on it but that is not the case.
> 
> That's an open question. leio suggested that mesa[vulkan] (or the nvidia
> drivers, or any other vulkan driver) should RDEPEND on vulkan-loader.

Can we then finally do that, at least until there's some virtual or whatever to move this to?

> That makes sense to me, but I'm still not sure what's the best way to ensure
> vulkan drivers are installed. E.g., what should vulkan applications RDEPEND
> on?
> 
> Ideas welcome.

We'll need a virtual that gets satified by mesa[vulkan] and any proprietary implementation.
Comment 54 Peter Asplund 2019-02-08 23:16:58 UTC
This can be considered as done, right?
Comment 55 Matt Turner gentoo-dev 2019-02-09 07:19:03 UTC
(In reply to Peter Asplund from comment #54)
> This can be considered as done, right?

I mean, not "done" because there's no virtual/vulkan. But it's not entirely clear to me that it's needed, to be honest.
Comment 56 C. Wijtmans 2019-02-09 16:19:59 UTC
(In reply to Matt Turner from comment #55)
> (In reply to Peter Asplund from comment #54)
> > This can be considered as done, right?
> 
> I mean, not "done" because there's no virtual/vulkan. But it's not entirely
> clear to me that it's needed, to be honest.

there should be a way to select default vulkan implementation? nvidia?mesa?
Comment 57 C. Wijtmans 2019-02-09 16:20:37 UTC
(In reply to C.J. Wijtmans from comment #56)
> (In reply to Matt Turner from comment #55)
> > (In reply to Peter Asplund from comment #54)
> > > This can be considered as done, right?
> > 
> > I mean, not "done" because there's no virtual/vulkan. But it's not entirely
> > clear to me that it's needed, to be honest.
> 
> there should be a way to select default vulkan implementation? nvidia?mesa?

Which device? dGPU, iGPU? dGPU 0 or 1?
Comment 58 Luke A. Guest 2019-02-09 16:26:23 UTC
(In reply to C.J. Wijtmans from comment #56)
> (In reply to Matt Turner from comment #55)
> > (In reply to Peter Asplund from comment #54)
> > > This can be considered as done, right?
> > 
> > I mean, not "done" because there's no virtual/vulkan. But it's not entirely
> > clear to me that it's needed, to be honest.
> 
> there should be a way to select default vulkan implementation? nvidia?mesa?

The whole point of Vulkan is to allow there to be multiple implementations, the application selects which one or ones to use. This is so multiple graphics cards can be used at the same time. Unlike OpenGL. I don't think there is a need for a virtual/vulkan package.
Comment 59 C. Wijtmans 2019-02-09 16:27:51 UTC
(In reply to Luke A. Guest from comment #58)
> (In reply to C.J. Wijtmans from comment #56)
> > (In reply to Matt Turner from comment #55)
> > > (In reply to Peter Asplund from comment #54)
> > > > This can be considered as done, right?
> > > 
> > > I mean, not "done" because there's no virtual/vulkan. But it's not entirely
> > > clear to me that it's needed, to be honest.
> > 
> > there should be a way to select default vulkan implementation? nvidia?mesa?
> 
> The whole point of Vulkan is to allow there to be multiple implementations,
> the application selects which one or ones to use. This is so multiple
> graphics cards can be used at the same time. Unlike OpenGL. I don't think
> there is a need for a virtual/vulkan package.

yes but there should be a default. Which you should be able to change. I was thinking of eselect not virtual. MY bad.
Comment 60 Matt Turner gentoo-dev 2019-02-09 18:06:35 UTC
(In reply to C.J. Wijtmans from comment #59)
> (In reply to Luke A. Guest from comment #58)
> > (In reply to C.J. Wijtmans from comment #56)
> > > (In reply to Matt Turner from comment #55)
> > > > (In reply to Peter Asplund from comment #54)
> > > > > This can be considered as done, right?
> > > > 
> > > > I mean, not "done" because there's no virtual/vulkan. But it's not entirely
> > > > clear to me that it's needed, to be honest.
> > > 
> > > there should be a way to select default vulkan implementation? nvidia?mesa?
> > 
> > The whole point of Vulkan is to allow there to be multiple implementations,
> > the application selects which one or ones to use. This is so multiple
> > graphics cards can be used at the same time. Unlike OpenGL. I don't think
> > there is a need for a virtual/vulkan package.
> 
> yes but there should be a default. Which you should be able to change. I was
> thinking of eselect not virtual. MY bad.

That's not how Vulkan works. See https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Physical_devices_and_queue_families

It's up to the application to enumerate the physical devices (e.g., graphics cards) and pick which one it will execute on. There is not currently a way to specify a preference in Linux for which device it should pick, and when there is it would be in the form of a Vulkan layer with a config file, not an eselect module.

I'm just going to mark as RESOLVED/WONTFIX.