Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

This is a simple passthrough implementation to the native Vulkan driver,
but will be extended to support cross-process rendering.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

Create images to be used for cross-process Vulkan rendering, and
return them through vkGetSwapchainImagesKHR.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

Introduce the remote swapchain object, currently with a stub
implementation, that we are going to use for cross-process Vulkan
rendering.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

When the target window for a Win32 VkSurfaceKHR is not owned by the
current process, we don't have access to the corresponding wayland
surface to use as the target for creating the host VkSurfaceKHR. In such
cases create a dummy wl_surface and use it to allow VkSurfaceKHR to
conclude successfully.

Note that no content targeting this dummy wl_surface will ever become
visible, but we will fix this in upcoming commits when we introduce a
cross-process swapchain implementation that forwards images to the right
process for presentation.

For now the cross-process code path is not used (notice the constant
allowed_to_create_remote_swapchain in the code), because we still don't
have all the pieces to make the cross-process swapchain work. So we
won't even allow the dummy wl_surface to be created. When we put all the
pieces together, we'll drop this constant and allow the code to run.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

Introduce a mechanism to check and enable VkInstance extensions required
to support cross-process rendering in upcoming commits.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

Introduce a mechanism to check and enable VkDevice extensions required
to support cross-process rendering in upcoming commits.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

Implement vkCreateDevice and vkDestroyDevice so that:

1. We can track the mapping between physical and logical Vulkan devices.
2. We can enable some additional host VkDevice extensions.

Both of the above are required to support cross-process rendering in
upcoming commits.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

In the following commits we'll introduce an internal swapchain in order
to support Vulkan cross-process rendering. In order to do that, we'll
need to create wl_surface objects from the per-process instance. So bind
to wl_compositor on the per-process instance as well.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

This makes some Vulkan extensions available to driver and allows
them to override a few more Vulkan functions.

This will be needed by the Wine Wayland driver in the following commits,
in which we introduce support for cross-process Vulkan rendering.

Extensions:
    VK_EXT_external_memory_dma_buf
    VK_EXT_image_drm_format_modifier
    VK_KHR_external_fence_fd
    VK_KHR_external_memory_fd
    VK_KHR_external_semaphore_fd

Functions:
    vkCreateDevice
    vkDestroyDevice
    vkAcquireNextImageKHR

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

With this change we don't need to implement all the functions from
struct vulkan_funcs on the X11 driver. This is safe to do because
Wine has fallbacks for them.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>

When the Wayland surface is updated (including when it changes to NULL,
i.e., when it is destroyed), we need to notify the application so that
it can deal with it accordingly.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

The VkSurfaceKHR we return in wayland_vkCreateWin32SurfaceKHR *is* the
native VkSurfaceKHR, so the implementation is trivial.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

This is a simple passthrough implementation to the native Vulkan driver.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

This is a simple passthrough implementation to the corresponding Vulkan
Wayland extension.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

This is a simple passthrough implementation to the native Vulkan driver,
with the addition of a VkSurfaceKHR invalidation check.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

This is a simple passthrough implementation to the native Vulkan driver,
with the addition of a VkSurfaceKHR invalidation check.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Passthrough implementations with two additions:

1. Checking for invalidated VkSurfaceKHR.
2. Try to emulate vkGetPhysicalDeviceSurfaceFormats2KHR with
   vkGetPhysicalDeviceSurfaceFormatsKHR if needed.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Passthrough implementations with three additions:

1. Checking for invalidated VkSurfaceKHR.
2. Try to emulate vkGetPhysicalDeviceSurfaceCapabilities2KHR with
   vkGetPhysicalDeviceSurfaceCapabilitiesKHR if needed.
3. Set the capabilities' image extent values to match what the Vulkan Win32 WSI
   typically provides.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

This is a simple passthrough implementation to the native Vulkan driver.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

This is a simple passthrough implementation to the native Vulkan driver,
with the addition of a VkSurfaceKHR invalidation check.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Return the native instance extension properties, substituting
VK_KHR_wayland_surface for VK_KHR_win32_surface.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

When the Wayland surface associated with a Vulkan surface or swapchain
is scheduled for destruction, we mark such Vulkan objects as invalidated
in the driver and callers are notified with the
VK_ERROR_SURFACE_LOST_KHR hard error when they try to use such objects.

Note that the Vulkan objects hold a reference to the associated Wayland
surface, so there is no danger of time-of-check to time-of-use (TOCTOU)
related bugs/races when checking for invalidation.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Return the VK_ERROR_OUT_OF_DATE_KHR soft error to notify callers of
vkQueuePresent that the image(s) they are presenting don't match the
current window size.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Before presenting ensure that the parent Wayland surface of the
subsurface used for VK content has been mapped, otherwise the Vulkan
content won't be visible and will block any throttled/vsynced rendering
loops which rely on wl_frame events.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Create Win32 VkSwapchainKHR objects which are backed by native Wayland
VkSwapchainKHR objects. We use the native VkSwapchainKHR handle as the
Win32 VkSwapchainKHR handle, to ensure transparent compatibility with
all extensions (current *and* future) that accept VkSwapchainKHR
handles.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Create Win32 VkSurfaceKHR objects which are backed by native Wayland
VkSurfaceKHR objects. These native objects are associated with a
dedicated subsurface we use for Vulkan rendering (see
wayland_surface_create_or_ref_vk). We use the native VkSurfaceKHR handle
as the Win32 VkSurfaceKHR handle, to ensure transparent compatibility
with all extensions (current *and* future) that accept VkSurfaceKHR
handles.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Create a Vulkan instance, ensuring we use the proper (Wayland)
SurfaceKHR extension when forwarding the request to the native Vulkan
platform.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Inform the Wayland compositor of the window title for toplevel windows,
transforming the title to the expected UTF-8 encoding.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Leandro Ribeiro authored 2 years ago and Alexandros Frantzis committed 2 years ago

Implement the SetCursorPos driver callback to improve our pointer
constraint and relative motion heuristics. Note that we don't
support actually setting the cursor position, since this is not
supported by Wayland.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>

Implement cursor clipping by using the zwp_pointer_constraints_v1
and the zwp_relative_pointer_v1 Wayland protocols.

We use a set of heurestics to decide when to constrain the Wayland
pointer and which form of constraint to use for the focused surface:

1. If the cursor isn't visible (i.e., we don't have a current cursor)
   and we have an effective clip for a window, lock the pointer in
   the corresponding Wayland surface and emit relative events (typical
   case for first/third-person perspective 3D games).

2. If the cursor is visible, and we have an effective clip for a window,
   confine the cursor to the clipped area within the corresponding
   Wayland surface and emit absolute events.

3. Otherwise, don't constrain.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Introduce the wayland_surface_coords_from_screen function to transform
Wine screen coords to Wayland surfaces coords. This will be useful in an
upcoming commit which will need to set the pointer position hint when
leaving relative pointer event mode.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Introduce a function to set the Wayland pointer event mode, emitting
either absolute coordinates (the default) or relative coordinates (i.e.,
just differences from previous positions). Relative mode requires and
uses the zwp_relative_pointer_manager_v1 Wayland extension.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

This is a fallback implementation for when the dibdrv cannot perform
this task, typically because the destination belongs to a different
process. In such a case the implementation utilizes the remote surface
infrastructure to commit content to the remote HWND.

The implementation is very limited, supporting only simple full copies,
but that's enough for some typical cross-process cases, notably software
rendered content on Chrome/CEF.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

Use the cross-process remote surface infrastructure to present buffers
to HWNDs belonging in different processes.

Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>