On 11/03/18 18:08, Dylan Baker wrote:
> Quoting Alejandro Piñeiro (2018-03-08 07:00:16)
>> Ideally this should be generated somehow. One option would be gather
>> all the extension dependencies listed on the core grammar, but there
>> would be the possibility of not including some of the extensions.
>> Note that spirv-tools is doing it just slightly better, as it has a
>> hardcoded list of extensions manually took from the registry, that
>> they parse to get the enum and the to_string method (see
>> generate_grammar_tables.py).
> If there were extensions not in the core grammar that we wanted to or needed 
> to
> support, are they available in a different format that is still machine
> readable?

Taking a look to the last version of the core grammar [1], it seems that
all the extensions, but SPV_AMD_gcn_shader are now part of the core. For
the latter, I found a json file as part of spirv-tools [3]

But when I wrote this patch, some of the extensions were not part of the
core, and as far as I saw, they were just listed on the registry [2]. I
was not able to find a individual json core grammar for some extensions
then. On the commit message I mention generate_grammar_tables. From a
comment there:

 #Extensions to recognize, but which don't necessarily come from the SPIR-V
 #core grammar. Get this list from the SPIR-V registery web page.

So right now one option would be create that list from the core grammar
plus the grammar amd one. But what would happen if a new extension is
defined without a grammar file? Would we just write one ourselves? Would
we ask khronos (or who defined the spec) to provide one?


[2] https://www.khronos.org/registry/spir-v/extensions/KHR/

Attachment: signature.asc
Description: OpenPGP digital signature

mesa-dev mailing list

Reply via email to