Skip to content

Manager: forward optional VkPhysicalDeviceFeatures2 pNext chain to VkDeviceCreateInfo#457

Open
mgajda wants to merge 1 commit intoKomputeProject:masterfrom
mgajda:atomic-float-features
Open

Manager: forward optional VkPhysicalDeviceFeatures2 pNext chain to VkDeviceCreateInfo#457
mgajda wants to merge 1 commit intoKomputeProject:masterfrom
mgajda:atomic-float-features

Conversation

@mgajda
Copy link
Copy Markdown

@mgajda mgajda commented Apr 20, 2026

Summary

Extends kp::Manager's configured constructor (and the internal
createDevice) with an optional const void* desiredFeaturesChain
parameter. When non-null it is forwarded to
VkDeviceCreateInfo::pNext, enabling callers to opt in to
extension-gated features such as
VkPhysicalDeviceShaderAtomicFloatFeaturesEXT::shaderBufferFloat32AtomicAdd
or any other feature struct chain the application needs.

Without this, even if VK_EXT_shader_atomic_float is passed through
the existing desiredExtensions list, pipeline creation rejects
SPIR-V that uses OpAtomicFAdd on storage buffers because the
corresponding feature bit is never enabled.

The parameter defaults to nullptr, so all existing call sites
compile and behave exactly as before. Ownership remains with the
caller — Manager only reads the pointer during VkDeviceCreateInfo
configuration and does not store it.

Motivation

Kompute currently requires
subclassing Manager or reaching directly into the shared
vk::Device to reconfigure it, which defeats the point of the
Manager abstraction. This small hook lets those workloads stay on
the stock Manager.

Notes

Happy to add a small example under examples/ showing the feature-chain
idiom if that's desired — didn't include one here to keep the diff
minimal and reviewable. Also happy to narrow the API to a typed
vk::PhysicalDeviceFeatures2* if the maintainers prefer that over a
raw const void*; I chose the latter so callers can supply any
pNext-chainable struct without Manager having to know about it.

@mgajda
Copy link
Copy Markdown
Author

mgajda commented Apr 20, 2026

Implements fix for issue #458 (queue-family selection). Also fixes queue priority starvation issue mentioned in #460.

@mgajda
Copy link
Copy Markdown
Author

mgajda commented Apr 21, 2026

Superseded by #462 — same fix in 16 lines instead of 92, no API change.

@mgajda mgajda closed this Apr 21, 2026
@mgajda
Copy link
Copy Markdown
Author

mgajda commented Apr 21, 2026

Sorry — closed by mistake, this PR is about forwarding the features2 pNext chain, not the queue-family fix. Reopening.

@mgajda mgajda reopened this Apr 21, 2026
@mgajda mgajda force-pushed the atomic-float-features branch from 4298b7d to 7064d72 Compare April 21, 2026 12:26
Add an optional `desiredFeaturesChain` pointer to `Manager`'s
configured constructor and `createDevice`.  When non-null it is
forwarded to `VkDeviceCreateInfo::pNext`, so callers can enable
extension-gated features such as
`VkPhysicalDeviceShaderAtomicFloatFeaturesEXT::shaderBufferFloat32AtomicAdd`
without bypassing Manager.

Backward compatible: the new parameter defaults to `nullptr`, so
existing call sites are unaffected.  Caller owns the struct(s) and
must keep them alive for the duration of the Manager constructor.
@mgajda mgajda force-pushed the atomic-float-features branch from 7064d72 to 4c760da Compare April 21, 2026 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant