32-bit AMDVLK compilation fails in gpurt

[v-fox]

After spending days working around DXC's cmake script bugs to satisfy gpurt's dependency in amdvlk, I managed to successfully make a 64-bit amdvlk package but not 32-bit due to persistent too many elements in vector initialization and if statement conditional expressions must evaluate to a scalar errors: amdvlk_gpurt.log

[Flakebi]

Building a 32-bit package is working fine for me with dxc 1.7.2207 (and seems to work for the official Ubuntu packages as well). Which dxc are you using?

[v-fox]

Building a 32-bit package is working fine for me with dxc 1.7.2207 (and seems to work for the official Ubuntu packages as well). Which dxc are you using?

3 days old commit: microsoft/DirectXShaderCompiler@79856c4a7
Their tag on the main branch seems wrong, so packaging script gets '1.4.0.2274+1249~git20220913.79856c4a7' version but it's '1.7.2207.0' in utils/version.

[qiaojbao]

Currently, we use 1.6.2 dxc version, we will verify more versions later.
You could use this version first.

git clone --depth=1 -b release-1.6.2112 https://github.com/microsoft/DirectXShaderCompiler.git
cd DirectXShaderCompiler
git submodule init
git submodule update
cmake -H. -Bbuilds -GNinja -DCMAKE_BUILD_TYPE=Release -C ./cmake/caches/PredefinedParams.cmake
cmake --build builds

We did not meet any CMake bugs for dxc build.
And, tools are used to compile the shader, so we only build 64bit dxc ang glslang tools.

Also, you could install vulkan-sdk to get dxc tools if you use ubuntu system.

[LAKostis]

Still reproducible with v2022.Q3.5 and dxc from release-1.6.2112 branch GIT 6f204c7. Build log attached
amdvlk_gpurt_alt-32.log

[LAKostis]

Still reproducible with v2022.Q4.1 and dxc from release-1.7.2207 GIT e3f322389dadc5d5370bc8e17d3494a7909b6238. Build log attached
build.log.i586.txt

[LAKostis]

Okay, the build failure was caused by LTO enabled in dxc + missing -DCMAKE_BUILD_TYPE=Release flag. So 2022.Q4.2 + release-1.6.2112 works now.

[Flakebi]

After encountering the same (?) issue in NixOS, it looks like

1. the issue surfaces when building gpurt with a 32-bit directx-shader-compiler that was built with gcc 12
2. the issue goes away after updating dxc to 1.7.2212.1 and amdvlk to 2023.Q1.3 (directx-shader-compiler: remove pinned stdenv workaround NixOS/nixpkgs#222072).

Can you try if compilation works for you with these dxc and amdvlk versions?

[v-fox]

Can you try if compilation works for you with these dxc and amdvlk versions?

No changes for me.
My working 64-bit build of dxc is built with clang-15 while 32-bit build is done by gcc-12 because otherwise it fails with lib/DxcSupport/WinFunctions.cpp:134:15: error: definition of builtin function '_BitScanForward'. Maybe that has something to do with it. So I just build 32-bit amdvlk with -DVKI_RAY_TRACING=OFF for now.

[LAKostis]

After encountering the same (?) issue in NixOS, it looks like

1. the issue surfaces when building gpurt with a 32-bit directx-shader-compiler that was built with **gcc 12**

In my case it builds fine with gcc-12 but with dxc 1.6.2112.

2. the issue goes away after updating dxc to **1.7.2212.1** and amdvlk to **2023.Q1.3** ([directx-shader-compiler: remove pinned stdenv workaround NixOS/nixpkgs#222072](https://github.com/NixOS/nixpkgs/pull/222072)).

Can you try if compilation works for you with these dxc and amdvlk versions?

How you compile 1.7.2212.1 if it fails on linux due conflicting types in directx-headers?

[Flakebi]

No changes for me.

Ok, thanks for trying!

How you compile 1.7.2212.1 if it fails on linux due conflicting types in directx-headers?

You only need the dxc binary, we don’t use directx-headers anywhere.
The nix package build for dxc looks like this: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/graphics/directx-shader-compiler/default.nix

[LAKostis]

No changes for me.

Ok, thanks for trying!

How you compile 1.7.2212.1 if it fails on linux due conflicting types in directx-headers?

You only need the dxc binary, we don’t use directx-headers anywhere. The nix package build for dxc looks like this: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/graphics/directx-shader-compiler/default.nix

I see that you checkout submodules too (which includes DirectX-Headers), so in fact headers are in use. But I'm puzzled why compilation doesn't fail in your case. Nevertheless, this is out of scope, maybe it's my local misconfiguration.

[LAKostis]

For those who interested about directx-headers:

$ git submodule update
Cloning into '/home/lakostis/local/src/git/work/DirectXShaderCompiler/external/DirectX-Headers'...
Cloning into '/home/lakostis/local/src/git/work/DirectXShaderCompiler/external/SPIRV-Headers'...
Cloning into '/home/lakostis/local/src/git/work/DirectXShaderCompiler/external/SPIRV-Tools'...
Cloning into '/home/lakostis/local/src/git/work/DirectXShaderCompiler/external/effcee'...
Cloning into '/home/lakostis/local/src/git/work/DirectXShaderCompiler/external/re2'...
Submodule path 'external/DirectX-Headers': checked out '980971e835876dc0cde415e8f9bc646e64667bf7'
...

But commit 980971e835876dc0cde415e8f9bc646e64667bf7 is not in latest version of DirectX-Headers but in version 1.600.10.

[LAKostis]

After encountering the same (?) issue in NixOS, it looks like

1. the issue surfaces when building gpurt with a 32-bit directx-shader-compiler that was built with **gcc 12**

2. the issue goes away after updating dxc to **1.7.2212.1** and amdvlk to **2023.Q1.3** ([directx-shader-compiler: remove pinned stdenv workaround NixOS/nixpkgs#222072](https://github.com/NixOS/nixpkgs/pull/222072)).

Can you try if compilation works for you with these dxc and amdvlk versions?

I can confirm that everything works with dxc 1.7.2212.1 and amdvlk 2023.Q1.3 both for i586 and x86_64.