Naming convention for semaphores
@spencer-lunarg is already working on this.
Since Jun 29, 2026.
Assessment
This issue has not been assessed yet.
Description
I was reading this article https://docs.vulkan.org/guide/latest/swapchain_semaphore_reuse.html and thought it was very helpful, but I think understanding it is harder than it needs to be due to a naming convention issue.
The problem is that semaphores are primitives that are signalled at the end of one operation and waited on before another operation starts. But in the current naming convention all semaphores are named after the operation that signals them. For example, submit_semaphore is signalled by vkQueueSubmit but from its name it's not clear whether it's waited by vkQueueSubmit or is signalled by it, and it's also not clear who waits for that semaphore.
I think it could be made much easier to understand if each semaphore was following a naming convention where both the operation that signals it and the operation that waits for it are in its name, for example submit_semaphore becomes submit_to_present and acquire_semaphore becomes acquire_to_submit. Following this convention, it's immediately obvious that acquire does not have a semaphore it's waiting for, that acquire_to_submit separates it from submission, that submit_to_present separates submission to presenting and that presenting does not signal anything, because there's no semaphore named present_to_something.
Note that the same naming convention has proven to work much better for matrices, when object_to_world is used instead of object_matrix, it also works much better for functions, barriers and other entities that in some sense mediate two other entities but that's another story.
- Dominant language
- Makefile
- Stars
- 2.3k
- Forks
- 198
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from KhronosGroup/Vulkan-Guide
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
KhronosGroup/Vulkan-Guide#397 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
KhronosGroup/Vulkan-Guide#396 ·
-
Unclear when non-core formats are allowed to be usedMay be free again @gpx1000 claimed this 117 days ago, and no pull request is open. Opendocumentation
KhronosGroup/Vulkan-Guide#185 · 4 comments · 3 reactions · 2 assignees ·
-
Add section with in-depth details on Vulkan Memory ModelMay be free again @sfricke-samsung claimed this 2441 days ago, and no pull request is open. Opendocumentation
KhronosGroup/Vulkan-Guide#28 · 1 assignee ·
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
KhronosGroup/Vulkan-Guide#15 · 4 comments · 4 reactions ·