diff options
author | Jason Ekstrand <[email protected]> | 2017-07-13 22:50:30 -0700 |
---|---|---|
committer | Jason Ekstrand <[email protected]> | 2017-08-01 11:12:41 -0700 |
commit | d62063ce316a86e3e091a392b42261138524a1a0 (patch) | |
tree | c570506616c45afaa909c489c62fe66f5620f16f /src/glx | |
parent | ddc86c1d0e56e2f16bf37cd378656f459fd15622 (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/glx')
0 files changed, 0 insertions, 0 deletions