.gitlab-ci/container/build-crosvm.sh

@@ -2,13 +2,18 @@
 
 set -ex
 
-CROSVM_VERSION=f904b0ee258554bca9fed1b633b79e6d96003cf0
-git clone --single-branch -b for-mesa-ci --no-checkout https://gitlab.freedesktop.org/tintou/crosvm.git /platform/crosvm
+SCRIPT_DIR="$(pwd)"
+
+CROSVM_VERSION=c7cd0e0114c8363b884ba56d8e12adee718dcc93
+git clone --single-branch -b main --no-checkout https://chromium.googlesource.com/chromiumos/platform/crosvm /platform/crosvm
 pushd /platform/crosvm
 git checkout "$CROSVM_VERSION"
 git submodule update --init
+# Apply all crosvm patches for Mesa CI
+cat "$SCRIPT_DIR"/.gitlab-ci/container/build-crosvm_*.patch |
+    patch -p1
 
-VIRGLRENDERER_VERSION=45070fae92d25a726d9ce10fc22c1f92270ecd35
+VIRGLRENDERER_VERSION=0564c9a0c2f584e004a7d4864aee3b8ec9692105
 rm -rf third_party/virglrenderer
 git clone --single-branch -b master --no-checkout https://gitlab.freedesktop.org/virgl/virglrenderer.git third_party/virglrenderer
 pushd third_party/virglrenderer

.gitlab-ci/container/build-crosvm_no-syslog.patch

