search

MightyCreak / mesamatrix

PHP script that parse the text file from the mesa git tree and format it in HTML.
https://mesamatrix.net
GNU Affero General Public License v3.0
125 stars 26 forks source link

There are many missing vendor extensions #231

Open LifeIsStrange opened 2 years ago

LifeIsStrange commented 2 years ago

By vendor extension I mean e.g GLNV 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.

LifeIsStrange commented 2 years ago

@MightyCreak friendly ping @shmerl

shmerl commented 2 years ago

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.

LifeIsStrange commented 2 years ago

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!

shmerl commented 2 years ago

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).

MightyCreak commented 2 years ago

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.

LifeIsStrange commented 2 years ago

@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.

MightyCreak commented 2 years ago

@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.