KhronosGroup / KhronosGroup/Vulkan-Docs

vkGetMemoryWin32HandleKHR behavior should be more explicit

Open
#2,420 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
3.3k
Forks
549
Avg merge
5d 5h
Merged PRs (30d)
2

Description

Hello, I'm investigating the behavior of interop functions for device memory allocations.

I have stumbled upon [this spec](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/vkGetMemoryWin32HandleKHR.html) for win32 handles. After analyzing the behavior on multiple graphics cards the behavior is different. One returns the same handle, the second returns different handle.

I'd like to propose a fix, to make the API more stable, and add opportunity to create handles for the same memory the same way that Fd does: Creating a duplicate handle on subsequent calls. Making them open a duplicate handle will just make internal shared counter increment, so it wouldn't be much of an overhead.

Every such handle will need to be closed.

Proposed change:

```
VUID-VkMemoryGetWin32HandleInfoKHR-handleType-00663
If handleType is defined as an NT handle, vkGetMemoryWin32HandleKHR must be called no more than once for each valid unique combination of memory and handleType
```
shall be removed from the spec.

Contributor guide

Open the contributing guide

Research direction

Start with the linked vkGetMemoryWin32HandleKHR specification page and locate VUID-VkMemoryGetWin32HandleInfoKHR-handleType-00663. Review the documented restriction alongside the proposed duplicate-handle behavior and the issue's observations about repeated calls. Done means the specification change is resolved and the relevant wording reflects the agreed behavior.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.