1. 16 Aug, 2017 2 commits
  2. 02 Aug, 2017 5 commits
  3. 01 Aug, 2017 2 commits
    • Jason Ekstrand's avatar
      anv: Autogenerate extension query and lookup · d62063ce
      Jason Ekstrand authored
      
      
      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's avatarEmil Velikov <emil.velikov@collabora.com>
      Reviewed-by: Lionel Landwerlin's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      d62063ce
    • Jason Ekstrand's avatar
      anv: Add a new centralized extensions file · ddc86c1d
      Jason Ekstrand authored
      
      
      This will allow us to keep everything in one place when it comes to
      declaring what extensions are supported.
      
      Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      Reviewed-by: Lionel Landwerlin's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      ddc86c1d