[NVIDIA] Explicit sync on nested Wayland with gamescope upscaling crashes from vkImportSemaphoreFdKHR failed
#1662
Comments
|
I haven't looked yet, but GameScope isn't by chance trying to directly import a DRM timeline syncobj FD into Vulkan as a timeline semaphore is it? That's definitely not allowed by any current spec, but probably works on Mesa drivers and not ours. Even if that's the case, we're not allowed to crash, so it'd still be a driver bug. Just wanted to see if it's a possibility. |
|
For future reference, I've filed NV-internal bug 5007734 to track this issue. |
this is probably best answered by @misyltoad or someone with a better understanding of the code than myself |
That is exactly what we are doing, works fine on Mesa. Why would this be forbidden by the spec? To my knowledge, there is no language that forbids importing a syncobj just because it's timeline -- it is just explicit that the type must match: It's only forbidden to import timelines from syncobjs temporarily, which we don't do. |
There is no language that allows importing a syncobj in the first place. OPAQUE_FD does not mean syncobj. It would be welcome if you could propose a new extension that provided a SYNCOBJ_FD handle type. |
|
It has long been decided that OPAQUE_FD is syncobj compatible on Linux. |
No, it hasn't. That just happens to be true on Mesa-based drivers at the moment. I don't think there's even consensus among all Mesa/DRM developers that syncobj will always be the optimal primitive to implement timeline semaphore OPAQUE_FD handles on Linux. That debate aside, Khronos arbitrates how Vulkan works, not Mesa or DRM. If you want to modify Vulkan to allow this, as suggested, you can write an extension, but it would be pretty nasty to retroactively alter the behavior of the existing handle type and NVIDIA would never implement that. An extension that allows implementing a new handle type which refers specifically to DRM timeline syncobjs would be more reasonable, and we could implement that if/when we supported such functionality. I should note though, the main reason this wasn't done before was some Mesa developers weren't sure exposing the DRM syncobj handle type was the greatest idea long term. I've since seen comments to the effect that it's probably fine, but I don't know if there's consensus. The VUID you referenced only applies if what you're importing was exported from Vulkan, as the OPAQUE_* types are scoped to the Vulkan spec by default, unless some other API has specifically written an extension to define something compatible with these handle types, e.g., all the opaque handle usage in OpenGL's external object specifications. All these extensions have requirements that the driver UUID and physical device UUID of the exporting device match the importing one, which ensures both drivers agree on the actual handle type, which is specifically there to avoid anyone making these sorts of assumptions. As stated, it should be possible to gracefully fail the import in our driver. Not doing so is a bug on our part. However, if gamescope doesn't handle that failure (We should return VK_ERROR_INVALID_EXTERNAL_HANDLE), it still won't work. |
|
I took a closer look at this issue. It seems like we do gracefully fail in vkImportSemaphoreFdKHR() in the case @cubanismo described. You can also see this in Gamescope logs.
In Gamescope, CVulkanDevice::ImportTimelineSemaphore() method returns nullptr if this Vulkan function fails. Gamescope later tries to dereference this nullptr in CVulkanDevice::submitInternal(), causing the crash. |
Is there an existing issue for this?
Are you using any gamescope patches or a forked version of gamescope?
Current Behavior
Using gamescope on NVIDIA with 555 series drivers or later causes gamescope to coredump after briefly launching but only showing a black window. The issue only occurs while using gamescope's upscaling, which implements explicit sync since #1463 was merged
This issue no longer occurs if you do one of several things:
ENABLE_GAMESCOPE_WSI=0 gamescope -F fsr -- vkcubeworks, but you lose HDR without Gamescope WSIgamescope/src/Backends/DRMBackend.cpp
Line 72 in 6330a32
The issue also does not occur on the Vulkan developer driver series.
Steps To Reproduce
gamescope -F fsr -- vkcubeor any other upscaling methodHardware information
Software information
Which gamescope backends have the issue you are reporting?
Logging, screenshots, or anything else
Looking at my logs, it seems like it happens after Gamecope WSI establishes its swapchain.
It generates the following coredump:
nvidia-bug-report.log.gz
The text was updated successfully, but these errors were encountered: