There are many missing vendor extensions
Opened this issue · 7 comments
By vendor extension I mean e.g GL_NV_ or GL_AMD
In mesamatrix, there is currently:
18 VK_AMD extensions and only one VK_NV one..
Mesa matrix only has 2 GL_NV extensions and zero GL_AMD extensions..
(of course I am excluding the ARB extensions, which are former vendor extensions).
GL and VK extensions push the frontier of computer science and what is possible to do efficiently with GPUs. That is why including vendor extensions in mesamatrix would be useful as it would make them a bit more discoverable and therefore enable new software applications.
The best example I know of is NV_path_rendering
https://developer.nvidia.com/nv-path-rendering
But there are probably interesting other ones I never heard about.
BTW thanks for this amazing project I've been following it since years! It's been beautiful to see the matrix become greener as time passed.
@MightyCreak friendly ping
@shmerl
I think it would depend on whether Mesa developers even plan to ever implementing some of those. From what I understood, it has to be in features.txt to be displayed. And if they don't even have plans for them, I doubt they'd care about adding them to that list.
But those they do plan or even already implemented in some drivers totally should be listed.
For the record:
https://www.khronos.org/registry/OpenGL/index_gl.php
The OpenGL index registry shows:
38 GL_AMD extensions and 141 (!) GL_NV extensions.
Weirdly there are 18 GL_MESA extensions o.O
Mesamatrix is meant to be a tracker toward progress into implementing all GL extensions.
As such, the repository could be enhanced by feeding it's list on additional sources than the feature.txt, e.g by downloading/scrapping the official OpenGL registry list.
So many of those extensions are useful and intriguing!
Yeah, for that you need some standard way of getting that list I suppose. May be you can propose to Khronos to host some txt list as well (or whatever easily parseable format).
I'd like to repeat the first two paragraphs in mesamatrix.net:
This page is a graphical representation of the text file docs/features.txt from the Mesa repository.
Although this text file is updated by the Mesa developers themselves, it might not contain an exhaustive list of all the drivers features and subtleties. So, for more information, it is advised to look at the source code, or ask the developers on their mailing-list.
I don't have much control over the features.txt file, Mesamatrix is simply a graphical representation of this file.
Of course a perfect Vulkan/OpenGL/OpenGLES/OpenCL tracker, with machines that would test all the drivers would be a lot better, but it would take a huge amount of time and maintenance to have that working. So the best way to go from there is still to ask the devs to add the extensions that you feel worthy of being listed in features.txt.
@MightyCreak that seems to be a false dilemma,
Sure the ideal tracker would do automated tests of drivers but it's the approach with the highest maintenance work.
Asking for upstream mesa to add the extension on the features.txt is indeed the recommended practice, but it is insufficient, we are very far from covering most vendor extensions with that approach.
The third way would be to augment mesamatrix by parsing an additional file, one that would exhaustively contains GL extensions.
By default, the extensions found in the khronos file and not present in features.txt (through a diff) would be appended at the end of each matrix. And the columns would have a default value for each driver of either unimplemented or unknown.
As such it would dramatically improve GL extensions coverage. It might even motivate some driver developers to actually implement them by giving them more visibility.
Note BTW that vendor extensions are not necessarily implemented only by one vendor, for example VK_NV_compute_shader_derivatives is supported by both AMD and Intel drivers.
@LifeIsStrange I don't think adding more extensions to Mesamatrix will all of a sudden motivate Mesa devs to add more extensions in the features.txt file.
I don't know why they didn't list all the extensions in features.txt but they are the experts and I trust they have a good reason for that (even if it's as simple as not having enough time to track them all).
I don't think it is Mesamatrix's place to tell the Mesa devs which extensions should be tracked or not. Mesamatrix's "source of truth" is features.txt and if this file changes, Mesamatrix will change accordingly. Mesamatrix is but a mere graphical representation of features.txt.
That said, I am not entirely closed to the idea. I just don't want to appear cavalier to the Mesa devs and their impressive work. So I think that the right of doing that is to discuss with the Mesa devs to see if they would agree to add more extensions to features.txt, or if you want to do it, you can create a script that will gather all the Vulkan/OpenGL/OpenGLES/OpenCL extensions from the respective official websites resources, and generate a new text file from it and update the extensions statuses thanks to features.txt.