Unify vkb::allocated::Allocated and vkb::allocated::HPPAllocated into vkb::allocated::Allocated<bindingType>

asuessenbach commented 1 month ago

Description

Next class unified between C- and C++-bindings.

Build tested on Win10 with VS2022. Run tested on Win10 with NVidia GPU.

General Checklist:

Please ensure the following points are checked:

[x] My code follows the coding style
[x] I have reviewed file licenses
[x] I have commented any added functions (in line with Doxygen)
[x] I have commented any code that could be hard to understand
[x] My changes do not add any new compiler warnings
[x] My changes do not add any new validation layer errors or warnings
[x] I have used existing framework/helper functions where possible
[x] My changes do not add any regressions
[x] I have tested every sample to ensure everything runs correctly
[x] This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:
- [x] I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
- [ ] My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions
If this PR contains framework changes:
- [x] I did a full batch run using the batch command line argument to make sure all samples still work properly

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

[ ] I have tested the sample on at least one compliant Vulkan implementation
[ ] If the sample is vendor-specific, I have tagged it appropriately
[ ] I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
[ ] Any dependent assets have been merged and published in downstream modules
[ ] For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
[ ] For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
[ ] For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

SaschaWillems commented 4 weeks ago

Could you add some comments to the allocated class? I'm having a hard time understand what it does and why we need it (instead of e.g. simply using a buffer class). Having some comment for the class would make things easier to understand.

asuessenbach commented 3 weeks ago

Could you add some comments to the allocated class?

I think, I have not removed any comment for this class. Maybe @jherico can add some comments, as he introduced that class with #906.

SaschaWillems commented 3 weeks ago

Yeah, that class never was properly commented, so it's up to the original author. As someone who is not doing C++ on a professional basis it's getting harder and harder for me to understand and use the framework, and having proper code comments would really help.

jherico commented 3 weeks ago

I can create a PR improving the comments for the the allocated class and it's children. Should I create it against the main branch or against your branch @asuessenbach ?

asuessenbach commented 3 weeks ago

@jherico Would be great, if you would comment against my branch. But commenting against main would be ok as well, I'd rebase my PR then.

jherico commented 3 weeks ago

@asuessenbach so, the purpose behind breaking up Allocated and AllocatedBase was that AllocatedBase wasn't templated and therefore most of the implementation could be put in the CPP file. This was beneficial when I was working on this code base because modifying ANYTHING in the class triggered a rebuild of basically everything else in the project.

If AllocatedBase is going to require a template argument and therefore have its implementation line in the header, there's no real reason to have it a distinct class from Allocated.

I can try to merge the two classes in the header in my PR, or I can just leave it as is (likely with a note in the AllocatedBase class description that the original reason for the distinction is gone and some future work could be done to merge them.

jherico commented 3 weeks ago

I also see the builder base class has been moved to its own file, but even in that file it should probably still be in the allocated namespace since many of the methods are still very much tied to the VMA. If the intent is to use the builder pattern elsewhere with additional Vulkan types, then it should be broken into multiple classes, one of which should be focused on the VMA allocated resources and remain in the allocated namespace.

asuessenbach commented 2 weeks ago

I can try to merge the two classes in the header in my PR

Would be great, if you would. But that could also be done after this PR has been merged.

I also see the builder base class has been moved to its own file, but even in that file it should probably still be in the allocated namespace since many of the methods are still very much tied to the VMA

If you think, it's worth to move the builder base class into the allocated namespace, I'm fine with it.

KhronosGroup / Vulkan-Samples