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
Since it is not guaranteed by the standard for a graphics queue to support presentation and vkb::QueueType::graphics is used in tutorials for combined purposes of both rendering and presentation, for convenience reasons I'm suggesting to add a vkb::QueueType::graphics_and_present type that would perform an additional check under the hood and ensure its support.
The text was updated successfully, but these errors were encountered:
AnonN10
changed the title
Support graphics+present queue type
Add graphics+present queue type
Nov 17, 2021
I have a feeling it is pretty weird if every combination had it's own enum, apart from complicated naming and possible confusion.
I'd say defining operators on vkb::QueueType to OR the values together should be the better solution here. It would be much nicer from a readability perspective and would require the same under the hood changes anyway. If you agree, I'd be happy to open a PR.
enumclassQueueType : uin32_t {}; // You know what goes here.inline vkb::QueueType operator|(vkb::QueueType a, vkb::QueueType b) {
returnstatic_cast<vkb::QueueType>(
static_cast<uint32_t>(a) | static_cast<uint32_t>(b));
}
Since it is not guaranteed by the standard for a graphics queue to support presentation and
vkb::QueueType::graphics
is used in tutorials for combined purposes of both rendering and presentation, for convenience reasons I'm suggesting to add avkb::QueueType::graphics_and_present
type that would perform an additional check under the hood and ensure its support.The text was updated successfully, but these errors were encountered: