Mesa 23de78768b69d5600233df022431b8f26a0907fc regressed the following tests in dEQP: dEQP-VK.api.object_management.single_alloc_callbacks.fence_signaled dEQP-VK.api.object_management.alloc_callback_fail.fence dEQP-VK.api.object_management.alloc_callback_fail.fence_signaled dEQP-VK.api.object_management.single_alloc_callbacks.fence Sample output: ./deqp-vk --deqp-case=dEQP-VK.api.object_management.alloc_callback_fail.fence dEQP Core git-82679917a60b99f4ea6ed42f67de68cbb3a844bb (0x82679917) starting.. target implementation = 'Default' Test case 'dEQP-VK.api.object_management.alloc_callback_fail.fence'.. Test case duration in microseconds = 58464 us Fail (Invalid allocation callback) DONE! Test run totals: Passed: 0/1 (0.0%) Failed: 1/1 (100.0%) Not supported: 0/1 (0.0%) Warnings: 0/1 (0.0%)
This should be fixed as of the following commit: commit 428ffc9c13c24c30c317c2e985b9097956c583b0 Author: Jason Ekstrand <jason.ekstrand@intel.com> Date: Mon Mar 7 14:48:35 2016 -0800 anv/device: Actually free the CPU-side fence struct again In 23de78768, when we switched from allocating individual BOs to using the pool for fences, we accidentally deleted the free.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.