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.
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).
Created attachment 427764 [details] vulkan loader git repo ebuild live ebuild for Khronos/LunarG Vulkan loader, validation layer and example sources.
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.
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
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.
Created attachment 428838 [details] media-libs/vulkan-icd-loader-1.0.5.0.ebuild More concise ebuild that only installs the loader and headers.
Theoretically multiple gpus from different vendors should work together on same system through icd.
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.
(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.
(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.
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.
Created attachment 434654 [details] media-libs/vulkan-icd-loader-1.0.11.0.ebuild Updated ebuild
Created attachment 434656 [details] media-libs/vulkan-base-9999 Updated ebuild This version compiles for me, I'm still having issues with Vulkan however
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 [...]
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
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.
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.
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.
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.
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
(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.
(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
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...
(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
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.
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
(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.
(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.
Any progress on this one so far? (sorry for asking)
I need the vulkan libs and headers for my development. The ebuild in overlays are messy not quality worth.
(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.
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.
Please note there is no need for virtual/vulkan, only dev-libs/vulkan for vulkan development.
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 :)
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.
(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.
(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.
(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.
(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.
Games and applications using Vulkan would depend on it. The drivers have no need for the Vulkan loader.
> 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.
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.
(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.
(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.
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
You should sync again, that was already fixed. It's trying to build the layers while it shouldn't.
Thanks, that fixed the build indeed. It would be nice to have all parts of the upstream build eventually.
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.
Dont have the time or energy atm either.
(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.
(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.
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.
(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.
This can be considered as done, right?
(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.
(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?
(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?
(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.
(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.
(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.
