As the title suggests vkResetFences fails to reset the supplied fences to the unsignaled state. I am using the latest master branch on Ubuntu 15.10 and the version of LunarG's loader is 1.0.11.0. My laptop has a Broadwell cpu and I have experienced the same bug on another laptop that uses an Ivy Bridge cpu. I am attaching a simple program that reproduces the bug.
Created attachment 123453 [details] Simple program to reproduce bug
I can confirm this on Haswell - but I think the root cause is misdiagnosed. Fences behave as though they were always signalled, I've added another test case to illustrate. Even if a fence is created in the unsignalled state, vkGetFenceStatus and vkWaitForFences always return VK_SUCCESS.
Created attachment 124229 [details] Test case to show fences alway behaving as though signalled
Indeed, I think the problem is not vkResetFences(). I had a look at the source code and it seems that there is logic in vkGetFenceStatus() to actually reset the fence to the signalled state if it is not in use. You can find the logic in anv_device.c lines 1516-1520. Maybe the same logic is found in vkWaitForFences() as well. Also, I noticed that vkCreateFence() always creates the fence in the unsignalled state and ignores the flags from the creation info struct.
Just to clarify, I do not think that the current behaviour of vkGetFenceStatus() is correct according to the specification. As far as I understand the specification does not state that an unsignalled fence which is not in use should be reset to the signalled state after a call to vkGetFenceStatus(). My understanding is that vkGetFenceStatus() should be a simple getter method that returns the signalled state of the fence.
This seems to be resolved, at least on mesa git-0cee3fd5c73acf7e3841a7d790e3ec3031b0fe41.
I think this is probably fixed. Feel free to re-open if it isn't.
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.