GPUOpen-Drivers / AMDVLK

AMD Open Source Driver For Vulkan
MIT License
1.7k stars 160 forks source link

Release 2022.Q3.4 fails to compile due to missing header #293

Closed v-fox closed 6 months ago

v-fox commented 1 year ago

Tried updating to 2022.Q3.4 but got:

[ 9998s] /home/abuild/rpmbuild/BUILD/amdvlk-2022.Q3.4/gpurt/src/gpurtDevice.cpp:56:10: fatal error: 'pipelines/g_internal_shaders.h' file not found
[ 9998s] /home/abuild/rpmbuild/BUILD/amdvlk-2022.Q3.4/gpurt/src/gpurtInternalShaders.cpp:31:10: fatal error: 'pipelines/g_internal_shaders.h' file not found
Flakebi commented 1 year ago

Hi, 2022.Q3.4 added two new dependencies for the gpurt library. The DirectXShaderCompiler and glslang are needed: https://github.com/GPUOpen-Drivers/AMDVLK#install-shader-compiler-tools (sudo apt install dxc glslang-tools on Ubuntu or compiled from source/other packages on other distributions)

jinjianrong commented 1 year ago

please refer to the readme: https://github.com/GPUOpen-Drivers/AMDVLK/tree/master#install-shader-compiler-tools

v-fox commented 1 year ago

Hi, 2022.Q3.4 added two new dependencies for the gpurt library. The DirectXShaderCompiler and glslang are needed:

Thanks for clearing that up. But if those are hard dependencies then build should fail immediately on configuration instead of 3 hours into compilation. It should do its own search for dependencies, that's what cmake is for.

UPD: barely managed to make a build of a package just now. As customary, DirectXShaderCompiler is a giant LLVM fork (meaning that it build for half an hour with >95% of unnecessary code) with broken installation directives (so, manual file movement is required after build) as dependency for 200kb library which itself is a dependency of another LLVM fork which is amdvlk. So one can build LLVM to build LLVM fork to build another LLVM fork, then have all 3 of them installed with 95% of code being unused. But, at least, there were no need to manually pass header and library paths to amdvlk's cmake script, It ate it up after proper packaging of dxc.

I recommend closing this after proper pre-build dependency check is implemented. Or, even better, dxc is integrated into amdvlk's own fork.

RarogCmex commented 1 year ago

I am avoiding that bug by implementing raytracing USE flag in ebuild. See https://wiki.gentoo.org/wiki/AMDVLK#Raytracing_support_and_DXC and https://gitweb.gentoo.org/repo/proj/guru.git/commit/?h=dev&id=26c0cadb6e243d8fdf6aaaa6262727c127ebcd44

RarogCmex commented 1 year ago

-DVKI_RAY_TRACING=$(usex raytracing)

v-fox commented 1 year ago

-DVKI_RAY_TRACING=$(usex raytracing)

Thanks for this pointer. After I achieved stability with Mesa, I gave up on amdvlk. But disabling this for 32-bit builds only to let them compile to be packaged as potential fallback is a good idea.