[bug#57297,0/7] Update vulkan packages and add vulkan-validationlayers

Hi,

This patch series adds vulkan-validationlayers 1.2.201 and updates the dependent vulkan packages to compatible versions from approximately the same time period. I had added/updated these packages in a local channel about 8 or 9 months ago and have been running multiple systems with them since then. My motivation at the time was to add vulkan-validationlayers for use with the Vulkan tutorial at https://vulkan-tutorial.com.

It was only recently that I was able to fix an issue with the tutorial program not finding the .so for the validation layer, by patching the layer manifest file with the full store path of the .so. A similar phase would need to be added to the mesa package definition for its device selection layer to work properly. The error from the mesa layer not being found when I run the basic tutorial program is:

  !! validation layer: libVkLayer_MESA_device_select.so: cannot open shared object file: No such file or directory

The 'set-layer-path-in-manifest phase in vulkan-validationlayers resolved a similar error about libVkLayer_khronos_validation.so.

Final note: I went to update these packages to their latest versions before submitting the series, but they trigger warnings when running programs using Vulkan with Mesa 21.3.8 due it not supporting Vulkan 1.3 (I forget the exact warning).

Cheers,
Kaelyn


Kaelyn Takata (7):
  gnu: spirv-headers: Update to 1.2.198.0.
  gnu: spirv-tools: Update to 2021.4.
  gnu: vulkan-headers: Update to 1.2.202.
  gnu: vulkan-loader: Update to 1.2.202.
  gnu: vulkan-tools: Update to 1.2.201.
  gnu: shaderc: Update to 2021.3.
  gnu: Add vulkan-validationlayers.

 gnu/packages/vulkan.scm | 94 +++++++++++++++++++++++++++++------------
 1 file changed, 68 insertions(+), 26 deletions(-)


base-commit: 65cabb010e3388d10f9b25ec560bfcfab5f810d4
--
2.37.2
  

Thank you for the patches.  Overall they look good to me, but I have
some comments:

- the first patch updates spriv-headers from 1.5.3 to 1.2.198.0.  This
  looks like a downgrade.  Is this jump in version numbers expected?

- the commit message for the vulkan-loader update should mention the
  changes in the build system arguments:

* gnu/packages/vulkan.scm (vulkan-loader): Update to 1.2.202.
[arguments]: Enable tests by removing obsolete build phase
'disable-loader-tests and adjusting configure flags.

- in the patch for vulkan-validationlayers I’d use #$output instead of
  binding out to (assoc-ref outputs "out").

Other than that this all looks good to me!
  

This is a small V2 update to rebase against master and address review
feedback. The changes are:

* Update the commit message for the vulkan-loader update to include the
  [arguments] change.
* Use #$output instead of binding (assoc outputs "out") in the package
  definition for vulkan-validationlayers

Also worth noting is that the versioning scheme for spirv-headers has changed;
the old version scheme went up to 1.5.4 in late 2020, and starting in 2021 the
version tags are the sdk-1.x.y.z tags used with other Vulkan SDK components
(ref: https://github.com/KhronosGroup/SPIRV-Headers/tags).

Kaelyn Takata (7):
  gnu: spirv-headers: Update to 1.2.198.0.
  gnu: spirv-tools: Update to 2021.4.
  gnu: vulkan-headers: Update to 1.2.202.
  gnu: vulkan-loader: Update to 1.2.202.
  gnu: vulkan-tools: Update to 1.2.201.
  gnu: shaderc: Update to 2021.3.
  gnu: Add vulkan-validationlayers.

 gnu/packages/vulkan.scm | 93 +++++++++++++++++++++++++++++------------
 1 file changed, 67 insertions(+), 26 deletions(-)


base-commit: c053dfa52dc778eb3d965f58a85c435ae7fab0dd
--
2.37.2
  

This looks good, thank you!

Because updating vulkan-headers leads to rebuilds of 1000+ packages I
pushed it all to a new branch update-vulkan-headers and asked
ci.guix.gnu.org to build it on x86_64:

  https://ci.guix.gnu.org/jobset/update-vulkan-headers

Once it’s all been built and we see that it doesn’t break any existing
packages we can merge it into the “master” branch.
  

I had rebased this on top of the “staging” branch.  It seems that these
changes break a lot of downstream packages, such as weston, which builds
fine on staging, but fails on update-vulkan-headers-staging.

You can see all new failures here:
https://ci.guix.gnu.org/jobset/update-vulkan-headers

Here is the failing build of weston:
https://ci.guix.gnu.org/build/1444003/details

(I just restarted it to see if it’s a transient problem.)

Could you please take a look?
  

------- Original Message -------
On Friday, September 16th, 2022 at 6:34 AM, Ricardo Wurmus <rekado@elephly.net> wrote:


> I had rebased this on top of the “staging” branch. It seems that these
> changes break a lot of downstream packages, such as weston, which builds
> fine on staging, but fails on update-vulkan-headers-staging.
> 
> You can see all new failures here:
> https://ci.guix.gnu.org/jobset/update-vulkan-headers
> 
> Here is the failing build of weston:
> https://ci.guix.gnu.org/build/1444003/details
> 
> (I just restarted it to see if it’s a transient problem.)
> 
> Could you please take a look?
> 
> --
> Ricardo

Thank you for rebasing the patches, and for letting me know of the failures. I'm starting to investigate now, and have already reproduced the weston failure locally. At first glance the weston failure at least might be an (unfortunate) incompatibility with the old version of weston--weston 9.0.0 was released just over two years ago, and over a year before the vulkan versions on the branch.

Cheers,
Kaelyn
  

Hi,

Sorry for the long period of silence on this patch set! I have finally found a fix for the mpv build failure with the updated spirv-headers and spirv-tools (and likely any others that failed with similar undefined symbols as well). While trying to figure out why mpv wasn't building when other distros have been shipping the same version of mpv against updated spirv & vulkan packages, I started examining their package definitions to see why that may be.

The fix is to add "-DSPIRV_TOOLS_BUILD_STATIC=OFF" to the configure flags for spirv-tools. Apparently a change to spirv-tools in late 2020 caused issues when statically linking (lost the link to the ML thread), and the common packaging approach seems to be to disable the static libs with that flag[1][2].

Quick question on procedure: would it be better to send to this bug a revised version of the single patch (#2 of 7), or to rebase the set against the tip of the staging branch and send in a v3 of all 7 patches?

Cheers,
Kaelyn


[1] https://github.com/archlinux/svntogit-packages/blob/packages/spirv-tools/trunk/PKGBUILD#L27
[2] https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/spirv-tools/spirv-tools-1.3.224.ebuild#n39