Hi, On 2026-07-17 14:06, Simon McVittie wrote: > Source: vkd3d > Version: 2.0+ds-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: [email protected], [email protected] > User: [email protected] > Usertags: riscv64 > > vkd3d 2.0 fails many of its build-time tests on riscv64, with 6 tests > segfaulting and one test failing gracefully: > > https://buildd.debian.org/status/fetch.php?pkg=vkd3d&arch=riscv64&ver=2.0%2Bds-1&stamp=1784232926&raw=0 > > >Segmentation fault > >FAIL tests/d3d12 (exit status: 139) > > >Segmentation fault > >FAIL tests/hlsl_d3d12 (exit status: 139) > > >Segmentation fault > >FAIL tests/hlsl/compute.shader_test (exit status: 139) > > >shader_runner.c:1964: non-const-indexing.shader_test:398: Model 2.0: Test > >failed: Got {5.00000000e+00, 6.00000000e+00, 7.00000000e+00, > >8.00000000e+00}, expected {1.00000000e+00, 2.00000000e+00, 3.00000000e+00, > >4.00000000e+00} at (0, 0). > >FAIL tests/hlsl/non-const-indexing.shader_test (exit status: 1) > > >Segmentation fault > >FAIL tests/hlsl/rasteriser-ordered-views.shader_test (exit status: 139) > > >Segmentation fault > >FAIL tests/hlsl/tgsm.shader_test (exit status: 139) > > >Segmentation fault > >FAIL tests/hlsl/uav-rwbuffer.shader_test (exit status: 139) > > As with the similar armhf bug #1142206, these might well be problems > with Mesa llvmpipe/lavapipe, rather than genuinely being a bug in vkd3d. > > This is probably not actually a regression in vkd3d. Version 1.2 > compiled successfully on riscv64 buildds, but version 1.2 also didn't > actually run the majority of the tests on buildds: the buildd log claims > that all tests passed, but if you build locally in a buildd-like > environment and look at tests/*.log (which unfortunately are not > reflected into the buildd log), you'll see that most (all?) of the tests > were skipped because there was no working Vulkan driver. This is > because, before > https://salsa.debian.org/wine-team/vkd3d/-/commit/d2dcaf91440111271a285b119d2a05ba8409a8b6, > > there was no build-dependency on mesa-vulkan-drivers.
Building vkd3d on a SpacemiT K1 or SpacemiT K3 board leads to way better results with only 2 failures and without segfault: d3d12: 2485463 tests executed (4 failures, 27 skipped, 64 todo, 11 bugs). FAIL tests/d3d12 (exit status: 1) shader_runner: 1364 tests executed (1 failures, 0 skipped, 2 todo, 0 bugs). FAIL tests/hlsl/non-const-indexing.shader_test (exit status: 1) At this time it's not clear to me if it's because the CPUs are faster or because they include the Vector extension. I am able to reproduce the same failures as you reported on a JH7110 CPU, so I would tend to say that the CPU speed is not the explanation here. But it means that vkd3d works reasonably well for some of our users using recent CPUs. > Wine upstream seems unlikely to be actively supporting riscv64, and > nothing in Debian seems to depend on vkd3d (yet?), so I think it might > be most realistic to drop vkd3d from the riscv64 architecture and then > ask the ftp team to remove the old "cruft" binaries, unless a riscv64 > porter is available to investigate this in detail. > > Alternatively, if maintainers of vkd3d and/or riscv64 (and armhf) > porters are reasonably confident that it does work on systems with an > actual GPU, another possible workaround would be to skip the tests or > ignore their results on riscv64 (and armhf). I am not sure I have a good view about the usefulness of vkd3d on riscv64, I leave you decide here. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
