https://bugs.winehq.org/show_bug.cgi?id=54763
Bug ID: 54763 Summary: Build-time tests fail in an autobuilder environment Product: vkd3d Version: 1.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs@winehq.org Reporter: smcv@collabora.com Distribution: ---
In a typical distribution autobuilder environment, all builds will be run in a chroot or container, usually on server-class hardware or in a virtual machine. This means tests that just do computation (such as shader compilation) should still succeed, but tests that want to access a real GPU will find that either there is no VkDevice at all, or there is a VkDevice but it's only software rendering (lavapipe).
It seems like vkd3d already has some partial handling for this: run_shader_tests_vulkan() skips itself if a VkDevice cannot be created. However, run_shader_tests_d3d12() still tries to run, and crashes when it can't create a Vulkan instance, for example:
FAIL: tests/cast-to-half ========================
vkd3d:err:vkd3d_instance_init Failed to create Vulkan instance, vr -9. vkd3d:fixme:hresult_from_vk_result Unhandled VkResult -9. vkd3d:err:vkd3d_instance_init Failed to create Vulkan instance, vr -9. vkd3d:fixme:hresult_from_vk_result Unhandled VkResult -9. FAIL tests/cast-to-half.shader_test (exit status: 139)
(Exit status 139 is a segmentation fault.)
Would you consider patches that make the tests skip themselves in this situation? Or should distro packaging just not be running build-time tests at all?
https://bugs.winehq.org/show_bug.cgi?id=54763
--- Comment #1 from Simon McVittie smcv@collabora.com --- Created attachment 74257 --> https://bugs.winehq.org/attachment.cgi?id=74257 tests: If Vulkan runner can't be initialized, also skip D3D12 tests
In an autobuilder environment, it's relatively likely that we won't have access to a fully-functional Vulkan device. If we don't, then we can't expect vkd3d to work either.
---
As an example of the sort of thing I'm talking about, this fixes a build failure that I saw when backporting vkd3d 1.7 to the Steam Runtime 3 'sniper' environment, in a chroot on a virtual machine. This is probably not complete - the vkd3d Debian packaging already had some patches from its Debian maintainer, to skip other tests that were expected to segfault on llvmpipe.
sniper is basically Debian 11, but with some key game-related packages backported, notably the latest stable "SDK" Vulkan-Headers and Vulkan-Loader.
https://bugs.winehq.org/show_bug.cgi?id=54763
--- Comment #2 from Henri Verbeet hverbeet@gmail.com --- Created attachment 74258 --> https://bugs.winehq.org/attachment.cgi?id=74258 patch
(In reply to Simon McVittie from comment #0)
Would you consider patches that make the tests skip themselves in this situation?
Sure, we'll take patches for that. In this particular case, the attached patch should at least avoid the segmentation faults.
https://bugs.winehq.org/show_bug.cgi?id=54763
--- Comment #3 from Simon McVittie smcv@collabora.com --- (In reply to Henri Verbeet from comment #2)
Sure, we'll take patches for that. In this particular case, the attached patch should at least avoid the segmentation faults.
I had wondered about doing that, but went for attachment 74257 instead to try to report the test as skipped, so that people don't get an unrealistic picture of how much coverage vkd3d actually has.
(In practice it still seems to show up as passed rather than skipped in the Autotools test harness, though... perhaps the skipped status isn't getting propagated as a distinctive exit status?)
https://bugs.winehq.org/show_bug.cgi?id=54763
--- Comment #4 from Simon McVittie smcv@collabora.com --- Created attachment 74259 --> https://bugs.winehq.org/attachment.cgi?id=74259 completely ignore results of d3d12 tests when using llvmpipe
From: Michael Gilbert
---
FYI this is another, similar patch that's in the Debian packaging for 1.2. I haven't verified whether it's still necessary in 1.7.
https://bugs.winehq.org/show_bug.cgi?id=54763
--- Comment #5 from Henri Verbeet hverbeet@gmail.com --- (In reply to Simon McVittie from comment #3)
I had wondered about doing that, but went for attachment 74257 [details] instead to try to report the test as skipped, so that people don't get an unrealistic picture of how much coverage vkd3d actually has.
(In practice it still seems to show up as passed rather than skipped in the Autotools test harness, though... perhaps the skipped status isn't getting propagated as a distinctive exit status?)
That's because the shader runner tests get run with a couple of different configurations, and it would be entirely reasonable for e.g. the d3d9 and d3d11 configurations to get run, but not the d3d12 configurations on a particular setup. I think it would make sense to report the test as a SKIP if none of the configurations got run, but we don't currently do that.
https://bugs.winehq.org/show_bug.cgi?id=54763
--- Comment #6 from Henri Verbeet hverbeet@gmail.com --- This should be fixed by commit a0a3fb0e5f2f4b0f16357a62150201d20a5d994d.