{"id":13699892,"url":"https://github.com/nvpro-pipeline/VkHLF","last_synced_at":"2025-05-04T17:31:02.809Z","repository":{"id":84673712,"uuid":"78512347","full_name":"nvpro-pipeline/VkHLF","owner":"nvpro-pipeline","description":"Experimental High Level Framework for Vulkan","archived":false,"fork":false,"pushed_at":"2019-01-21T09:04:49.000Z","size":176,"stargazers_count":325,"open_issues_count":3,"forks_count":25,"subscribers_count":29,"default_branch":"master","last_synced_at":"2024-11-13T05:36:19.499Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/nvpro-pipeline.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2017-01-10T08:16:38.000Z","updated_at":"2024-10-03T10:46:23.000Z","dependencies_parsed_at":null,"dependency_job_id":"cdde6b36-3565-4b6b-b810-2e4d0a9a36e7","html_url":"https://github.com/nvpro-pipeline/VkHLF","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nvpro-pipeline%2FVkHLF","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nvpro-pipeline%2FVkHLF/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nvpro-pipeline%2FVkHLF/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nvpro-pipeline%2FVkHLF/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/nvpro-pipeline","download_url":"https://codeload.github.com/nvpro-pipeline/VkHLF/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252371687,"owners_count":21737380,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-02T20:00:45.291Z","updated_at":"2025-05-04T17:31:02.188Z","avatar_url":"https://github.com/nvpro-pipeline.png","language":"C++","funding_links":[],"categories":["C++","Libraries","Graphics"],"sub_categories":[],"readme":"# Vulkan High Level Framework\r\n\r\nVkHLF is an experimental high level abstraction library on top of Vulkan. It adds features like transparent suballocation,\r\nresource tracking on the CPU \u0026 GPU and simplified resource creation while staying as close as possible to the original\r\nVulkan API. In contrast to Vulkan-Hpp, which was carefully designed to be a zero-overhead C++ abstraction for Vulkan, this \r\nlibrary adds significant higher-level functionality. Even so, it has been designed for high-performance, but it can cost\r\nperformance relative to native Vulkan if not employed with the intended usage patterns. \r\n\r\nSince this project is in its early stages and under heavy development expect bugs and interface changes for a while. It should\r\nnot be used for production code yet!\r\n\r\n# Build instructions\r\n\r\n* Clone the repository.\r\n* Execute git submodule update --init --recursive to get the 3rdparty dependencies. Alternatevely unpack glfw3 in 3rdparty/glfw and glslang in 3rdparty/glslang.\r\n* Install Vulkan SDK 1.0.37 or newer.\r\n* Run CMake to generate the makefiles of your choice.\r\n\r\n# VkHLF namespace\r\nAll handles and structs which hold handles have been replicated in the ```vkhlf``` namespace. For the other structs we simply\r\nuse Vulkan-Hpp C++ bindings.\r\n\r\n# VkHLF Reference Counting\r\nVulkan requires the developer to keep the object hierarchy intact all the time. That is, destroying an object\r\nlike the ```vk::Device``` before any of the objects created from it results in undefined behavior. It is also useful for a\r\n```vk::CommandPool``` not to be destroyed if there are any ```vk::CommandBuffer``` objects left created by the same pool.\r\nTo ensure that functionality VkHLF is using ```std::shared_ptr``` and ```std::weak_ptr``` to keep track of the parents or children\r\nof objects, i.e. a ```vk::DeviceMemory``` object is a child object of a ```vk::Device``` object, so it has to keep a ```std::shared_ptr``` to\r\nthe ```vk::Device``` used for creation. This way the ```vk::Device``` stays alive as long as any ```vk::DeviceMemory``` or\r\nother child object exists and the destructor of any object has all the information required to destroy an object.\r\n\r\nAs a consequence to that structs containing handles or arrays of handles are no longer binary compatible with the native\r\nVulkan API. This means that each time such a struct or array is being passed to Vulkan VkHLF has to copy data into\r\na temporary struct or array and pass this one to Vulkan. Luckily this is not as bad as it seems since most of those\r\ncopy operations are only at initialization time, but not during ```vk::CommandBuffer``` construction.\r\n\r\n# VkHLF Device Suballocator\r\nVulkan moves the device suballocation responsibility from the driver to the application. While it is usually possible\r\nto do thousands of buffer allocations in OpenGL without any failure it is likely to get a failure on Vulkan when\r\ndoing one device allocation for each VkBuffer due to OS limitations. Thus application developers now have to implement\r\ndevice suballocators and keep track of the device/offset pair in the application. To simplify application development\r\nVkHLF provides the vkhlf::DeviceSuballocator interface which can be used for suballocation. The suballocator returns\r\n```vkhlf::DeviceMemory``` objects which always store the ```offset``` in addition to the ```vk::DeviceMemory``` object.\r\nEach location which is using ```vkhlf::DeviceMemory``` will use the pair of ```vk::DeviceMemory``` and ```offset``` \r\ncompletely transparent to the developer.\r\n\r\n# VkHLF GPU Resource Tracking\r\nVulkan does not have any automatic resource tracking. It is possible to change or delete resources which are currently\r\nin use on the GPU which will most likely result in strange behaviour, or worst case in an application or system crash.\r\n\r\nIt is essential to ensure that resources do not get destroyed while they are still in use by the GPU. Thus we have implemented\r\na ```vkhlf::ResourceTracker``` interface used by ```vkhlf::CommandBuffer``` to track all resources used to build up the \r\ncommand buffer.\r\n\r\nIn its current state resource tracking is an expensive operation if it is done on the fly while building up command buffers. \r\nDevelopers should try to avoid this cost by using one of the following techniques:\r\n* If possible, reuse command buffers over multiple frames.\r\n* Otherwise, reuse the tracking data. If it is known that the set of resources used by a command buffer does not change over multiple\r\nframes one can implement a version of the resource tracking interface which takes the tracking information of another resource tracker\r\nto keep the resources alive. In release mode this tracker does nothing, in debug mode it should validate that all used resources are\r\nalready tracked.\r\n\r\n\r\n# Providing Pull Requests\r\nNVIDIA is happy to review and consider pull requests for merging into the main tree of the nvpro-pipeline for bug fixes and features. Before providing a pull request to NVIDIA, please note the following:\r\n\r\n* A pull request provided to this repo by a developer constitutes permission from the developer for NVIDIA to merge the provided changes or any NVIDIA modified version of these changes to the repo. NVIDIA may remove or change the code at any time and in any way deemed appropriate.\r\n* Not all pull requests can be or will be accepted. NVIDIA will close pull requests that it does not intend to merge.\r\n* The modified files and any new files must include the unmodified NVIDIA copyright header seen at the top of all shipping files.\r\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnvpro-pipeline%2FVkHLF","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnvpro-pipeline%2FVkHLF","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnvpro-pipeline%2FVkHLF/lists"}