By code inspection of terminator_CreateDisplayPlaneSurfaceKHR(), it appears that this function may not function as intended when multiple ICDs that implement icd_term->dispatch.CreateDisplayPlaneSurfaceKHR.

Around here:

is code that loops over all ICDs. It dispatches vkCreateDisplayPlaneSurfaceKHR to every ICD that implements icd_term->dispatch.CreateDisplayPlaneSurfaceKHR. If any of the ICDs returns a VkResult other than VK_SUCCESS, then the function early-exits with that VkResult (with that error).

The displayMode member of the VkDisplaySurfaceCreateInfoKHR structure is a VkDisplayModeKHR.
A VkDisplayModeKHR is a non-dispatchable handle with parent type VkDisplayKHR.
A VkDisplayKHR is a non-dispatchable handle with parent type VkPhysicalDevice.
VkPhysicalDevice identifies one ICD.

I had expected the loader to dispatch vkCreateDisplayPlaneSurfaceKHR to the one ICD that exposed the indirectly-referenced VkPhysicalDevice , and not to dispatch it to any other ICDs. That is not how the loader behaves.
As written, when the loader vkCreateDisplayPlaneSurfaceKHR to an ICD that did not expose the indirectly-referenced VkPhysicalDevice, then I expect that other ICD to return a VkResult that is not VK_SUCCESS. This will cause terminator_CreateDisplayPlaneSurfaceKHR() to early exit and to return that same error VkResult.

If the loader does not know the relationship VkDisplayModeKHR -> VkDisplayKHR -> VkPhysicalDevice due to the loader not tracking the objects VkDisplayModeKHR and VkDisplayKHR, then perhaps a reasonable fix is the following:

• Deprecate vkCreateDisplayPlaneSurfaceKHR
• Create a new vkCreateDisplayPlaneSurface2KHR
  • This command is like the previous command, but it also includes a parameter of type VkPhysicalDeviceKHR.
  • Have the loader unpack the physical device to obtain the ICD that owns the physical device.
  • Have the loader dispatch this new command to only that one ICD.