mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-25 20:45:12 +00:00
194a7f4d0d
* Update release number to 122.
Internal Issues:
* Add style guide language on not using standalone `+` signs (internal
issue 736); not using leading whitespace for markup (internal issue
747); and on keeping descriptions of a single API in a contiguous block
of markup (internal issue 949), and apply them to the specification.
* Add a glossary definition of "`constant integral expression`", pointing
to the SPIR-V "`constant instruction`" definition (internal issue 1225).
* Many minor edits to improve writing style consistency and capture
additional style guidelines (internal issue 1553).
* Clarify that <<fragops-depth-write, depth writes are not performed>> if
there is no depth framebuffer attachment (internal issue 1771).
* Allow implementations to use rectangular line style of interpolation for
<<primsrast-lines-bresenham, wide Bresenham lines>>, though replicating
attributes is still preferred. Clarify that code:FragCoord is not
replicated (internal issue 1772).
* Resolve a contradiction in valid usage statements for
slink:VkImageCreateInfo and slink:VkImageStencilUsageCreateInfoEXT
(internal issue 1773).
* Add style guide discussion of markup for indented equations, and use
markup workaround for asciidoctor 2 compatibility (internal issue 1793).
* Deprecate the `<<VK_EXT_validation_flags>>` extension in `vk.xml` and
the extension appendix (internal issue 1801).
* Add a new checker script `scripts/xml_consistency.py`. This is not
currently run as part of internal CI (internal merge request 3285).
* Correct "`an`" -> "`a`" prepositions where needed (internal merge
request 3334).
* Clarify that the <<features-uniformBufferStandardLayout,
pname:uniformBufferStandardLayout>> feature is only required when the
extension defining it is supported (internal merge request 3341).
* Bring scripts into closer sync with OpenXR, mainly through conversion of
comments to docstrings where appropriate, and add gen-scripts-docs.sh
(internal merge request 3324).
* Correct pname:maxDrawMeshTasksCount to 2^16^-1 in the <<limits-required,
Required Limits>> table (internal merge requests 3361).
New Extensions
* `<<VK_IMG_format_pvrtc>>` (public issue 512).
90 lines
3.6 KiB
Plaintext
90 lines
3.6 KiB
Plaintext
// Copyright (c) 2014-2019 Khronos Group. This work is licensed under a
|
|
// Creative Commons Attribution 4.0 International License; see
|
|
// http://creativecommons.org/licenses/by/4.0/
|
|
|
|
[[platformCreateSurface_xlib,platformCreateSurface_xlib]]
|
|
|
|
=== Xlib Platform
|
|
|
|
[open,refpage='vkCreateXlibSurfaceKHR',desc='Create a slink:VkSurfaceKHR object for an X11 window, using the Xlib client-side library',type='protos']
|
|
--
|
|
|
|
To create a sname:VkSurfaceKHR object for an X11 window, using the Xlib
|
|
client-side library, call:
|
|
|
|
include::{generated}/api/protos/vkCreateXlibSurfaceKHR.txt[]
|
|
|
|
* pname:instance is the instance to associate the surface with.
|
|
* pname:pCreateInfo is a pointer to a sname:VkXlibSurfaceCreateInfoKHR
|
|
structure containing the parameters affecting the creation of the
|
|
surface object.
|
|
* pname:pAllocator is the allocator used for host memory allocated for the
|
|
surface object when there is no more specific allocator available (see
|
|
<<memory-allocation,Memory Allocation>>).
|
|
* pname:pSurface is a pointer to a slink:VkSurfaceKHR handle in which the
|
|
created surface object is returned.
|
|
|
|
include::{generated}/validity/protos/vkCreateXlibSurfaceKHR.txt[]
|
|
--
|
|
|
|
[open,refpage='VkXlibSurfaceCreateInfoKHR',desc='Structure specifying parameters of a newly created Xlib surface object',type='structs']
|
|
--
|
|
|
|
The sname:VkXlibSurfaceCreateInfoKHR structure is defined as:
|
|
|
|
include::{generated}/api/structs/VkXlibSurfaceCreateInfoKHR.txt[]
|
|
|
|
* pname:sType is the type of this structure.
|
|
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
|
|
* pname:flags is reserved for future use.
|
|
* pname:dpy is a pointer to an Xlib code:Display connection to the X
|
|
server.
|
|
* pname:window is an Xlib code:Window to associate the surface with.
|
|
|
|
.Valid Usage
|
|
****
|
|
* [[VUID-VkXlibSurfaceCreateInfoKHR-dpy-01313]]
|
|
pname:dpy must: point to a valid Xlib code:Display.
|
|
* [[VUID-VkXlibSurfaceCreateInfoKHR-window-01314]]
|
|
pname:window must: be a valid Xlib code:Window.
|
|
****
|
|
|
|
include::{generated}/validity/structs/VkXlibSurfaceCreateInfoKHR.txt[]
|
|
--
|
|
|
|
With Xlib, pname:minImageExtent, pname:maxImageExtent, and
|
|
pname:currentExtent must: always equal the window size.
|
|
|
|
The pname:currentExtent of an Xlib surface must: have both pname:width and
|
|
pname:height greater than 0, or both of them 0.
|
|
|
|
[NOTE]
|
|
.Note
|
|
====
|
|
Due to above restrictions, it is only possible to create a new swapchain on
|
|
this platform with pname:imageExtent being equal to the current size of the
|
|
window.
|
|
|
|
The window size may: become [eq]#(0, 0)# on this platform (e.g. when the
|
|
window is minimized), and so a swapchain cannot: be created until the size
|
|
changes.
|
|
====
|
|
|
|
Some Vulkan functions may: send protocol over the specified Xlib
|
|
code:Display connection when using a swapchain or presentable images created
|
|
from a slink:VkSurfaceKHR referring to an Xlib window.
|
|
Applications must: therefore ensure the display connection is available to
|
|
Vulkan for the duration of any functions that manipulate such swapchains or
|
|
their presentable images, and any functions that build or queue command
|
|
buffers that operate on such presentable images.
|
|
Specifically, applications using Vulkan with Xlib-based swapchains must:
|
|
|
|
* Avoid holding a server grab on a display connection while waiting for
|
|
Vulkan operations to complete using a swapchain derived from a different
|
|
display connection referring to the same X server instance.
|
|
Failing to do so may: result in deadlock.
|
|
|
|
Some implementations may require threads to implement some presentation
|
|
modes so applications must: call code:XInitThreads() before calling any
|
|
other Xlib functions.
|