You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, vk-bootstrap supports preferring a single device type to others, but it is unclear if there is any selection priority beyond that. I'd like to propose that an API is added such that it is possible to define physical device selection priority.
Possible APIs:
Option One: This takes a variadic template that would be restricted to only take vkb::PreferredDeviceType values. The order that the options are provided in is the order in which physical devices would be preferred.
Option Two: This option utilizes a struct to abstract a chain of responsibility, in which earlier GPU types in the chain take selection priority. It could look something like:
The downside to this approach is that it uses dynamically allocated memory in the vector as opposed to the variadic template argument approach. However, I think this is a relatively minor drawback, as this shouldn't be called frequently (most likely once on startup) and vectors are used elsewhere in the code.
As an aside for documentation, I think the preference order should be documented somewhere.
The text was updated successfully, but these errors were encountered:
Essentially, this adds sorting to the filtering capabilities of vk-bootstrap. I am against a general sorting mechanism, as there are a LOT of features/extensions/capabilities in vulkan, and sorting on all of them would take forever. However adding a simple "I want discrete first, integrated second, CPU third" is 99% of what sorting would be used for, so I have no issue with it.
I'd rather go with a much simpler API of just function calls on the builder + passing in a vector of the PreferredDeviceType to establish the order.
What I'm thinking:
// Sort physical devices by their device type, using the provided order. If a type isn't specified, it is put at the end.set_device_type_sorting_order(std::vector<PreferredDeviceType> order);
// Sort physical devices in the order provided by successive calls to this function. // The first call to `add_next_device_type_preference` makes that type be first in the sorting order, the second call makes that type second in the sorting order, etc etc // If `prefer_gpu_device_type` was called, the device type given to it is always first in the sort order. Any calls to `add_next_device_type_preference` will appear afterwards.// if `set_device_type_sorting_order` was called, it replaces any order set by this function.add_next_device_type_preference(PreferredDeviceType type);
// Sort physical devices in the default order: Discrete, Integrated, CPU, virtual, other// Resets the sorting order back to the default order.use_default_device_type_sorting_order();
So the changes include adding those 3 functions, as well as adding sorting to the list of physical devices in that order. This library already defaults to making the discrete GPU the 'first' choice, but it'd be good to sort the list by default.
Currently, vk-bootstrap supports preferring a single device type to others, but it is unclear if there is any selection priority beyond that. I'd like to propose that an API is added such that it is possible to define physical device selection priority.
Possible APIs:
Option One: This takes a variadic template that would be restricted to only take
vkb::PreferredDeviceType
values. The order that the options are provided in is the order in which physical devices would be preferred.Option Two: This option utilizes a struct to abstract a chain of responsibility, in which earlier GPU types in the chain take selection priority. It could look something like:
The downside to this approach is that it uses dynamically allocated memory in the vector as opposed to the variadic template argument approach. However, I think this is a relatively minor drawback, as this shouldn't be called frequently (most likely once on startup) and vectors are used elsewhere in the code.
As an aside for documentation, I think the preference order should be documented somewhere.
The text was updated successfully, but these errors were encountered: