Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Naming convention for semaphores

Đang mở
  • Có gì không ổn?
#343 2 bình luận 0 reaction 1 người được giao Xem trên GitHub

@spencer-lunarg đang làm issue này rồi.

Từ ngày 29/6/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

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.

Ngôn ngữ chính
Makefile
Star
2.3k
Fork
198
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của KhronosGroup/Vulkan-Guide

Tất cả issue của KhronosGroup/Vulkan-Guide

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.