Does the assignment of one VkFence variable to another also assign the state of it?

Vulkan
1

For example,I have two VkFence variables:

VkFence foo;
VkFence bar;

And foo is initially in the unsignaled state.
Then a assignment happans:

bar = foo;

Then for some reasons, foo is signaled and now be in the signaled state.
Will bar also be in the signaled state?

2

Copying a handle does nothing but copy the handle. All copies of it still point to the same underlying object.

3

This is actually a C/C++ question, not a Vulkan-specific question. After the assignment bar = foo, both variables will refer to the same fence. I.e., yes, both variables will always reflect the same state after that assignment.

4

Well, “handle” is a Vulkan concept (and many other APIs too though). But if you imagine a “handle” is a pointer, or an index into an array, then it is a C++ question.

5

But its type is “VkFence” not “VkHandleToFence”,it’s hard to know in the first place that this type points to some underlying objects.

6

Would need superwide screens with such names. If it has to be created, then it is a handle, where the driver holds the impl. If it is plain struct (such as VkExtent2D) then it is just struct. If you do not like it, you can always alias\typedef it to some hungary notation or something like hVkFence. It is not that unclear though. Its definition is VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkFence).

PS: Alternatively you could use Vulkan-Hpp. It might have a different semantics. Vulkan objects are typically non-copyable, so it might have only move semantics and deleted copy constructors and assignments.

2 Likes
7

No it isn’t. Every object given to you by the Vulkan API is either a handle or a pointer. They all work the same.

1 Like
8

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.