WIP: Refactor Resource Cache

Open tomadamatkinson opened this issue 2 years ago • 0 comments

Description

The resource cache is an easy to use area of the framework to lazily create resources. The resource cache is also one of the hardest to understand when debugging or digging through its code. The issue with the cache is that it holds the complexity needed for the hpp_pipeline_cache and pipeline_cache samples.

This PR moves this functionality from the framework to the sample. The cache code is easier to understand and the specialisation for pipeline caching is now local to the sample and so easier for users of the sample!

I found that the resource cache itself has been a hurdle when trying to make larger changes. This is likely due to its complexity and that the current implementation is not super readable. In order to fix some of this, i implemented some nice to have container types in core/containers/* (with tests). Removing the record/replay made the cache code easier to understand. This PR is a useful precursor to #657 but is not a blocker

General Checklist:

Please ensure the following points are checked:

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

Note: The Samples CI runs a number of checks including:

[ ] 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

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 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

Nov 30 '23 00:11 tomadamatkinson