-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sorting in Vulkan any extension not perfect #291
Comments
Can you give some examples? From what I see it follows the order in features.txt |
in Extensions that are not part of any Vulkan Version. VK_Google is before VK_AMD mostly VK_KHR are at the begin of the table. so it is partly sorted, and features are added at the end without new sorting. |
Yes, it's kinda intentional actually. As you can see here, the extensions aren't sorted in the original features.txt file and Mesamatrix simply follows the same order. I could sort the extensions alphabetically, but I don't know how much this order is important in the original file... |
Khronos with KHR is first and EXT is second priority for the Mesa Guys in development. |
I'd rather the source being changed upstream instead of arbitrarily change the order in Mesamatrix. I'm not expert enough in 3d drivers programming to know which extensions should be higher up in the list, also, it could change without me knowing, and also it's no regular sorting (KHR, then EXT, then the rest). I think it would be better to open an issue in mesa and ask the devs if they would be willing to re-order the extensions in features.txt (or if they have a preferred sorting order that they'd like to see in Mesamatrix) |
With Vulkan 1.4 some „sorting“ is done by transfer of some features to table 1.4. |
Sorting in Vulkan any extension not perfect
Khronos first with khr ist ok.
EXT is here next.
But then there is some chaos.
sorting in OpenGL extensions is alphabetically.
The text was updated successfully, but these errors were encountered: