Task Brief
Currently, vk::pipeline manage their own underlying VkPipeline handles. In the existing APIs, pipeline instance handles are coupled with binding operations, require an explicit binding point parameter.
The source for removing the explicit binding point parameter can be viewed here:
|
pipeline_bind_point::graphics) { |
API Changes
Currently, the implementation couples the pipeline are coupled by command buffer and requires explicit binding point specification:
m_graphics_pipeline.bind(m_current_command, vk::pipeline_bind_point::graphics);
The newer API shifts to having these executed context to the command buffer and deducing the binding point based on a dedicated API with the specific binding point:
m_current_command.bind_graphics_pipeline(m_graphics_pipeline);
Task Completion Expectation
vk::pipeline and other VkPipelinewrappers will no longer expose a bind API requiring explicit binding points.vk::command_buffer will be responsible for handling bind operations and dedicated APIs for explicitly binding specific pipelines.
Task Brief
Currently,
vk::pipelinemanage their own underlyingVkPipelinehandles. In the existing APIs, pipeline instance handles are coupled with binding operations, require an explicit binding point parameter.The source for removing the explicit binding point parameter can be viewed here:
vulkan-cpp/vulkan-cpp/pipeline.cppm
Line 476 in 36fab78
API Changes
Currently, the implementation couples the pipeline are coupled by command buffer and requires explicit binding point specification:
The newer API shifts to having these executed context to the command buffer and deducing the binding point based on a dedicated API with the specific binding point:
Task Completion Expectation
vk::pipelineand otherVkPipelinewrappers will no longer expose abindAPI requiring explicit binding points.vk::command_bufferwill be responsible for handling bind operations and dedicated APIs for explicitly binding specific pipelines.