On 2016-02-27 19:32, Kenneth Graunke wrote: > On Saturday, February 27, 2016 2:47:22 PM PST Jacek Konieczny wrote: >> The same handle returned by all vkCreateSemaphore() calls confuses >> validation layers: >> >> SEMAPHORE(ERROR): object: 0x1 type: 5 location: 1443 msgCode: 0: > vkQueueSubmit: Semaphore must not be currently signaled or in a wait state >> >> Signed-off-by: Jacek Konieczny <jaj...@jajcus.net> >> --- >> src/intel/vulkan/anv_device.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c >> index 5993055..96aef00 100644 >> --- a/src/intel/vulkan/anv_device.c >> +++ b/src/intel/vulkan/anv_device.c >> @@ -1546,7 +1546,9 @@ VkResult anv_CreateSemaphore( >> * rings. As such, there's nothing to do for the user space semaphore. >> */ >> >> - *pSemaphore = (VkSemaphore)1; >> + static uint64_t value = 0; >> + >> + *pSemaphore = (VkSemaphore) ++value; >> >> return VK_SUCCESS; >> } >> > > I believe this is okay on x86_64, but it would need locking (or an > atomic increment operation) on 32-bit systems. I'll gladly defer > to the maintainers as to whether they care, however.
Indeed, I completely forgot about multiple threads here. Extra locking code would probably be an overkill here and atomic increment should do. Jacek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
