Safe Haskell | None |
---|---|
Language | Haskell2010 |
Name
VK_KHR_display - instance extension
VK_KHR_display
- Name String
VK_KHR_display
- Extension Type
- Instance extension
- Registered Extension Number
- 3
- Revision
- 23
- Extension and Version Dependencies
- Requires Vulkan 1.0
- Requires
VK_KHR_surface
- Contact
Other Extension Metadata
- Last Modified Date
- 2017-03-13
- IP Status
- No known IP claims.
- Contributors
- James Jones, NVIDIA
- Norbert Nopper, Freescale
- Jeff Vigil, Qualcomm
- Daniel Rakos, AMD
Description
This extension provides the API to enumerate displays and available modes on a given device.
New Object Types
New Commands
createDisplayPlaneSurfaceKHR
getDisplayModePropertiesKHR
getDisplayPlaneCapabilitiesKHR
getDisplayPlaneSupportedDisplaysKHR
getPhysicalDeviceDisplayPlanePropertiesKHR
getPhysicalDeviceDisplayPropertiesKHR
New Structures
DisplayModeParametersKHR
DisplayModePropertiesKHR
DisplayPlaneCapabilitiesKHR
DisplayPlanePropertiesKHR
DisplayPropertiesKHR
DisplaySurfaceCreateInfoKHR
New Enums
New Bitmasks
New Enum Constants
KHR_DISPLAY_SPEC_VERSION
Extending
ObjectType
:Extending
StructureType
:
Issues
1) Which properties of a mode should be fixed in the mode info vs. settable in some other function when setting the mode? E.g., do we need to double the size of the mode pool to include both stereo and non-stereo modes? YUV and RGB scanout even if they both take RGB input images? BGR vs. RGB input? etc.
PROPOSED RESOLUTION: Many modern displays support at most a handful of resolutions and timings natively. Other “modes” are expected to be supported using scaling hardware on the display engine or GPU. Other properties, such as rotation and mirroring should not require duplicating hardware modes just to express all combinations. Further, these properties may be implemented on a per-display or per-overlay granularity.
To avoid the exponential growth of modes as mutable properties are
added, as was the case with EGLConfig
/WGL pixel
formats/GLXFBConfig
, this specification should separate out hardware
properties and configurable state into separate objects. Modes and
overlay planes will express capabilities of the hardware, while a
separate structure will allow applications to configure scaling,
rotation, mirroring, color keys, LUT values, alpha masks, etc. for a
given swapchain independent of the mode in use. Constraints on these
settings will be established by properties of the immutable objects.
Note the resolution of this issue may affect issue 5 as well.
2) What properties of a display itself are useful?
PROPOSED RESOLUTION: This issue is too broad. It was meant to prompt general discussion, but resolving this issue amounts to completing this specification. All interesting properties should be included. The issue will remain as a placeholder since removing it would make it hard to parse existing discussion notes that refer to issues by number.
3) How are multiple overlay planes within a display or mode enumerated?
PROPOSED RESOLUTION: They are referred to by an index. Each display will report the number of overlay planes it contains.
4) Should swapchains be created relative to a mode or a display?
PROPOSED RESOLUTION: When using this extension, swapchains are created relative to a mode and a plane. The mode implies the display object the swapchain will present to. If the specified mode is not the display’s current mode, the new mode will be applied when the first image is presented to the swapchain, and the default operating system mode, if any, will be restored when the swapchain is destroyed.
5) Should users query generic ranges from displays and construct their own modes explicitly using those constraints rather than querying a fixed set of modes (Most monitors only have one real “mode” these days, even though many support relatively arbitrary scaling, either on the monitor side or in the GPU display engine, making “modes” something of a relic/compatibility construct).
PROPOSED RESOLUTION: Expose both. Display info structures will expose a set of predefined modes, as well as any attributes necessary to construct a customized mode.
6) Is it fine if we return the display and display mode handles in the structure used to query their properties?
PROPOSED RESOLUTION: Yes.
7) Is there a possibility that not all displays of a device work with all of the present queues of a device? If yes, how do we determine which displays work with which present queues?
PROPOSED RESOLUTION: No known hardware has such limitations, but
determining such limitations is supported automatically using the
existing VK_KHR_surface
and VK_KHR_swapchain
query mechanisms.
8) Should all presentation need to be done relative to an overlay plane, or can a display mode + display be used alone to target an output?
PROPOSED RESOLUTION: Require specifying a plane explicitly.
9) Should displays have an associated window system display, such as an
HDC
or Display
*?
PROPOSED RESOLUTION: No. Displays are independent of any windowing
system in use on the system. Further, neither HDC
nor
Display
* refer to a physical
display object.
10) Are displays queried from a physical GPU or from a device instance?
PROPOSED RESOLUTION: Developers prefer to query modes directly from the physical GPU so they can use display information as an input to their device selection algorithms prior to device creation. This avoids the need to create placeholder device instances to enumerate displays.
This preference must be weighed against the extra initialization that must be done by driver vendors prior to device instance creation to support this usage.
11) Should displays and/or modes be dispatchable objects? If functions are to take displays, overlays, or modes as their first parameter, they must be dispatchable objects as defined in Khronos bug 13529. If they are not added to the list of dispatchable objects, functions operating on them must take some higher-level object as their first parameter. There is no performance case against making them dispatchable objects, but they would be the first extension objects to be dispatchable.
PROPOSED RESOLUTION: Do not make displays or modes dispatchable. They will dispatch based on their associated physical device.
12) Should hardware cursor capabilities be exposed?
PROPOSED RESOLUTION: Defer. This could be a separate extension on top of the base WSI specs.
if they are one physical display device to an end user, but may internally be implemented as two side-by-side displays using the same display engine (and sometimes cabling) resources as two physically separate display devices.
RESOLVED: Tiled displays will appear as a single display object in this API.
14) Should the raw EDID data be included in the display information?
RESOLVED: No. A future extension could be added which reports the EDID if necessary. This may be complicated by the outcome of issue 13.
15) Should min and max scaling factor capabilities of overlays be exposed?
RESOLVED: Yes. This is exposed indirectly by allowing applications to query the min/max position and extent of the source and destination regions from which image contents are fetched by the display engine when using a particular mode and overlay pair.
16) Should devices be able to expose planes that can be moved between displays? If so, how?
RESOLVED: Yes. Applications can determine which displays a given
plane supports using getDisplayPlaneSupportedDisplaysKHR
.
17) Should there be a way to destroy display modes? If so, does it support destroying “built in” modes?
RESOLVED: Not in this extension. A future extension could add this functionality.
18) What should the lifetime of display and built-in display mode objects be?
RESOLVED: The lifetime of the instance. These objects cannot be destroyed. A future extension may be added to expose a way to destroy these objects and/or support display hotplug.
19) Should persistent mode for smart panels be enabled/disabled at swapchain creation time, or on a per-present basis.
RESOLVED: On a per-present basis.
Examples
Note
The example code for the VK_KHR_display
and VK_KHR_display_swapchain
extensions was removed from the appendix after revision 1.0.43. The
display enumeration example code was ported to the cube demo that is
shipped with the official Khronos SDK, and is being kept up-to-date in
that location (see:
https://github.com/KhronosGroup/Vulkan-Tools/blob/master/cube/cube.c).
Version History
Revision 1, 2015-02-24 (James Jones)
- Initial draft
Revision 2, 2015-03-12 (Norbert Nopper)
- Added overlay enumeration for a display.
Revision 3, 2015-03-17 (Norbert Nopper)
- Fixed typos and namings as discussed in Bugzilla.
- Reordered and grouped functions.
- Added functions to query count of display, mode and overlay.
- Added native display handle, which is maybe needed on some platforms to create a native Window.
Revision 4, 2015-03-18 (Norbert Nopper)
- Removed primary and virtualPostion members (see comment of James Jones in Bugzilla).
- Added native overlay handle to info structure.
- Replaced , with ; in struct.
Revision 6, 2015-03-18 (Daniel Rakos)
- Added WSI extension suffix to all items.
- Made the whole API more "Vulkanish".
- Replaced all functions with a single vkGetDisplayInfoKHR function to better match the rest of the API.
- Made the display, display mode, and overlay objects be first class objects, not subclasses of VkBaseObject as they do not support the common functions anyways.
- Renamed *Info structures to *Properties.
- Removed overlayIndex field from VkOverlayProperties as there is an implicit index already as a result of moving to a "Vulkanish" API.
- Displays are not get through device, but through physical GPU to match the rest of the Vulkan API. Also this is something ISVs explicitly requested.
- Added issue (6) and (7).
Revision 7, 2015-03-25 (James Jones)
- Added an issues section
- Added rotation and mirroring flags
Revision 8, 2015-03-25 (James Jones)
- Combined the duplicate issues sections introduced in last change.
- Added proposed resolutions to several issues.
Revision 9, 2015-04-01 (Daniel Rakos)
- Rebased extension against Vulkan 0.82.0
Revision 10, 2015-04-01 (James Jones)
- Added issues (10) and (11).
- Added more straw-man issue resolutions, and cleaned up the proposed resolution for issue (4).
- Updated the rotation and mirroring enums to have proper bitmask semantics.
Revision 11, 2015-04-15 (James Jones)
- Added proposed resolution for issues (1) and (2).
- Added issues (12), (13), (14), and (15)
- Removed pNativeHandle field from overlay structure.
- Fixed small compilation errors in example code.
Revision 12, 2015-07-29 (James Jones)
- Rewrote the guts of the extension against the latest WSI swapchain specifications and the latest Vulkan API.
- Address overlay planes by their index rather than an object handle and refer to them as "planes" rather than "overlays" to make it slightly clearer that even a display with no "overlays" still has at least one base "plane" that images can be displayed on.
- Updated most of the issues.
- Added an "extension type" section to the specification header.
- Re-used the VK_EXT_KHR_surface surface transform enumerations rather than redefining them here.
- Updated the example code to use the new semantics.
Revision 13, 2015-08-21 (Ian Elliott)
- Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.
- Switched from "revision" to "version", including use of the VK_MAKE_VERSION macro in the header file.
Revision 14, 2015-09-01 (James Jones)
- Restore single-field revision number.
Revision 15, 2015-09-08 (James Jones)
- Added alpha flags enum.
- Added premultiplied alpha support.
Revision 16, 2015-09-08 (James Jones)
- Added description section to the spec.
- Added issues 16 - 18.
Revision 17, 2015-10-02 (James Jones)
- Planes are now a property of the entire device rather than individual displays. This allows planes to be moved between multiple displays on devices that support it.
- Added a function to create a VkSurfaceKHR object describing a display plane and mode to align with the new per-platform surface creation conventions.
- Removed detailed mode timing data. It was agreed that the mode extents and refresh rate are sufficient for current use cases. Other information could be added back2 in as an extension if it is needed in the future.
- Added support for smart/persistent/buffered display devices.
Revision 18, 2015-10-26 (Ian Elliott)
- Renamed from VK_EXT_KHR_display to VK_KHR_display.
Revision 19, 2015-11-02 (James Jones)
- Updated example code to match revision 17 changes.
Revision 20, 2015-11-03 (Daniel Rakos)
- Added allocation callbacks to creation functions.
Revision 21, 2015-11-10 (Jesse Hall)
- Added VK_DISPLAY_PLANE_ALPHA_OPAQUE_BIT_KHR, and use VkDisplayPlaneAlphaFlagBitsKHR for VkDisplayPlanePropertiesKHR::alphaMode instead of VkDisplayPlaneAlphaFlagsKHR, since it only represents one mode.
- Added reserved flags bitmask to VkDisplayPlanePropertiesKHR.
- Use VkSurfaceTransformFlagBitsKHR instead of obsolete VkSurfaceTransformKHR.
- Renamed vkGetDisplayPlaneSupportedDisplaysKHR parameters for clarity.
Revision 22, 2015-12-18 (James Jones)
- Added missing "planeIndex" parameter to vkGetDisplayPlaneSupportedDisplaysKHR()
Revision 23, 2017-03-13 (James Jones)
- Closed all remaining issues. The specification and implementations have been shipping with the proposed resolutions for some time now.
- Removed the sample code and noted it has been integrated into the official Vulkan SDK cube demo.
See Also
DisplayKHR
, DisplayModeCreateFlagsKHR
,
DisplayModeCreateInfoKHR
, DisplayModeKHR
,
DisplayModeParametersKHR
, DisplayModePropertiesKHR
,
DisplayPlaneAlphaFlagBitsKHR
, DisplayPlaneAlphaFlagsKHR
,
DisplayPlaneCapabilitiesKHR
, DisplayPlanePropertiesKHR
,
DisplayPropertiesKHR
, DisplaySurfaceCreateFlagsKHR
,
DisplaySurfaceCreateInfoKHR
,
SurfaceTransformFlagsKHR
,
createDisplayModeKHR
, createDisplayPlaneSurfaceKHR
,
getDisplayModePropertiesKHR
, getDisplayPlaneCapabilitiesKHR
,
getDisplayPlaneSupportedDisplaysKHR
,
getPhysicalDeviceDisplayPlanePropertiesKHR
,
getPhysicalDeviceDisplayPropertiesKHR
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.
Synopsis
- getPhysicalDeviceDisplayPropertiesKHR :: forall io. MonadIO io => PhysicalDevice -> io (Result, "properties" ::: Vector DisplayPropertiesKHR)
- getPhysicalDeviceDisplayPlanePropertiesKHR :: forall io. MonadIO io => PhysicalDevice -> io (Result, "properties" ::: Vector DisplayPlanePropertiesKHR)
- getDisplayPlaneSupportedDisplaysKHR :: forall io. MonadIO io => PhysicalDevice -> ("planeIndex" ::: Word32) -> io (Result, "displays" ::: Vector DisplayKHR)
- getDisplayModePropertiesKHR :: forall io. MonadIO io => PhysicalDevice -> DisplayKHR -> io (Result, "properties" ::: Vector DisplayModePropertiesKHR)
- createDisplayModeKHR :: forall io. MonadIO io => PhysicalDevice -> DisplayKHR -> DisplayModeCreateInfoKHR -> ("allocator" ::: Maybe AllocationCallbacks) -> io DisplayModeKHR
- getDisplayPlaneCapabilitiesKHR :: forall io. MonadIO io => PhysicalDevice -> DisplayModeKHR -> ("planeIndex" ::: Word32) -> io DisplayPlaneCapabilitiesKHR
- createDisplayPlaneSurfaceKHR :: forall io. MonadIO io => Instance -> DisplaySurfaceCreateInfoKHR -> ("allocator" ::: Maybe AllocationCallbacks) -> io SurfaceKHR
- data DisplayPropertiesKHR = DisplayPropertiesKHR {}
- data DisplayPlanePropertiesKHR = DisplayPlanePropertiesKHR {}
- data DisplayModeParametersKHR = DisplayModeParametersKHR {}
- data DisplayModePropertiesKHR = DisplayModePropertiesKHR {}
- data DisplayModeCreateInfoKHR = DisplayModeCreateInfoKHR {}
- data DisplayPlaneCapabilitiesKHR = DisplayPlaneCapabilitiesKHR {}
- data DisplaySurfaceCreateInfoKHR = DisplaySurfaceCreateInfoKHR {}
- newtype DisplayModeCreateFlagsKHR = DisplayModeCreateFlagsKHR Flags
- newtype DisplaySurfaceCreateFlagsKHR = DisplaySurfaceCreateFlagsKHR Flags
- type DisplayPlaneAlphaFlagsKHR = DisplayPlaneAlphaFlagBitsKHR
- newtype DisplayPlaneAlphaFlagBitsKHR where
- DisplayPlaneAlphaFlagBitsKHR Flags
- pattern DISPLAY_PLANE_ALPHA_OPAQUE_BIT_KHR :: DisplayPlaneAlphaFlagBitsKHR
- pattern DISPLAY_PLANE_ALPHA_GLOBAL_BIT_KHR :: DisplayPlaneAlphaFlagBitsKHR
- pattern DISPLAY_PLANE_ALPHA_PER_PIXEL_BIT_KHR :: DisplayPlaneAlphaFlagBitsKHR
- pattern DISPLAY_PLANE_ALPHA_PER_PIXEL_PREMULTIPLIED_BIT_KHR :: DisplayPlaneAlphaFlagBitsKHR
- type KHR_DISPLAY_SPEC_VERSION = 23
- pattern KHR_DISPLAY_SPEC_VERSION :: forall a. Integral a => a
- type KHR_DISPLAY_EXTENSION_NAME = "VK_KHR_display"
- pattern KHR_DISPLAY_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a
- newtype DisplayKHR = DisplayKHR Word64
- newtype DisplayModeKHR = DisplayModeKHR Word64
- newtype SurfaceKHR = SurfaceKHR Word64
- newtype SurfaceTransformFlagBitsKHR where
- SurfaceTransformFlagBitsKHR Flags
- pattern SURFACE_TRANSFORM_IDENTITY_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_ROTATE_90_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_ROTATE_180_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_ROTATE_270_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_HORIZONTAL_MIRROR_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_HORIZONTAL_MIRROR_ROTATE_90_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_HORIZONTAL_MIRROR_ROTATE_180_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_HORIZONTAL_MIRROR_ROTATE_270_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_INHERIT_BIT_KHR :: SurfaceTransformFlagBitsKHR
- type SurfaceTransformFlagsKHR = SurfaceTransformFlagBitsKHR
Documentation
getPhysicalDeviceDisplayPropertiesKHR Source #
:: forall io. MonadIO io | |
=> PhysicalDevice |
|
-> io (Result, "properties" ::: Vector DisplayPropertiesKHR) |
vkGetPhysicalDeviceDisplayPropertiesKHR - Query information about the available displays
Description
If pProperties
is NULL
, then the number of display devices available
for physicalDevice
is returned in pPropertyCount
. Otherwise,
pPropertyCount
must point to a variable set by the user to the
number of elements in the pProperties
array, and on return the
variable is overwritten with the number of structures actually written
to pProperties
. If the value of pPropertyCount
is less than the
number of display devices for physicalDevice
, at most pPropertyCount
structures will be written. If pPropertyCount
is smaller than the
number of display devices available for physicalDevice
,
INCOMPLETE
will be returned instead of
SUCCESS
to indicate that not all the
available values were returned.
Valid Usage (Implicit)
-
physicalDevice
must be a validPhysicalDevice
handle
-
pPropertyCount
must be a valid pointer to auint32_t
value -
If the value referenced by
pPropertyCount
is not0
, andpProperties
is notNULL
,pProperties
must be a valid pointer to an array ofpPropertyCount
DisplayPropertiesKHR
structures
Return Codes
See Also
getPhysicalDeviceDisplayPlanePropertiesKHR Source #
:: forall io. MonadIO io | |
=> PhysicalDevice |
|
-> io (Result, "properties" ::: Vector DisplayPlanePropertiesKHR) |
vkGetPhysicalDeviceDisplayPlanePropertiesKHR - Query the plane properties
Description
If pProperties
is NULL
, then the number of display planes available
for physicalDevice
is returned in pPropertyCount
. Otherwise,
pPropertyCount
must point to a variable set by the user to the
number of elements in the pProperties
array, and on return the
variable is overwritten with the number of structures actually written
to pProperties
. If the value of pPropertyCount
is less than the
number of display planes for physicalDevice
, at most pPropertyCount
structures will be written.
Valid Usage (Implicit)
-
physicalDevice
must be a validPhysicalDevice
handle
-
pPropertyCount
must be a valid pointer to auint32_t
value -
If the value referenced by
pPropertyCount
is not0
, andpProperties
is notNULL
,pProperties
must be a valid pointer to an array ofpPropertyCount
DisplayPlanePropertiesKHR
structures
Return Codes
See Also
getDisplayPlaneSupportedDisplaysKHR Source #
:: forall io. MonadIO io | |
=> PhysicalDevice |
|
-> ("planeIndex" ::: Word32) |
|
-> io (Result, "displays" ::: Vector DisplayKHR) |
vkGetDisplayPlaneSupportedDisplaysKHR - Query the list of displays a plane supports
Description
If pDisplays
is NULL
, then the number of displays usable with the
specified planeIndex
for physicalDevice
is returned in
pDisplayCount
. Otherwise, pDisplayCount
must point to a variable
set by the user to the number of elements in the pDisplays
array, and
on return the variable is overwritten with the number of handles
actually written to pDisplays
. If the value of pDisplayCount
is less
than the number of display planes for physicalDevice
, at most
pDisplayCount
handles will be written. If pDisplayCount
is smaller
than the number of displays usable with the specified planeIndex
for
physicalDevice
, INCOMPLETE
will be
returned instead of SUCCESS
to indicate
that not all the available values were returned.
Valid Usage
-
planeIndex
must be less than the number of display planes supported by the device as determined by callinggetPhysicalDeviceDisplayPlanePropertiesKHR
Valid Usage (Implicit)
-
physicalDevice
must be a validPhysicalDevice
handle
-
pDisplayCount
must be a valid pointer to auint32_t
value - If
the value referenced by
pDisplayCount
is not0
, andpDisplays
is notNULL
,pDisplays
must be a valid pointer to an array ofpDisplayCount
DisplayKHR
handles
Return Codes
See Also
getDisplayModePropertiesKHR Source #
:: forall io. MonadIO io | |
=> PhysicalDevice |
|
-> DisplayKHR |
|
-> io (Result, "properties" ::: Vector DisplayModePropertiesKHR) |
vkGetDisplayModePropertiesKHR - Query the set of mode properties supported by the display
Description
If pProperties
is NULL
, then the number of display modes available
on the specified display
for physicalDevice
is returned in
pPropertyCount
. Otherwise, pPropertyCount
must point to a variable
set by the user to the number of elements in the pProperties
array,
and on return the variable is overwritten with the number of structures
actually written to pProperties
. If the value of pPropertyCount
is
less than the number of display modes for physicalDevice
, at most
pPropertyCount
structures will be written. If pPropertyCount
is
smaller than the number of display modes available on the specified
display
for physicalDevice
, INCOMPLETE
will be returned instead of SUCCESS
to
indicate that not all the available values were returned.
Valid Usage (Implicit)
-
physicalDevice
must be a validPhysicalDevice
handle
-
display
must be a validDisplayKHR
handle -
pPropertyCount
must be a valid pointer to auint32_t
value - If the
value referenced by
pPropertyCount
is not0
, andpProperties
is notNULL
,pProperties
must be a valid pointer to an array ofpPropertyCount
DisplayModePropertiesKHR
structures -
display
must have been created, allocated, or retrieved fromphysicalDevice
Return Codes
See Also
:: forall io. MonadIO io | |
=> PhysicalDevice |
|
-> DisplayKHR |
|
-> DisplayModeCreateInfoKHR |
|
-> ("allocator" ::: Maybe AllocationCallbacks) |
|
-> io DisplayModeKHR |
vkCreateDisplayModeKHR - Create a display mode
Valid Usage (Implicit)
-
physicalDevice
must be a validPhysicalDevice
handle
-
display
must be a validDisplayKHR
handle -
pCreateInfo
must be a valid pointer to a validDisplayModeCreateInfoKHR
structure - If
pAllocator
is notNULL
,pAllocator
must be a valid pointer to a validAllocationCallbacks
structure -
pMode
must be a valid pointer to aDisplayModeKHR
handle -
display
must have been created, allocated, or retrieved fromphysicalDevice
Host Synchronization
- Host access to
display
must be externally synchronized
Return Codes
See Also
AllocationCallbacks
,
DisplayKHR
, DisplayModeCreateInfoKHR
,
DisplayModeKHR
,
PhysicalDevice
getDisplayPlaneCapabilitiesKHR Source #
:: forall io. MonadIO io | |
=> PhysicalDevice |
|
-> DisplayModeKHR |
|
-> ("planeIndex" ::: Word32) |
|
-> io DisplayPlaneCapabilitiesKHR |
vkGetDisplayPlaneCapabilitiesKHR - Query capabilities of a mode and plane combination
Valid Usage (Implicit)
-
physicalDevice
must be a validPhysicalDevice
handle
-
mode
must be a validDisplayModeKHR
handle -
pCapabilities
must be a valid pointer to aDisplayPlaneCapabilitiesKHR
structure
Host Synchronization
- Host access to
mode
must be externally synchronized
Return Codes
See Also
createDisplayPlaneSurfaceKHR Source #
:: forall io. MonadIO io | |
=> Instance |
|
-> DisplaySurfaceCreateInfoKHR |
|
-> ("allocator" ::: Maybe AllocationCallbacks) |
|
-> io SurfaceKHR |
vkCreateDisplayPlaneSurfaceKHR - Create a
SurfaceKHR
structure representing a display
plane and mode
Valid Usage (Implicit)
-
instance
must be a validInstance
handle
-
pCreateInfo
must be a valid pointer to a validDisplaySurfaceCreateInfoKHR
structure - If
pAllocator
is notNULL
,pAllocator
must be a valid pointer to a validAllocationCallbacks
structure -
pSurface
must be a valid pointer to aSurfaceKHR
handle
Return Codes
See Also
AllocationCallbacks
,
DisplaySurfaceCreateInfoKHR
, Instance
,
SurfaceKHR
data DisplayPropertiesKHR Source #
VkDisplayPropertiesKHR - Structure describing an available display device
Description
Note
For devices which have no natural value to return here, implementations should return the maximum resolution supported.
Note
Persistent presents may have higher latency, and may use less power when the screen content is updated infrequently, or when only a portion of the screen needs to be updated in most frames.
See Also
Bool32
,
DisplayKHR
,
DisplayProperties2KHR
,
Extent2D
,
SurfaceTransformFlagsKHR
,
getPhysicalDeviceDisplayPropertiesKHR
DisplayPropertiesKHR | |
|
Instances
Show DisplayPropertiesKHR Source # | |
Defined in Vulkan.Extensions.VK_KHR_display showsPrec :: Int -> DisplayPropertiesKHR -> ShowS # show :: DisplayPropertiesKHR -> String # showList :: [DisplayPropertiesKHR] -> ShowS # | |
FromCStruct DisplayPropertiesKHR Source # | |
Defined in Vulkan.Extensions.VK_KHR_display | |
ToCStruct DisplayPropertiesKHR Source # | |
Defined in Vulkan.Extensions.VK_KHR_display withCStruct :: DisplayPropertiesKHR -> (Ptr DisplayPropertiesKHR -> IO b) -> IO b Source # pokeCStruct :: Ptr DisplayPropertiesKHR -> DisplayPropertiesKHR -> IO b -> IO b Source # withZeroCStruct :: (Ptr DisplayPropertiesKHR -> IO b) -> IO b Source # pokeZeroCStruct :: Ptr DisplayPropertiesKHR -> IO b -> IO b Source # cStructSize :: Int Source # | |
Zero DisplayPropertiesKHR Source # | |
Defined in Vulkan.Extensions.VK_KHR_display |
data DisplayPlanePropertiesKHR Source #
VkDisplayPlanePropertiesKHR - Structure describing display plane properties
See Also
DisplayKHR
,
DisplayPlaneProperties2KHR
,
getPhysicalDeviceDisplayPlanePropertiesKHR
DisplayPlanePropertiesKHR | |
|
Instances
data DisplayModeParametersKHR Source #
VkDisplayModeParametersKHR - Structure describing display parameters associated with a display mode
Description
Note
For example, a 60Hz display mode would report a refreshRate
of 60,000.
Valid Usage
See Also
DisplayModeCreateInfoKHR
, DisplayModePropertiesKHR
,
Extent2D
DisplayModeParametersKHR | |
|
Instances
data DisplayModePropertiesKHR Source #
VkDisplayModePropertiesKHR - Structure describing display mode properties
See Also
DisplayModeKHR
, DisplayModeParametersKHR
,
DisplayModeProperties2KHR
,
getDisplayModePropertiesKHR
DisplayModePropertiesKHR | |
|
Instances
data DisplayModeCreateInfoKHR Source #
VkDisplayModeCreateInfoKHR - Structure specifying parameters of a newly created display mode object
Valid Usage (Implicit)
See Also
DisplayModeCreateFlagsKHR
, DisplayModeParametersKHR
,
StructureType
,
createDisplayModeKHR
DisplayModeCreateInfoKHR | |
|
Instances
data DisplayPlaneCapabilitiesKHR Source #
VkDisplayPlaneCapabilitiesKHR - Structure describing capabilities of a mode and plane combination
Description
The minimum and maximum position and extent fields describe the
implementation limits, if any, as they apply to the specified display
mode and plane. Vendors may support displaying a subset of a
swapchain’s presentable images on the specified display plane. This is
expressed by returning minSrcPosition
, maxSrcPosition
,
minSrcExtent
, and maxSrcExtent
values that indicate a range of
possible positions and sizes may be used to specify the region within
the presentable images that source pixels will be read from when
creating a swapchain on the specified display mode and plane.
Vendors may also support mapping the presentable images’ content to a
subset or superset of the visible region in the specified display mode.
This is expressed by returning minDstPosition
, maxDstPosition
,
minDstExtent
and maxDstExtent
values that indicate a range of
possible positions and sizes may be used to describe the region within
the display mode that the source pixels will be mapped to.
Other vendors may support only a 1-1 mapping between pixels in the
presentable images and the display mode. This may be indicated by
returning (0,0) for minSrcPosition
, maxSrcPosition
,
minDstPosition
, and maxDstPosition
, and (display mode width, display
mode height) for minSrcExtent
, maxSrcExtent
, minDstExtent
, and
maxDstExtent
.
These values indicate the limits of the implementation’s individual
fields. Not all combinations of values within the offset and extent
ranges returned in DisplayPlaneCapabilitiesKHR
are guaranteed to be
supported. Presentation requests specifying unsupported combinations
may fail.
See Also
DisplayPlaneAlphaFlagsKHR
,
DisplayPlaneCapabilities2KHR
,
Extent2D
,
Offset2D
,
getDisplayPlaneCapabilitiesKHR
DisplayPlaneCapabilitiesKHR | |
|
Instances
data DisplaySurfaceCreateInfoKHR Source #
VkDisplaySurfaceCreateInfoKHR - Structure specifying parameters of a newly created display plane surface object
Description
Note
Creating a display surface must not modify the state of the displays, planes, or other resources it names. For example, it must not apply the specified mode to be set on the associated display. Application of display configuration occurs as a side effect of presenting to a display surface.
Valid Usage
-
planeIndex
must be less than the number of display planes supported by the device as determined by callinggetPhysicalDeviceDisplayPlanePropertiesKHR
- If
the
planeReorderPossible
member of theDisplayPropertiesKHR
structure returned bygetPhysicalDeviceDisplayPropertiesKHR
for the display corresponding todisplayMode
isTRUE
thenplaneStackIndex
must be less than the number of display planes supported by the device as determined by callinggetPhysicalDeviceDisplayPlanePropertiesKHR
; otherwiseplaneStackIndex
must equal thecurrentStackIndex
member ofDisplayPlanePropertiesKHR
returned bygetPhysicalDeviceDisplayPlanePropertiesKHR
for the display plane corresponding todisplayMode
- If
alphaMode
isDISPLAY_PLANE_ALPHA_GLOBAL_BIT_KHR
thenglobalAlpha
must be between0
and1
, inclusive -
alphaMode
must be0
or one of the bits present in thesupportedAlpha
member ofDisplayPlaneCapabilitiesKHR
returned bygetDisplayPlaneCapabilitiesKHR
for the display plane corresponding todisplayMode
- The
width
andheight
members ofimageExtent
must be less thanPhysicalDeviceLimits
::maxImageDimension2D
Valid Usage (Implicit)
-
sType
must beSTRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR
-
pNext
must beNULL
-
flags
must be0
-
displayMode
must be a validDisplayModeKHR
handle -
transform
must be a validSurfaceTransformFlagBitsKHR
value -
alphaMode
must be a validDisplayPlaneAlphaFlagBitsKHR
value
See Also
DisplayModeKHR
,
DisplayPlaneAlphaFlagBitsKHR
, DisplaySurfaceCreateFlagsKHR
,
Extent2D
,
StructureType
,
SurfaceTransformFlagBitsKHR
,
createDisplayPlaneSurfaceKHR
DisplaySurfaceCreateInfoKHR | |
|
Instances
newtype DisplayModeCreateFlagsKHR Source #
VkDisplayModeCreateFlagsKHR - Reserved for future use
Description
DisplayModeCreateFlagsKHR
is a bitmask type for setting a mask, but is
currently reserved for future use.
See Also
Instances
newtype DisplaySurfaceCreateFlagsKHR Source #
VkDisplaySurfaceCreateFlagsKHR - Reserved for future use
Description
DisplaySurfaceCreateFlagsKHR
is a bitmask type for setting a mask, but
is currently reserved for future use.
See Also
Instances
newtype DisplayPlaneAlphaFlagBitsKHR Source #
VkDisplayPlaneAlphaFlagBitsKHR - Alpha blending type
See Also
pattern DISPLAY_PLANE_ALPHA_OPAQUE_BIT_KHR :: DisplayPlaneAlphaFlagBitsKHR |
|
pattern DISPLAY_PLANE_ALPHA_GLOBAL_BIT_KHR :: DisplayPlaneAlphaFlagBitsKHR |
|
pattern DISPLAY_PLANE_ALPHA_PER_PIXEL_BIT_KHR :: DisplayPlaneAlphaFlagBitsKHR |
|
pattern DISPLAY_PLANE_ALPHA_PER_PIXEL_PREMULTIPLIED_BIT_KHR :: DisplayPlaneAlphaFlagBitsKHR |
|
Instances
type KHR_DISPLAY_SPEC_VERSION = 23 Source #
pattern KHR_DISPLAY_SPEC_VERSION :: forall a. Integral a => a Source #
type KHR_DISPLAY_EXTENSION_NAME = "VK_KHR_display" Source #
pattern KHR_DISPLAY_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #
newtype DisplayKHR Source #
VkDisplayKHR - Opaque handle to a display object
See Also
DisplayPlanePropertiesKHR
,
DisplayPropertiesKHR
,
acquireWinrtDisplayNV
,
acquireXlibDisplayEXT
,
createDisplayModeKHR
,
displayPowerControlEXT
,
getDisplayModeProperties2KHR
,
getDisplayModePropertiesKHR
,
getDisplayPlaneSupportedDisplaysKHR
,
getRandROutputDisplayEXT
,
getWinrtDisplayNV
,
registerDisplayEventEXT
,
releaseDisplayEXT
Instances
newtype DisplayModeKHR Source #
VkDisplayModeKHR - Opaque handle to a display mode object
See Also
DisplayModePropertiesKHR
,
DisplayPlaneInfo2KHR
,
DisplaySurfaceCreateInfoKHR
,
createDisplayModeKHR
,
getDisplayPlaneCapabilitiesKHR
Instances
newtype SurfaceKHR Source #
VkSurfaceKHR - Opaque handle to a surface object
Description
The VK_KHR_surface
extension declares the SurfaceKHR
object, and
provides a function for destroying SurfaceKHR
objects. Separate
platform-specific extensions each provide a function for creating a
SurfaceKHR
object for the respective platform. From the application’s
perspective this is an opaque handle, just like the handles of other
Vulkan objects.
See Also
PhysicalDeviceSurfaceInfo2KHR
,
SwapchainCreateInfoKHR
,
createAndroidSurfaceKHR
,
createDirectFBSurfaceEXT
,
createDisplayPlaneSurfaceKHR
,
createHeadlessSurfaceEXT
,
createIOSSurfaceMVK
,
createImagePipeSurfaceFUCHSIA
,
createMacOSSurfaceMVK
,
createMetalSurfaceEXT
,
createStreamDescriptorSurfaceGGP
,
createViSurfaceNN
,
createWaylandSurfaceKHR
,
createWin32SurfaceKHR
,
createXcbSurfaceKHR
,
createXlibSurfaceKHR
,
destroySurfaceKHR
,
getDeviceGroupSurfacePresentModesKHR
,
getPhysicalDevicePresentRectanglesKHR
,
getPhysicalDeviceSurfaceCapabilities2EXT
,
getPhysicalDeviceSurfaceCapabilitiesKHR
,
getPhysicalDeviceSurfaceFormatsKHR
,
getPhysicalDeviceSurfacePresentModesKHR
,
getPhysicalDeviceSurfaceSupportKHR
Instances
newtype SurfaceTransformFlagBitsKHR Source #
VkSurfaceTransformFlagBitsKHR - presentation transforms supported on a device
See Also
CommandBufferInheritanceRenderPassTransformInfoQCOM
,
CopyCommandTransformInfoQCOM
,
DisplaySurfaceCreateInfoKHR
,
RenderPassTransformBeginInfoQCOM
,
SurfaceCapabilities2EXT
,
SurfaceCapabilitiesKHR
, SurfaceTransformFlagsKHR
,
SwapchainCreateInfoKHR