Adding Jason and Ian here for their opinions.

Quoting Alejandro Piñeiro (2018-03-12 01:31:02)
> 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
> >>
> > 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?
> BR
> [1]
> [2]
> [3]

Attachment: signature.asc
Description: signature

mesa-dev mailing list

Reply via email to