Closed Agrael1 closed 2 months ago
I think, just using that check could result in a resource leak, as allocated command buffers would not be freed. That is, I would prefer to have some template magic to resolve that
Besides that: You might have modified your vk.xml, somehow. The <commands>
section is required and definitely part of every vk.xml. In the current version (1.3.291), it's on line 11321.
And a side question: is it somehow assured or verified, that the CommandPool passed into the SharedCommandBuffer constructor is the very same that is used to actually allocate the CommandBuffer?
I think, just using that check could result in a resource leak, as allocated command buffers would not be freed. That is, I would prefer to have some template magic to resolve that
Template magic it is then.
And a side question: is it somehow assured or verified, that the CommandPool passed into the SharedCommandBuffer constructor is the very same that is used to actually allocate the CommandBuffer?
No way unfortunately, only if we had functions to make shared handles. In such case there would need to be all of the functions for shared handles. I dropped that idea, because both approaches looked inconvenient and ugly (operator-> and raw functions)
Ok, so I added the magic, should not compile without the explicit pool argument now
@asuessenbach So, what do you think, can it be merged?
Looks good now! Thanks a lot for your contribution.
@asuessenbach Is it ok to leave it at that? I could do a mandatory pool argument, but it will require another bunch of template metaprogramming, Also I'm not able to test that, since generator breaks with
caught exception: VulkanHppGenerator: Spec error on line 2: missing required element <commands>