Vulkan.Extensions.VK_KHR_wayland_surface

Name

VK_KHR_wayland_surface - instance extension

VK_KHR_wayland_surface

Name String

VK_KHR_wayland_surface

Extension Type

Instance extension

Registered Extension Number

7

Revision

6

Ratification Status

Ratified

Extension and Version Dependencies

VK_KHR_surface

Contact

• Jesse Hall @critsec%0A*Here describe the issue or question you have about the VK_KHR_wayland_surface extension*

• Ian Elliott @ianelliottus%0A*Here describe the issue or question you have about the VK_KHR_wayland_surface extension*

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 SurfaceKHR 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 Commands

• createWaylandSurfaceKHR

• getPhysicalDeviceWaylandPresentationSupportKHR

New Structures

• WaylandSurfaceCreateInfoKHR

New Bitmasks

• WaylandSurfaceCreateFlagsKHR

New Enum Constants

• KHR_WAYLAND_SURFACE_EXTENSION_NAME

• KHR_WAYLAND_SURFACE_SPEC_VERSION

• Extending StructureType:

  • 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 getPhysicalDeviceSurfaceSupportKHR: if the Wayland-specific query returned TRUE for a (PhysicalDevice, struct wl_display*) pair, then the physical device could be assumed to support presentation to any SurfaceKHR for surfaces on the display.

RESOLVED: Yes. getPhysicalDeviceWaylandPresentationSupportKHR was added to address this issue.

2) Should we require surfaces created with createWaylandSurfaceKHR to support the 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 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 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 PRESENT_MODE_MAILBOX_KHR.

  • Added wording about interactions between queuePresentKHR and the Wayland requests sent to the compositor.

See Also

No cross-references are available

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.