Contact
- 
Jesse Hall [GitHub]critsec 
- 
Ian Elliott [GitHub]ianelliottus 
Other Extension Metadata
- Last Modified Date
- 
2015-11-28 
- IP Status
- 
No known IP claims. 
- Contributors
- 
- 
Patrick Doane, Blizzard 
- 
Faith Ekstrand, Intel 
- 
Ian Elliott, LunarG 
- 
Courtney Goeltzenleuchter, LunarG 
- 
Jesse Hall, Google 
- 
James Jones, NVIDIA 
- 
Antoine Labour, Google 
- 
Jon Leech, Khronos 
- 
David Mao, AMD 
- 
Norbert Nopper, Freescale 
- 
Alon Or-bach, Samsung 
- 
Daniel Rakos, AMD 
- 
Graham Sellers, AMD 
- 
Ray Smith, ARM 
- 
Jeff Vigil, Qualcomm 
- 
Chia-I Wu, LunarG 
 
- 
Description
The VK_KHR_wayland_surface extension is an instance extension.
It provides a mechanism to create a VkSurfaceKHR object (defined by
the VK_KHR_surface extension) that refers to a Wayland
wl_surface, as well as a query to determine support for rendering to a
Wayland compositor.
New Enum Constants
- 
VK_KHR_WAYLAND_SURFACE_EXTENSION_NAME
- 
VK_KHR_WAYLAND_SURFACE_SPEC_VERSION
- 
Extending VkStructureType: - 
VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR
 
- 
Issues
1) Does Wayland need a way to query for compatibility between a particular
physical device and a specific Wayland display? This would be a more general
query than vkGetPhysicalDeviceSurfaceSupportKHR: if the
Wayland-specific query returned VK_TRUE for a (VkPhysicalDevice,
struct wl_display*) pair, then the physical device could be assumed to
support presentation to any VkSurfaceKHR for surfaces on the display.
RESOLVED: Yes. vkGetPhysicalDeviceWaylandPresentationSupportKHR was added to address this issue.
2) Should we require surfaces created with vkCreateWaylandSurfaceKHR
to support the VK_PRESENT_MODE_MAILBOX_KHR present mode?
RESOLVED: Yes.
Wayland is an inherently mailbox window system and mailbox support is
required for some Wayland compositor interactions to work as expected.
While handling these interactions may be possible with
VK_PRESENT_MODE_FIFO_KHR, it is much more difficult to do without
deadlock and requiring all Wayland applications to be able to support
implementations which only support VK_PRESENT_MODE_FIFO_KHR would be
an onerous restriction on application developers.
Version History
- 
Revision 1, 2015-09-23 (Jesse Hall) - 
Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface). 
 
- 
- 
Revision 2, 2015-10-02 (James Jones) - 
Added vkGetPhysicalDeviceWaylandPresentationSupportKHR() to resolve issue #1. 
- 
Adjusted wording of issue #1 to match the agreed-upon solution. 
- 
Renamed “window” parameters to “surface” to match Wayland conventions. 
 
- 
- 
Revision 3, 2015-10-26 (Ian Elliott) - 
Renamed from VK_EXT_KHR_wayland_surface to VK_KHR_wayland_surface. 
 
- 
- 
Revision 4, 2015-11-03 (Daniel Rakos) - 
Added allocation callbacks to vkCreateWaylandSurfaceKHR. 
 
- 
- 
Revision 5, 2015-11-28 (Daniel Rakos) - 
Updated the surface create function to take a pCreateInfo structure. 
 
- 
- 
Revision 6, 2017-02-08 (Faith Ekstrand) - 
Added the requirement that implementations support VK_PRESENT_MODE_MAILBOX_KHR.
- 
Added wording about interactions between vkQueuePresentKHR and the Wayland requests sent to the compositor. 
 
- 
Document Notes
For more information, see the Vulkan Specification
This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.