There's code in loader_create_device_chain that detects a VkDeviceGroupDeviceCreateInfoKHR and replaces it with a copy that has the "unwrapped" physical device handle values. This edits members of the existing pNext chain, which may include writing to data that is "const" (and will fault), and also leaves the pNext chain corrupted after the vkCreateDevice call returns.
The text was updated successfully, but these errors were encountered:
It indeed is bad to be editing the pNext chain in-situ like that. Though I'm not seeing a immediate solution. When we call down the chain, those VkPhysicalDevice handles need to be the next layer's handles. This means that not and getting the right one before they are used isn't possible since layers wouldn't know what the right handles are.
I can imagine creating a copy of the pNext chain and passing that down, then on the return copying the results back into original pNext chain, but that plays foul of the same const problems.