• Bug#1103352: dxvk: FTBFS on armhf and other non-x86 non-aarch64 archite

    From Simon McVittie@21:1/5 to All on Wed Apr 16 18:50:01 2025
    Source: dxvk
    Version: 2.6.1-1
    Severity: serious
    Tags: upstream ftbfs experimental
    Justification: built successfully in the past on armhf

    dxvk 2.6.1 with DXVK Native enabled doesn't build successfully on armhf:

    c++ -Isrc/wsi/libwsi.a.p -Isrc/wsi -I../src/wsi -Iinclude -I../include -I../include/vulkan/include -I../include/spirv/include -Iinclude/native -I../include/native -I../include/native/windows -I../include/native/directx -I../subprojects/libdisplay-info/
    include -I/usr/include/SDL2 -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -Wall -Winvalid-pch -Wextra -std=c++17 -Wimplicit-fallthrough -Wno-missing-field-initializers -Wno-unused-parameter -Wno-misleading-indentation -Wno-cast-function-type -Wno-
    unused-const-variable -Wno-missing-braces -DDXVK_WSI_SDL2 -g -O2 -ffile-prefix-map=/build/reproducible-path/dxvk-2.6.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_
    BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE=1 -D_REENTRANT -MD -MQ src/wsi/libwsi.a.p/wsi_platform.cpp.o -MF src/wsi/libwsi.a.p/wsi_platform.cpp.o.d -o src/wsi/libwsi.a.p/wsi_platform.cpp.o -c ../src/wsi/wsi_platform.cpp
    In file included from ../src/wsi/../util/util_string.h:10,
    from ../src/wsi/../util/util_env.h:3,
    from ../src/wsi/wsi_platform.cpp:4: ../src/wsi/../util/util_bit.h:12:2: error: #error "Unknown CPU Architecture"
    https://buildd.debian.org/status/fetch.php?pkg=dxvk&arch=armhf&ver=2.6.1-1&stamp=1744304328&raw=0

    A crude way to mitigate this issue would be to limit compilation of
    DXVK Native to amd64, i386 and arm64 only, after which this bug could
    be downgraded to wishlist until a porter steps in to help; please let me
    know if you would like a MR for this. But of course ideally DXVK Native
    would be portable (I don't think there's any fundamental reason why it
    can't be compilable on every architecture).

    There seem to be two places in the dxvk codebase that #error out if the
    CPU architecture is not recognised.

    1. src/util/util_bit.h

    There is some conditional-compilation of this form (pseudocode):

    #if (architecture is x86_64 or i386)
    #define DXVK_ARCH_X86
    #if (architecture is x86_64)
    #define DXVK_ARCH_X86_64
    #endif
    #elif (architecture is aarch64)
    #define DXVK_ARCH_ARM64
    #else
    #error
    #endif

    But all the conditional compilation further down the file seems to have a portable "#else" fallback available, so probably it would be OK to replace
    the "#error" with just not defining any of the helper macros on unrecognised architectures?

    2. src/util/sync/sync_spinlock.h

    The implementation of dxvk::sync::spin calls _mm_pause() on x86, uses inline assembly to call "yield" on aarch64, and emits a #error "Pause/Yield not implemented for this architecture." otherwise. For this to be portable, it would need a fallback for other architectures.

    Looking at https://codesearch.debian.net/search?q=_mm_pause&literal=1
    it seems that a reasonable implementation for other architectures would
    be to do nothing at all (and porters can contribute an implementation
    for their architecture if they want to).

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to Simon McVittie on Wed Apr 16 21:10:01 2025
    Control: forwarded -1 https://github.com/doitsujin/dxvk/pull/4853

    On Wed, 16 Apr 2025 at 17:45:32 +0100, Simon McVittie wrote:
    There seem to be two places in the dxvk codebase that #error out if the
    CPU architecture is not recognised.

    1. src/util/util_bit.h
    2. src/util/sync/sync_spinlock.h

    https://github.com/doitsujin/dxvk/pull/4853 is an untested implementation
    of the "generic CPU" code path that I suggested in the bug report.

    After DXVK compiles successfully, it would also become useful to apply https://salsa.debian.org/aviau/dxvk/-/merge_requests/11, but there's little point in applying that MR until the build would be expected to succeed.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian Bug Tracking System@21:1/5 to All on Wed Apr 16 21:10:01 2025
    Processing control commands:

    forwarded -1 https://github.com/doitsujin/dxvk/pull/4853
    Bug #1103352 [src:dxvk] dxvk: FTBFS on armhf and other non-x86 non-aarch64 architectures: #error "Unknown CPU Architecture"
    Set Bug forwarded-to-address to 'https://github.com/doitsujin/dxvk/pull/4853'.

    --
    1103352: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103352
    Debian Bug Tracking System
    Contact [email protected] with problems

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to Simon McVittie on Mon May 12 13:50:01 2025
    Control: tags -1 + pending

    On Wed, 16 Apr 2025 at 19:50:46 +0100, Simon McVittie wrote: >https://github.com/doitsujin/dxvk/pull/4853 is an untested implementation
    of the "generic CPU" code path that I suggested in the bug report.

    This was applied in the packaging git repo as part of an updated https://salsa.debian.org/aviau/dxvk/-/merge_requests/11.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian Bug Tracking System@21:1/5 to All on Mon May 12 13:50:01 2025
    Processing control commands:

    tags -1 + pending
    Bug #1103352 [src:dxvk] dxvk: FTBFS on armhf and other non-x86 non-aarch64 architectures: #error "Unknown CPU Architecture"
    Added tag(s) pending.

    --
    1103352: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103352
    Debian Bug Tracking System
    Contact [email protected] with problems

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)