On Sun, Jul 05, 2020 at 10:02:39PM -0600, Thomas Frohwein wrote:
> Hi,
>
> Below is the update to latest vulkan sdk versions 1.2.141.0 from end of
> May. Pass portcheck and make port-lib-depends-check. The 'make test'
> for glslang still shows the same error as previously [1].
> vkcube, vkcubepp, and vkquake run without problems on this Intel
> Skylake machine. vulkaninfo does it's job, but complains about not
> being able to identify the executable, probably because of the stub
> needed for loader_platform_executable_path().
>
> This is largely base on jsg@'s diff from April [2], but updated for the
> latest SDK. Also some help from brynet@ with vulkan-loader as detailed
> below.
>
> I'm aware of the issue with aarch64 build failures and the workaround
> that led to problems with i386 [3] and would like to tackle this
> separately after this update.
>
> A few bulletpoints to highlight about the update:
>
> - add COMPILER to spirv-headers as it uses C++ (seen in my build log)
> - NO_BUILD=Yes for vulkan-headers, as there is nothing to build
> - libvulkan now uses alloca(3) (unfortunately). The define to
> __builtin_alloca doesn't get picked up from stdlib.h, therefore added
> the line to vk_loader_platform.h. Discussed this with brynet@; a
> replacement with malloc is likely non-trivial. Maybe in the future
> this can be revisited.
The problem here is it builds with _XOPEN_SOURCE=500 which changes
alloca() visibility. A better way of handling this would be to patch
out the places which do this, diff below.
> - loader_platform_executable_path() is meant to return the path of the
> running executable, on Linux done via procfs. Just stubbed it to
> return NULL as we don't have that functionality. If other ports
> depend on this, it will likely need to be hardcoded in the respective
> ports (none known so far).
> - update MODPY_VERSION for vulkan-tools to 3.8
> (MODPY_DEFAULT_VERSION_3); builds and runs fine here.
>
> Testing welcome, as this is a more complex update. vulkan should run on
> any amdgpu or newer Intel (>= Braswell) GPU.
>= Broadwell / gen 8 on Intel, shows in dmesg now
inteldrm0: msi, BROADWELL, gen 8
> Other applications that can use vulkan other than the ones tested so
> far are emulators/ppsspp and emulators/dolphin.
>
> ok?
It would be great to get this in, I think we should not go with the
__builtin_alloca define as discussed earlier but otherwise looks good.
I can try help with the aarch64 build after it is in.
ok jsg@ if you drop the alloca define and add this
--- CMakeLists.txt.orig Mon Jul 6 16:37:26 2020
+++ CMakeLists.txt Mon Jul 6 16:40:03 2020
@@ -170,7 +170,6 @@ else(UNIX AND NOT APPLE) # i.e.: Linux
target_link_libraries(asm_offset Vulkan::Headers)
add_custom_command(OUTPUT gen_defines.asm DEPENDS asm_offset COMMAND
asm_offset GAS)
add_custom_target(loader_asm_gen_files DEPENDS gen_defines.asm)
- target_compile_definitions(asm_offset PRIVATE _XOPEN_SOURCE=500) #
hush compiler warnings for readlink
else()
message(WARNING "Could not find working x86 GAS
assembler\n${ASM_FAILURE_MSG}")
set(OPT_LOADER_SRCS ${OPT_LOADER_SRCS} unknown_ext_chain.c)
@@ -290,8 +289,6 @@ else()
endif()
if(NOT APPLE)
- target_compile_definitions(vulkan PRIVATE _XOPEN_SOURCE=500) # hush
compiler warnings for readlink
-
# Generate pkg-config file.
include(FindPkgConfig QUIET)
if(PKG_CONFIG_FOUND)
