No available machine processable glsl specification

[pdaniell-nv]

This comes from david.morgan@kdab.com in bugzilla 1283: https://www.khronos.org/bugzilla/show_bug.cgi?id=1283

The specification for the GLSL language is in a good format for human-reading but can be problematic for computer based reading. If the GLSL specification was also publish in an XML-like format (https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml) similar to the OpenGL specification then it can be better used for applications that benefit from knowledge of GLSL feature-sets per version, such as interactive editors.

[oddhack]

It's not clear what is being asked for here. If something like gl.xml but specifying the GLSL built-in functions is required, we haven't needed that for our own purposes yet AFAIK, although I think the SPIR-V folks have done something similar with their Opcodes. Maybe John Kessenich could chime in here? In any event this feels like a low priority for us, but an opportunity for contributions by the developer community if it's something they'd find useful.

[johnkslang]

Agree it would be desirable to have much of the content tabled in a computer readable form, like JSON as we do with SPIR-V. Translating the spec. to asciidoc instead of using LibreOffice would also lower the barrier, and that's a more likely first step to enable automatic processing.

[3b]

Full information on the valid combinations of input types and corresponding output type for glsl functions, operators, and constructors would be nice for doing type inference.

It would also be nice to have minimum GLSL versions and/or extensions for types, functions, etc. to allow automatically detecting or checking what is required by a particular shader.

Machine readable descriptions of the std140/std430 packing rules might also be nice, not sure if that should be included as extra info on types in a glsl spec or as something separate though

[johnkslang]

It also occurs to me that glslang creates version specific strings holding all the built-in functions, in Initialize.cpp. Executing this and printing the resulting per-stage per-version strings shows a parsable form.

[oddhack]

@3b FWIW, the glsl reference pages do have version compatibility tables for each function they document. I guess that information could be extracted from the Docbook sources but ideally the ref pages would be driven off an external database as was requested here, not the other way around :-)

[johnkslang]

Note that the specification is now published as asciidoctor, and hence much more machine readable.

Machine readable descriptions of the std140/std430 packing rules might also be nice

That's basically expressed in the API specification, as a recursive algorithm. Glslang implements it, in reasonably. straightforward and isolated way. I think it's hard to get something other than English recursive definition and direct C++ implementation of that, which would then be even better to deal with. At any rate, that's from the API spec, not the language spec.

It would also be nice to have minimum GLSL versions and/or extensions for types, functions, etc. to allow automatically detecting or checking what is required by a particular shader.

That's really a collation problem across specs. It's not about the from the spec. is printed in. I'd consider that a separate activity, not a spec. change.

Full information on the valid combinations of input types and corresponding output type for glsl functions, operators, and constructors would be nice for doing type inference.

Built-in functions are parseable now; this could theoretically be done. Texturing is hard, but as above, there is at least one public source algorithm that generates the correct set programmatically, and that might be a better place to start (in glslang, which is a reference front end, as far as this question is concerned, so should be on equal footing for the prototype generation with the spec itself).

Given this state of things, I suggest we can close this issue.