dEQP-VK.memory.device_memory_report.vk_device_memory.allocate_and_free fails when run with validation

[gnl21]

The CTS test dEQP-VK.memory.device_memory_report.vk_device_memory.allocate_and_free fails when run with validation. There are no validation errors but the test code is not able to correlate the memory report records with the allocations that it gets back. It looks like this is caused by the memory report containing object handles that have been wrapped by the validation layer, so they don't correspond to the object handles returned to the app by the validation layer.

[ncesario-lunarg]

Out of curiosity, does setting the environment variable VK_LAYER_DISABLES=VK_VALIDATION_FEATURE_DISABLE_UNIQUE_HANDLES_EXT result in the test passing?

[gnl21]

Yes, if I disable unique handles then the test does pass.

[arno-lunarg]

Since there is little support for this extension, and because it is not possible to do any testing using the Mock ICD, I am not be able to test a solution for this issue, so I am going to un-assign it from me. As a potential solution, one idea would be to intercept the VkDeviceDeviceMemoryReportCreateInfoEXT struct at device creation time, and replace the user supplied callback by a custom one. This custom callback would roughly do the following:

void VVLDeviceMemoryReportCallback(
	const VkDeviceMemoryReportCallbackDataEXT*  pCallbackData,
    void*                                       pUserData)
{
	SomeStruct* blob = (SomeStruct*)pUserData;
	safe_VkDeviceMemoryReportCallbackDataEXT wrapped_data (*pCallbackData);
	wrapped_data.objectHandle = VVLWrapHandle(wrapped_data.objectHandle);
	blob->UserSuppliedCallback(wrapped_data.ptr(), blob->user_supplied_data);
}

[ncesario-lunarg]

It seems like we should be able to modify VkDeviceCreateInfo's pNext chain, wrapping the callbacks in any VkDeviceDeviceMemoryReportCreateInfoEXT that are present.

This is not ideal, but not I'm not sure how we can solve this from the VVL side.