summaryrefslogtreecommitdiffstats
path: root/src/compiler/nir/nir_opt_algebraic.py
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2017-07-13 22:50:30 -0700
committerJason Ekstrand <[email protected]>2017-08-01 11:12:41 -0700
commitd62063ce316a86e3e091a392b42261138524a1a0 (patch)
treec570506616c45afaa909c489c62fe66f5620f16f /src/compiler/nir/nir_opt_algebraic.py
parentddc86c1d0e56e2f16bf37cd378656f459fd15622 (diff)
anv: Autogenerate extension query and lookup
As time goes on, extension advertising is going to get more complex. Today, we either implement an extension or we don't. However, in the future, whether or not we advertise an extension will depend on kernel or hardware features. This commit introduces a python codegen framework that generates the anv_EnumerateFooExtensionProperties functions as well as a pair of anv_foo_extension_supported functions for querying for the support of a given extension string. Each extension has an "enable" predicate that is any valid C expression. For device extensions, the physical device is available as "device" so the expression could be something such as "device->has_kernel_feature". For instance extensions, the only option is VK_USE_PLATFORM defines. This mechanism also means that we have a single one-line-per-entry table for all extension declarations instead of the two tables we had in anv_device.c and the one we had in anv_entrypoints_gen.py. The Python code is smart and uses the XML to determine whether an extension is an instance extension or device extension. Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
Diffstat (limited to 'src/compiler/nir/nir_opt_algebraic.py')
0 files changed, 0 insertions, 0 deletions