[QUOTE=Stephan Soller;31203]Thats pretty much what I thought the difference between events and semaphors is about in Vulkan. Events = fine grained GPU only synchronization. Semaphors = coarse grained synchronization the OS can work with. But that’s only hopeful guesswork on my part. I hoped someone from the working group could clarify this.
[/QUOTE]
You are going to have 3 variations of events at least:
signaled by CPU and waited on by GPU (waiting on the cpu side SSBO buffer to be filled before DMA)
signaled by GPU and waited on by CPU (waiting on a finished DMA to (re)use the CPU-side buffer)
signaled by GPU and waited on by GPU (waiting on a renderpass to complete and the target texture to become readable to use the resulting shadowmap)
That is assuming no hybrid event are allowed
[QUOTE=Stephan Soller;31203]
This is just a way to make an event loop execute a callback for each incoming event. And like you said this can be done by the programmers themselfs, no need to have such a thing in Vulkan.
But such a function would defeat the point. It would only wait for events from Vulkan. It wouldn’t be possible to include other HANDLEs or file descriptors into the waiting process. I couldn’t use that code to also wait for incoming video or audio buffers or network packets. So even such a simple example would require to isolate Vulkan into it’s own thread, shuffle buffers to and from that thread with some queues and do some polling there to see if new buffers or Vulkan events are pending. Just because I can’t integrate it into an OS event loop that uses MsgWaitForMultipleObjects(…) or poll(…). That’s pretty much like it is today with OpenGL.
But all that would evaporate if I could get a waitable HANDLE or file descriptor out of a Vulkan semaphor. Something like in that pseudo code:
VK_SEMAPHOR sem = { ... };
vkQueueSubmit(queue, 1, commandBuffers, fence);
vkQueueSignalSemaphore(queue, &sem);
// Linux
int fd = 0;
vkSemaphoreOSHandle(&sem, &fd, sizeof(fd));
// use fd in a poll(...), select(...), epoll(...) event loop
// Windows
HANDLE event;
vkSemaphoreOSHandle(&sem, &event, sizeof(event));
// use event in a WaitForMultipleObjects(...), MsgWaitForMultipleObjects(...), etc. event loop
The vkSemaphoreOSHandle(…) function would return the underlying OS object for the semaphor. And that OS object can be used in the operating systems event multiplexing functions. Of course the vkQueueSubmit(…) and vkQueueSignalSemaphore(…) calls would usually be within the event loop, not before it. I hope this clarifies what I’m looking for.[/QUOTE]
The callback in my code could be used to signal the OS-level event in the passed in void* userdata however that would introduce some extra delay and tie up a mostly-idle thread however it removes the OS specific event handling from the vulkan spec. I can see that going either way.