+From 3c57ec558bccc67fd53363c23deea20646be5c47 Mon Sep 17 00:00:00 2001
+From: Tomeu Vizoso <tomeu.vizoso@collabora.com>
+Date: Wed, 17 Nov 2021 10:18:04 +0100
+Subject: [PATCH] Hack syslog out
+
+It's causing stability problems when running several Crosvm instances in
+parallel.
+
+Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
+---
+ base/src/unix/linux/syslog.rs       | 2 +-
+ common/sys_util/src/linux/syslog.rs | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/base/src/unix/linux/syslog.rs b/base/src/unix/linux/syslog.rs
+index 05972a3a..f0db3781 100644
+--- a/base/src/unix/linux/syslog.rs
++++ b/base/src/unix/linux/syslog.rs
+@@ -35,7 +35,7 @@ pub struct PlatformSyslog {
+ impl Syslog for PlatformSyslog {
+     fn new() -> Result<Self, Error> {
+         Ok(Self {
+-            socket: Some(openlog_and_get_socket()?),
++            socket: None,
+         })
+     }
+ 
+diff --git a/common/sys_util/src/linux/syslog.rs b/common/sys_util/src/linux/syslog.rs
+index 05972a3a..f0db3781 100644
+--- a/common/sys_util/src/linux/syslog.rs
++++ b/common/sys_util/src/linux/syslog.rs
+@@ -35,7 +35,7 @@ pub struct PlatformSyslog {
+ impl Syslog for PlatformSyslog {
+     fn new() -> Result<Self, Error> {
+         Ok(Self {
+-            socket: Some(openlog_and_get_socket()?),
++            socket: None,
+         })
+     }
+ 
+-- 
+2.25.1
+

.gitlab-ci/container/build-skqp.sh

@@ -64,7 +64,7 @@ download_skia_source
 pushd "${SKIA_DIR}"
 
 # Apply all skqp patches for Mesa CI
-cat "${SKQP_PATCH_DIR}"/*.patch |
+cat "${SKQP_PATCH_DIR}"/build-skqp_*.patch |
     patch -p1
 
 # Fetch some needed build tools needed to build skia/skqp.

.gitlab-ci/image-tags.yml

@@ -8,11 +8,11 @@ variables:
    DEBIAN_X86_TEST_BASE_IMAGE: "debian/x86_test-base"
 
    DEBIAN_X86_TEST_IMAGE_PATH: "debian/x86_test-gl"
-   DEBIAN_X86_TEST_GL_TAG: "2022-04-05-deqp-runner"
+   DEBIAN_X86_TEST_GL_TAG: "2022-04-07-virgl-crosvm"
    DEBIAN_X86_TEST_VK_TAG: "2022-04-05-deqp-runner"
 
    FEDORA_X86_BUILD_TAG: "2022-03-18-spirv-tools-5"
-   KERNEL_ROOTFS_TAG: "2022-04-05-deqp-runner"
+   KERNEL_ROOTFS_TAG: "2022-04-07-prefix-skqp"
 
    WINDOWS_X64_BUILD_PATH: "windows/x64_build"
    WINDOWS_X64_BUILD_TAG: "2022-20-02-base_split"

.gitlab-ci/lava/lava_job_submitter.py

@@ -74,7 +74,7 @@ def generate_lava_yaml(args):
         'visibility': { 'group': [ args.visibility_group ] },
         'priority': 75,
         'context': {
-            'extra_nfsroot_args': ' init=/init rootwait'
+            'extra_nfsroot_args': ' init=/init rootwait usbcore.quirks=0bda:8153:k'
         },
         'timeouts': {
             'job': {

docs/doxygen-wrapper.py

@@ -58,6 +58,7 @@ EXPAND_ONLY_PREDEF = YES
 # Defines required to keep doxygen from tripping on our attribute macros
 PREDEFINED  = PACKED=
 PREDEFINED += ATTRIBUTE_CONST=
+PREDEFINED += MUST_CHECK=
 """)
 
 def run_doxygen(output_path, input_paths=[]):

docs/envvars.rst

@@ -226,6 +226,19 @@ the :doc:`Xlib software driver page <xlibdriver>` for details.
 :envvar:`MESA_GLX_ALPHA_BITS`
    specifies default number of bits for alpha channel.
 
+Mesa WGL driver environment variables
+-------------------------------------
+
+The following are only applicable to the Mesa WGL driver, which is in use
+on Windows.
+
+:envvar:`WGL_FORCE_MSAA`
+   if set to a positive value, specifies the number of MSAA samples to
+   force when choosing the display configuration.
+:envvar:`WGL_DISABLE_ERROR_DIALOGS`
+   if set to 1, true or yes, disables Win32 error dialogs. Useful for
+   automated test-runs.
+
 Intel driver environment variables
 ----------------------------------------------------
 

docs/features.txt

@@ -522,7 +522,7 @@ Khronos extensions that are not part of any Vulkan version:
   VK_KHR_surface                                        DONE (anv, lvp, radv, tu, v3dv, vn)
   VK_KHR_surface_protected_capabilities                 DONE (anv, lvp, radv, v3dv, vn)
   VK_KHR_swapchain                                      DONE (anv, lvp, radv, tu, v3dv, vn)
-  VK_KHR_swapchain_mutable_format                       DONE (anv, radv, v3dv, vn)
+  VK_KHR_swapchain_mutable_format                       DONE (anv, lvp, radv, v3dv, vn)
   VK_KHR_wayland_surface                                DONE (anv, lvp, radv, tu, v3dv, vn)
   VK_KHR_workgroup_memory_explicit_layout               DONE (anv, radv)
   VK_KHR_win32_keyed_mutex                              not started
@@ -560,7 +560,7 @@ Khronos extensions that are not part of any Vulkan version:
   VK_EXT_physical_device_drm                            DONE (anv, radv, tu, v3dv)
   VK_EXT_post_depth_coverage                            DONE (anv/gfx10+, lvp, radv/gfx10+)
   VK_EXT_primitive_topology_list_restart                DONE (anv, lvp, radv, tu)
-  VK_EXT_primitives_generated_query                     DONE (lvp)
+  VK_EXT_primitives_generated_query                     DONE (lvp, tu)
   VK_EXT_provoking_vertex                               DONE (anv, lvp, radv, tu, v3dv)
   VK_EXT_queue_family_foreign                           DONE (anv, radv, vn)
   VK_EXT_robustness2                                    DONE (anv, radv, tu)

docs/relnotes/new_features.txt

@@ -5,3 +5,4 @@ Vulkan 1.3 support on lavapipe
 VK_EXT_graphics_pipeline_library on lavapipe
 VK_EXT_primitives_generated_query on lavapipe
 VK_EXT_image_2d_view_of_3d on ANV and lavapipe
+VK_KHR_swapchain_mutable_format on lavapipe

docs/vulkan/base-objs.rst

+Base object structs
+===================
+
+The Vulkan runtime code provides a set of base object structs which must be
+used if you want your driver to take advantage of any of the runtime code.
+There are other base structs for various things which are not covered here
+but those are optional.  The ones covered here are the bare minimum set
+which form the core of the Vulkan runtime code:
+
+.. contents::
+   :local:
+
+As one might expect, :cpp:struct:`vk_instance` is the required base struct
+for implementing ``VkInstance``, :cpp:struct:`vk_physical_device` is
+required for ``VkPhysicalDevice``, and :cpp:struct:`vk_device` for
+``VkDevice``.  Everything else must derive from
+:cpp:struct:`vk_vk_objet_base` or from some struct that derives from
+:cpp:struct:`vk_vk_objet_base`.
+
+
+vk_object_base
+--------------
+
+The root base struct for all Vulkan objects is
+:cpp:struct:`vk_object_base`.  Every object exposed to the client through
+the Vulkan API *must* inherit from :cpp:struct:`vk_object_base` by having a
+:cpp:struct:`vk_object_base` or some struct that inherits from
+:cpp:struct:`vk_object_base` as the driver struct's first member.  Even
+though we have `container_of()` and use it liberally, the
+:cpp:struct:`vk_object_base` should be the first member as there are a few
+places, particularly in the logging framework, where we use void pointers
+to avoid casting and this only works if the address of the driver struct is
+the same as the address of the :cpp:struct:`vk_object_base`.
+
+The standard pattern for defining a Vulkan object inside a driver looks
+something like this:
+
+.. code-block:: c
+
+   struct drv_sampler {
+      struct vk_object_base base;
+
+      /* Driver fields */
+   };
+
+   VK_DEFINE_NONDISP_HANDLE_CASTS(drv_sampler, base, VkSampler,
+                                  VK_OBJECT_TYPE_SAMPLER);
+
+Then, to the object in a Vulkan entrypoint,
+
+.. code-block:: c
+
+   VKAPI_ATTR void VKAPI_CALL drv_DestroySampler(
+       VkDevice                                    _device,
+       VkSampler                                   _sampler,
+       const VkAllocationCallbacks*                pAllocator)
+   {
+      VK_FROM_HANDLE(drv_device, device, _device);
+      VK_FROM_HANDLE(drv_sampler, sampler, _sampler);
+
+      if (!sampler)
+         return;
+
+      /* Tear down the sampler */
+
+      vk_object_free(&device->vk, pAllocator, sampler);
+   }
+
+The :cpp:any:`VK_DEFINE_NONDISP_HANDLE_CASTS()` macro defines a set of
+type-safe cast functions called ``drv_sampler_from_handle()`` and
+``drv_sampler_to_handle()`` which cast a :cpp:type:`VkSampler` to and from a
+``struct drv_sampler *``.  Because compile-time type checking with Vulkan
+handle types doesn't always work in C, the ``_from_handle()`` helper uses the
+provided :cpp:type:`VkObjectType` to assert at runtime that the provided
+handle is the correct type of object.  Both cast helpers properly handle
+``NULL`` and ``VK_NULL_HANDLE`` as inputs.  The :cpp:any:`VK_FROM_HANDLE()`
+macro provides a convenient way to declare a ``drv_foo`` pointer and
+initialize it from a ``VkFoo`` handle in one smooth motion.
+
+.. doxygenstruct:: vk_object_base
+   :members:
+
+.. doxygenfunction:: vk_object_base_init
+.. doxygenfunction:: vk_object_base_finish
+
+.. doxygendefine:: VK_DEFINE_HANDLE_CASTS
+
+.. doxygendefine:: VK_DEFINE_NONDISP_HANDLE_CASTS
+
+.. doxygendefine:: VK_FROM_HANDLE
+
+
+vk_instance
+-----------
+
+.. doxygenstruct:: vk_instance
+   :members:
+
+.. doxygenfunction:: vk_instance_init
+.. doxygenfunction:: vk_instance_finish
+
+Once a driver has a :cpp:struct:`vk_instance`, implementing all the various
+instance-level ``vkGet*ProcAddr()`` entrypoints is trivial:
+
+.. code-block:: c
+
+   VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL
+   drv_GetInstanceProcAddr(VkInstance _instance,
+                           const char *pName)
+   {
+      VK_FROM_HANDLE(vk_instance, instance, _instance);
+      return vk_instance_get_proc_addr(instance,
+                                       &drv_instance_entrypoints,
+                                       pName);
+   }
+
+   PUBLIC VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL
+   vk_icdGetInstanceProcAddr(VkInstance instance,
+                             const char *pName);
+
+   PUBLIC VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL
+   vk_icdGetInstanceProcAddr(VkInstance instance,
+                             const char *pName)
+   {
+      return drv_GetInstanceProcAddr(instance, pName);
+   }
+
+   PUBLIC VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL
+   vk_icdGetPhysicalDeviceProcAddr(VkInstance  _instance,
+                                   const char* pName);
+
+   PUBLIC VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL
+   vk_icdGetPhysicalDeviceProcAddr(VkInstance  _instance,
+                                   const char* pName)
+   {
+      VK_FROM_HANDLE(vk_instance, instance, _instance);
+      return vk_instance_get_physical_device_proc_addr(instance, pName);
+   }
+
+The prototypes for the ``vk_icd*`` versions are needed because those are not
+actually defined in the Vulkan headers and you need the prototype somewhere
+to get the C compiler to not complain.  These are all implemented by
+wrapping one of the provided ``vk_instance_get*_proc_addr()`` functions.
+
+.. doxygenfunction:: vk_instance_get_proc_addr
+.. doxygenfunction:: vk_instance_get_proc_addr_unchecked
+.. doxygenfunction:: vk_instance_get_physical_device_proc_addr
+
+We also provide an implementation of
+``vkEnumerateInstanceExtensionProperties()`` which can be used similarly:
+
+.. code-block:: c
+
+   VKAPI_ATTR VkResult VKAPI_CALL
+   drv_EnumerateInstanceExtensionProperties(const char *pLayerName,
+                                            uint32_t *pPropertyCount,
+                                            VkExtensionProperties *pProperties)
+   {
+      if (pLayerName)
+         return vk_error(NULL, VK_ERROR_LAYER_NOT_PRESENT);
+
+      return vk_enumerate_instance_extension_properties(
+         &instance_extensions, pPropertyCount, pProperties);
+   }
+
+.. doxygenfunction:: vk_enumerate_instance_extension_properties
+
+vk_physical_device
+------------------
+
+.. doxygenstruct:: vk_physical_device
+   :members:
+
+.. doxygenfunction:: vk_physical_device_init
+.. doxygenfunction:: vk_physical_device_finish
+
+vk_device
+------------------
+
+.. doxygenstruct:: vk_device
+   :members:
+
+.. doxygenfunction:: vk_device_init
+.. doxygenfunction:: vk_device_finish

docs/vulkan/dispatch.rst

+Dispatch
+=============
+
+This chapter attemtps to document the Vulkan dispatch infrastructure in the
+Mesa Vulkan runtime.  There are a lot of moving pieces here but the end
+result has proven quite effective for implementing all the various Vulkan
+API requirements.
+
+
+Extension tables
+----------------
+
+The Vulkan runtime defines two extension table structures, one for instance
+extensions and one for device extensions which contain a Boolean per
+extension.  The device table looks like this:
+
+.. code-block:: c
+
+    #define VK_DEVICE_EXTENSION_COUNT 238
+
+    struct vk_device_extension_table {
+       union {
+          bool extensions[VK_DEVICE_EXTENSION_COUNT];
+          struct {
+             bool KHR_8bit_storage;
+             bool KHR_16bit_storage;
+             bool KHR_acceleration_structure;
+             bool KHR_bind_memory2;
+             ...
+          };
+       };
+    };
+
+The instance extension table is similar except that it includes the
+instance level extensions.  Both tables are actually unions so that you can
+access the table either by name or as an array.  Accessing by name is
+typically better for human-written code which needs to query for specific
+enabled extensions or declare a table of which extensions a driver
+supports.  The array form is convenient for more automatic code which wants
+to iterate over the table.
+
+These tables are are generated automatically using a bit of python code that
+parses the vk.xml from the `Vulkan-Docs repo
+<https://github.com/KhronosGroup/Vulkan-docs/>`_, enumerates the
+extensions, sorts them by instance vs. device and generates the table.
+Generating it from XML means that we never have to manually maintain any of
+these data structures; they get automatically updated when someone imports
+a new version of vk.xml.  We also generates a matching pair of tables of
+``VkExtensionProperties``.  This makes it easy to implement
+``vkEnumerate*ExtensionProperties()`` with a simple loop that walks a table
+of supported extensions and copies the VkExtensionProperties for each
+enabled entry.  Similarly, we can have a loop in ``vkCreateInstance()`` or
+``vkCreateDevice()`` which takes the ``ppEnabledExtensionNames`` and fills
+out the table with all enabled extensions.
+
+
+Entrypoint and dispatch tables
+------------------------------
+
+Entrypoint tables contain a function pointer for every Vulkan entrypoint
+within a particular scope.  There are separate tables for instance,
+physical device, and device-level functionality.  The device entrypoint
+table looks like this:
+
+.. code-block:: c
+
+    struct vk_device_entrypoint_table {
+       PFN_vkGetDeviceProcAddr GetDeviceProcAddr;
+       PFN_vkDestroyDevice DestroyDevice;
+       PFN_vkGetDeviceQueue GetDeviceQueue;
+       PFN_vkQueueSubmit QueueSubmit;
+       ...
+    #ifdef VK_USE_PLATFORM_WIN32_KHR
+       PFN_vkGetSemaphoreWin32HandleKHR GetSemaphoreWin32HandleKHR;
+    #else
+       PFN_vkVoidFunction GetSemaphoreWin32HandleKHR;
+    # endif
+       ...
+    };
+
+Every entry that requires some sort of platform define is wrapped in an
+``#ifdef`` and declared as the actual function pointer type if the platform
+define is set and declared as a void function otherwise.  This ensures that
+the layout of the structure doesn't change based on preprocessor symbols
+but anyone who has the platform defines set gets the real prototype and
+anyone who doesn't can use the table without needing to pull in all the
+platform headers.
+
+Dispatch tables are similar to entrypoint tables except that they're
+de-duplicated so that aliased entrypoints have only one entry in the table.
+The device dispatch table looks like this:
+
+.. code-block:: c
+
+    struct vk_device_dispatch_table {
+        PFN_vkGetDeviceProcAddr GetDeviceProcAddr;
+        PFN_vkDestroyDevice DestroyDevice;
+        PFN_vkGetDeviceQueue GetDeviceQueue;
+        PFN_vkQueueSubmit QueueSubmit;
+        ...
+        union {
+            PFN_vkResetQueryPool ResetQueryPool;
+            PFN_vkResetQueryPoolEXT ResetQueryPoolEXT;
+        };
+        ...
+    };
+
+In order to allow code to use any of the aliases for a given entrypoint,
+such entrypoints are wrapped in a union.  This is important because we need
+to be able to add new aliases potentially at any Vulkan release and we want
+to do so without having to update all the driver code which uses one of the
+newly aliased entrypoints.  We could require that everyone use the first
+name an entrypoint ever has but that gets weird if, for instance, it's
+introduced in an EXT extension and some driver only ever implements the KHR
+or core version of the feature.  It's easier for everyone if we make all
+the entrypoint names work.
+
+An entrypoint table can be converted to a dispatch table by compacting it
+with one of the ``vk_*_dispatch_table_from_entrypoints()`` family of
+functions:
+
+.. code-block:: c
+
+   void vk_instance_dispatch_table_from_entrypoints(
+       struct vk_instance_dispatch_table *dispatch_table,
+       const struct vk_instance_entrypoint_table *entrypoint_table,
+       bool overwrite);
+
+   void vk_physical_device_dispatch_table_from_entrypoints(
+       struct vk_physical_device_dispatch_table *dispatch_table,
+       const struct vk_physical_device_entrypoint_table *entrypoint_table,
+       bool overwrite);
+
+   void vk_device_dispatch_table_from_entrypoints(
+       struct vk_device_dispatch_table *dispatch_table,
+       const struct vk_device_entrypoint_table *entrypoint_table,
+       bool overwrite);
+
+
+Generating driver dispatch tables
+---------------------------------
+
+Entrypoint tables can be easily auto-generated for your driver.  Simply put
+the following in the driver's ``meson.build``, modified as necessary:
+
+.. code-block::
+
+    drv_entrypoints = custom_target(
+      'drv_entrypoints',
+      input : [vk_entrypoints_gen, vk_api_xml],
+      output : ['drv_entrypoints.h', 'drv_entrypoints.c'],
+      command : [
+        prog_python, '@INPUT0@', '--xml', '@INPUT1@', '--proto', '--weak',
+        '--out-h', '@OUTPUT0@', '--out-c', '@OUTPUT1@', '--prefix', 'drv',
+      ],
+      depend_files : vk_entrypoints_gen_depend_files,
+    )
+
+The generated ``drv_entrypoints.h`` fill will contain prototypes for every
+Vulkan entrypoint, prefixed with what you passed to ``--prefix`` above.
+For instance, if you set ``--prefix drv`` and the entrypoint name is
+``vkCreateDevice()``, the driver entrypoint will be named
+``drv_CreateDevice()``.  The ``--prefix`` flag can be specified multiple
+times if you want more than one table.  It also generates an entrypoint
+table for each prefix and each dispatch level (instance, physical device,
+and device) which is populated using the driver's functions.  Thanks to our
+use of weak function pointers (or something roughly equivalent for MSVC),
+any entrypoints which are not implented will automatically show up as
+``NULL`` entries in the table rather than resulting in linking errors.
+
+The above generates entrypoint tables because, thanks to aliasing and the C
+rules around const struct declarations, it's not practical to generate a
+dispatch table directly.  Before they can be passed into the relevant
+``vk_*_init()`` function, the entrypoint table will have to be converted to
+a dispatch table.  The typical pattern for this inside a driver looks
+something like this:
+
+.. code-block:: c
+
+    struct vk_instance_dispatch_table dispatch_table;
+    vk_instance_dispatch_table_from_entrypoints(
+       &dispatch_table, &anv_instance_entrypoints, true);
+    vk_instance_dispatch_table_from_entrypoints(
+       &dispatch_table, &wsi_instance_entrypoints, false);
+
+    result = vk_instance_init(&instance->vk, &instance_extensions,
+                              &dispatch_table, pCreateInfo, pAllocator);
+    if (result != VK_SUCCESS) {
+       vk_free(pAllocator, instance);
+       return result;
+    }
+
+The ``vk_*_dispatch_table_from_entrypoints()`` functions are designed so
+that they can be layered like this.  In this case, it starts with the
+instance entrypoints from the Intel vulkan driver and then adds in the WSI
+entrypoints.  If there are any entrypoints duplicated between the two, the
+first one to define the entrypoint wins.
+
+
+Common Vulkan entrypoints
+-------------------------
+
+For the Vulkan runtime itself, there is a dispatch table with the
+``vk_common`` prefix used to provide common implementations of various
+entrypoints.  This entrypoint table is added last as part of
+``vk_*_init()`` so that the driver implementation will always be used, if
+there is one.
+
+This is used to implement a bunch of things on behalf of the driver.  The
+most common case is whenever there are ``vkFoo()`` and ``vkFoo2()``
+entrypoints.  We provide wrappers for nearly all of these that implement
+``vkFoo()`` in terms of ``vkFoo2()`` so a driver can switch to the new one
+and throw the old one away.  For instance, ``vk_common_BindBufferMemory()``
+looks like this:
+
+.. code-block:: c
+
+   VKAPI_ATTR VkResult VKAPI_CALL
+   vk_common_BindBufferMemory(VkDevice _device,
+                              VkBuffer buffer,
+                              VkDeviceMemory memory,
+                              VkDeviceSize memoryOffset)
+   {
+      VK_FROM_HANDLE(vk_device, device, _device);
+
+      VkBindBufferMemoryInfo bind = {
+         .sType         = VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_INFO,
+         .buffer        = buffer,
+         .memory        = memory,
+         .memoryOffset  = memoryOffset,
+      };
+
+      return device->dispatch_table.BindBufferMemory2(_device, 1, &bind);
+   }
+
+There are, of course, far more complicated cases of implementing
+``vkFoo()`` in terms of ``vkFoo2()`` such as the
+``vk_common_QueueSubmit()`` implementation.  We also implement far less
+trivial functionality as ``vk_common_*`` entrypoints.  For instance, we
+have full implementations of ``VkFence``, ``VkSemaphore``, and
+``vkQueueSubmit2()``.
+
+
+Entrypoint lookup
+-----------------
+
+Implementing ``vkGet*ProcAddr()`` is quite complicated because of the
+Vulkan 1.2 rules around exactly when they have to return ``NULL``.  When a
+client calls `vkGet*ProcAddr()`, we go through a three step process resolve
+the function pointer:
+
+ 1. A static (generated at compile time) hash table is used to map the
+    entrypoint name to an index into the corresponding entry point table.
+
+ 2. Optionally, the index is passed to an auto-generated function that
+    checks against the enabled core API version and extensions.  We use an
+    index into the entrypoint table, not the dispatch table, because the
+    rules for when an entrypoint should be exposed are per-entrypoint.  For
+    instance, `vkBindImageMemory2` is available on Vulkan 1.1 and later but
+    `vkBindImageMemory2KHR` is available if VK_KHR_bind_memory2 is enabled.
+
+ 3. A compaction table is used to map from the entrypoint table index to
+    the dispatch table index and the function is finally fetched from the
+    dispatch table.
+
+All of this is encapsulated within the ``vk_*_dispatch_table_get()`` and
+``vk_*_dispatch_table_get_if_supported()`` families of functions.  The
+``_if_supported`` versions take a core version and one or more extension
+tables.  The driver has to provide ``vk_icdGet*ProcAddr()`` entrypoints
+which wrap these functions because those have to be exposed as actual
+symbols from the ``.so`` or ``.dll`` as part of the loader interface.  It
+also has to provide its own ``drv_GetInstanceProcAddr()`` because it needs
+to pass the supported instance extension table to
+:cpp:func:`vk_instance_get_proc_addr`.  The runtime will provide
+``vk_common_GetDeviceProcAddr()`` implementations.
+
+
+Populating layer or client dispatch tables
+------------------------------------------
+
+The entrypoint and dispatch tables actually live in ``src/vulkan/util``,
+not ``src/vulkan/runtime`` so they can be used by layers and clients (such
+as Zink) as well as the runtime.  Layers and clients may wish to populate
+dispatch tables from an underlying Vulkan implementation.  This can be done
+via the ``vk_*_dispatch_table_load()`` family of functions:
+
+.. code-block:: c
+
+   void
+   vk_instance_dispatch_table_load(struct vk_instance_dispatch_table *table,
+                                   PFN_vkGetInstanceProcAddr gpa,
+                                   VkInstance instance);
+   void
+   vk_physical_device_dispatch_table_load(struct vk_physical_device_dispatch_table *table,
+                                          PFN_vkGetInstanceProcAddr gpa,
+                                          VkInstance instance);
+   void
+   vk_device_dispatch_table_load(struct vk_device_dispatch_table *table,
+                                 PFN_vkGetDeviceProcAddr gpa,
+                                 VkDevice device);
+
+These call the given ``vkGet*ProcAddr`` function to populate the dispatch
+table.  For aliased entrypoints, it will try each variant in succession to
+ensure that the dispatch table entry gets populated no matter which version
+of the feature you have enabled.

docs/vulkan/index.rst

@@ -9,4 +9,6 @@ hardware-agnostic bits in common code.
 .. toctree::
    :maxdepth: 2
 
+   base-objs
+   dispatch
    renderpass

include/kopper_interface.h

+/*
+ * Copyright 2020 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * In principle this could all go in dri_interface.h, but:
+ * - I want type safety in here, but I don't want to require vulkan.h from
+ *   dri_interface.h
+ * - I don't especially want this to be an interface outside of Mesa itself
+ * - Ideally dri_interface.h wouldn't even be a thing anymore
+ *
+ * So instead let's just keep this as a Mesa-internal detail.
+ */
+
+#ifndef KOPPER_INTERFACE_H
+#define KOPPER_INTERFACE_H
+
+#include <GL/internal/dri_interface.h>
+#include <vulkan/vulkan.h>
+#ifdef VK_USE_PLATFORM_XCB_KHR
+#include <xcb/xcb.h>
+#include <vulkan/vulkan_xcb.h>
+#endif
+#ifdef VK_USE_PLATFORM_WAYLAND_KHR
+#include <vulkan/vulkan_wayland.h>
+#endif
+
+typedef struct __DRIkopperExtensionRec          __DRIkopperExtension;
+typedef struct __DRIkopperLoaderExtensionRec    __DRIkopperLoaderExtension;
+
+/**
+ * This extension defines the core GL-atop-VK functionality. This is used by the
+ * zink driver to implement GL (or other APIs) natively atop Vulkan, without
+ * relying on a particular window system or DRI protocol.
+ */
+#define __DRI_KOPPER "DRI_Kopper"
+#define __DRI_KOPPER_VERSION 1
+
+struct kopper_surface;
+
+struct __DRIkopperExtensionRec {
+    __DRIextension base;
+
+    /* This is called by a kopper-aware loader in preference to the one
+     * in __DRI_DRISW. The additional fourth argument sets whether the winsys
+     * drawable is a pixmap. This matters because swapchains correspond to
+     * on-screen surfaces (eg X11 window) and trying to create a swapchain for
+     * a pixmap is undefined.
+     */
+    __DRIdrawable *(*createNewDrawable)(__DRIscreen *screen,
+                                        const __DRIconfig *config,
+                                        void *loaderPrivate,
+                                        int pixmap);
+};
+
+/**
+ * Kopper loader extension.
+ */
+
+struct kopper_loader_info {
+   union {
+      VkBaseOutStructure bos;
+#ifdef VK_USE_PLATFORM_XCB_KHR
+      VkXcbSurfaceCreateInfoKHR xcb;
+#endif
+#ifdef VK_USE_PLATFORM_WAYLAND_KHR
+      VkWaylandSurfaceCreateInfoKHR wl;
+#endif
+   };
+   int has_alpha;
+};
+
+#define __DRI_KOPPER_LOADER "DRI_KopperLoader"
+#define __DRI_KOPPER_LOADER_VERSION 0
+struct __DRIkopperLoaderExtensionRec {
+    __DRIextension base;
+
+    /* Asks the loader to fill in VkWhateverSurfaceCreateInfo etc. */
+    void (*SetSurfaceCreateInfo)(void *draw, struct kopper_loader_info *out);
+    /* Asks the loader to fill in the drawable's width and height */
+    void (*GetDrawableInfo)(__DRIdrawable *draw, int *w, int *h,
+                            void *closure);
+};
+#endif /* KOPPER_INTERFACE_H */

include/pci_ids/iris_pci_ids.h

@@ -237,4 +237,6 @@ CHIPSET(0x56a5, dg2_g11, "DG2", "Intel(R) Graphics")
 CHIPSET(0x56a6, dg2_g11, "DG2", "Intel(R) Graphics")
 CHIPSET(0x56b0, dg2_g11, "DG2", "Intel(R) Graphics")
 CHIPSET(0x56b1, dg2_g11, "DG2", "Intel(R) Graphics")
+CHIPSET(0x56c0, dg2_g10, "ATS-M", "Intel(R) Graphics")
+CHIPSET(0x56c1, dg2_g11, "ATS-M", "Intel(R) Graphics")
 #endif

meson.build

@@ -231,6 +231,9 @@ with_gallium_lima = gallium_drivers.contains('lima')
 with_gallium_zink = gallium_drivers.contains('zink')
 with_gallium_d3d12 = gallium_drivers.contains('d3d12')
 with_gallium_asahi = gallium_drivers.contains('asahi')
+foreach gallium_driver : gallium_drivers
+  pre_args += '-DHAVE_@0@'.format(gallium_driver.to_upper())
+endforeach
 
 with_gallium = gallium_drivers.length() != 0
 with_gallium_kmsro = with_gallium_v3d or with_gallium_vc4 or with_gallium_etnaviv or with_gallium_panfrost or with_gallium_lima or with_gallium_freedreno

meson_options.txt

@@ -467,7 +467,7 @@ option(
   'platform-sdk-version',
   type : 'integer',
   min : 25,
-  max : 31,
+  max : 10000,
   value : 25,
   description : 'Android Platform SDK version. Default: Nougat version.'
 )

src/amd/vulkan/radv_cmd_buffer.c

@@ -8779,7 +8779,14 @@ radv_flush_vgt_streamout(struct radv_cmd_buffer *cmd_buffer)
    unsigned reg_strmout_cntl;
 
    /* The register is at different places on different ASICs. */
-   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX7) {
+   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
+      reg_strmout_cntl = R_0300FC_CP_STRMOUT_CNTL;
+      radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
+      radeon_emit(cs, S_370_DST_SEL(V_370_MEM_MAPPED_REGISTER) | S_370_ENGINE_SEL(V_370_ME));
+      radeon_emit(cs, R_0300FC_CP_STRMOUT_CNTL >> 2);
+      radeon_emit(cs, 0);
+      radeon_emit(cs, 0);
+   } else if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX7) {
       reg_strmout_cntl = R_0300FC_CP_STRMOUT_CNTL;
       radeon_set_uconfig_reg(cs, reg_strmout_cntl, 0);
    } else {

src/amd/vulkan/radv_nir_apply_pipeline_layout.c

@@ -42,6 +42,7 @@ typedef struct {
 static nir_ssa_def *
 get_scalar_arg(nir_builder *b, unsigned size, struct ac_arg arg)
 {
+   assert(arg.used);
    return nir_load_scalar_arg_amd(b, size, .base = arg.arg_index);
 }
 

src/amd/vulkan/radv_pipeline_cache.c

@@ -118,9 +118,9 @@ entry_size(struct cache_entry *entry)
 }
 
 void
-radv_hash_shaders(unsigned char *hash, const VkPipelineShaderStageCreateInfo **stages,
-                  const struct radv_pipeline_layout *layout, const struct radv_pipeline_key *key,
-                  uint32_t flags)
+radv_hash_shaders(unsigned char *hash, const VkPipelineShaderStageCreateInfo *stages,
+                  uint32_t stageCount, const struct radv_pipeline_layout *layout,
+                  const struct radv_pipeline_key *key, uint32_t flags)
 {
    struct mesa_sha1 ctx;
 
@@ -130,18 +130,16 @@ radv_hash_shaders(unsigned char *hash, const VkPipelineShaderStageCreateInfo **s
    if (layout)
       _mesa_sha1_update(&ctx, layout->sha1, sizeof(layout->sha1));
 
-   for (int i = 0; i < MESA_VULKAN_SHADER_STAGES; ++i) {
-      if (stages[i]) {
-         RADV_FROM_HANDLE(vk_shader_module, module, stages[i]->module);
-         const VkSpecializationInfo *spec_info = stages[i]->pSpecializationInfo;
-
-         _mesa_sha1_update(&ctx, module->sha1, sizeof(module->sha1));
-         _mesa_sha1_update(&ctx, stages[i]->pName, strlen(stages[i]->pName));
-         if (spec_info && spec_info->mapEntryCount) {
-            _mesa_sha1_update(&ctx, spec_info->pMapEntries,
-                              spec_info->mapEntryCount * sizeof spec_info->pMapEntries[0]);
-            _mesa_sha1_update(&ctx, spec_info->pData, spec_info->dataSize);
-         }
+   for (uint32_t i = 0; i < stageCount; i++) {
+      RADV_FROM_HANDLE(vk_shader_module, module, stages[i].module);
+      const VkSpecializationInfo *spec_info = stages[i].pSpecializationInfo;
+
+      _mesa_sha1_update(&ctx, module->sha1, sizeof(module->sha1));
+      _mesa_sha1_update(&ctx, stages[i].pName, strlen(stages[i].pName));
+      if (spec_info && spec_info->mapEntryCount) {
+         _mesa_sha1_update(&ctx, spec_info->pMapEntries,
+                           spec_info->mapEntryCount * sizeof spec_info->pMapEntries[0]);
+         _mesa_sha1_update(&ctx, spec_info->pData, spec_info->dataSize);
       }
    }
    _mesa_sha1_update(&ctx, &flags, 4);