loader: apply settings device configurations to device groups - #2011
Conversation
|
Author Wint3rNight not on autobuild list. Waiting for curator authorization before starting CI build. |
1 similar comment
|
Author Wint3rNight not on autobuild list. Waiting for curator authorization before starting CI build. |
|
CI Vulkan-Loader build queued with queue ID 84672. |
charles-lunarg
left a comment
charles-lunarg
left a comment
There was a problem hiding this comment.
Baring a nitpick on a comment and a defensive memset, this looks very good!
Thank you for taking on the fun challenge of device groups.
|
CI Vulkan-Loader build # 3712 running. |
|
CI Vulkan-Loader build # 3712 passed. |
The plain vkEnumeratePhysicalDevices path applies the settings file's device_configurations in terminator_EnumeratePhysicalDevices. Group enumeration did not, so an application enumerating groups could reach a VkPhysicalDevice that the settings file meant to hide, and the validation layer would then fault on a device it had never seen enumerated. Apply the same filter in terminator_EnumeratePhysicalDeviceGroups, reusing loader_apply_settings_device_configurations so the two paths cannot drift apart. If a group contains an excluded VkPhysicalDevice, drop the whole group rather than editing it: the devices in a group are physically linked, so a group with a member removed no longer describes the hardware it claims to. Also publish the post-filter group count. The copy loop already skipped groups whose physicalDeviceCount is zero, but the function published the pre-skip total, so enabling that path would have read past the groups actually written.
bf24cf8 to
e5ab0bd
Compare
|
Author Wint3rNight not on autobuild list. Waiting for curator authorization before starting CI build. |
1 similar comment
|
Author Wint3rNight not on autobuild list. Waiting for curator authorization before starting CI build. |
|
|
|
CI Vulkan-Loader build queued with queue ID 85372. |
|
CI Vulkan-Loader build # 3716 running. |
|
CI Vulkan-Loader build # 3716 passed. |
4 participants
Fixes #1915.
The settings file's
device_configurationslist decides whichVkPhysicalDevices an app gets to see, but onlyvkEnumeratePhysicalDeviceswas honouring it.vkEnumeratePhysicalDeviceGroupsdidn't look at the settings at all, so an app could still get at a hidden device through a group — which is what makes the validation layer fall over in the issue.So a group containing an excluded device now gets dropped. It calls
loader_apply_settings_device_configurationsrather than redoing the deviceUUID/driverUUID/driverVersion matching, so the two paths can't drift apart.Two calls I made that are worth a second opinion:
I drop the whole group instead of removing the hidden device from it. The devices in a group are physically linked, so a group with a member missing doesn't really describe the hardware anymore. Easy to switch if you'd rather strip.
I also changed
phys_dev_group_count_termto count the groups actually written. The copy loop already skips groups withphysicalDeviceCount == 0, but the count included them, andnew_phys_dev_groupsis calloc'd — so a skipped group left a NULL that the memcpy at the end would read. Nothing sets that count to zero today so it was unreachable, but this change makes it reachable.The count query is still an upper bound, same as the plain path does. Getting it exact would mean fetching every group's contents during a count-only call, which seemed like a bad trade.
One log message got reworded, since it named
vkEnumeratePhysicalDevicesand the group path calls it now too.Tests cover a hidden singleton group, a partially hidden group, settings that match nothing, and no settings file at all. Suite's green at 693/693.