| Safe Haskell | None |
|---|---|
| Language | Haskell2010 |
Vulkan.Extensions.VK_EXT_hdr_metadata
Description
Name
VK_EXT_hdr_metadata - device extension
VK_EXT_hdr_metadata
- Name String
VK_EXT_hdr_metadata
- Extension Type
- Device extension
- Registered Extension Number
- 106
- Revision
- 2
- Extension and Version Dependencies
- Requires Vulkan 1.0
- Requires
VK_KHR_swapchain
- Contact
- Courtney Goeltzenleuchter @courtney-g%0A<<Here describe the issue or question you have about the VK_EXT_hdr_metadata extension> >
Other Extension Metadata
- Last Modified Date
- 2018-12-19
- IP Status
- No known IP claims.
- Contributors
- Courtney Goeltzenleuchter, Google
Description
This extension defines two new structures and a function to assign SMPTE
(the Society of Motion Picture and Television Engineers) 2086 metadata
and CTA (Consumer Technology Association) 861.3 metadata to a swapchain.
The metadata includes the color primaries, white point, and luminance
range of the reference monitor, which all together define the color
volume that contains all the possible colors the reference monitor can
produce. The reference monitor is the display where creative work is
done and creative intent is established. To preserve such creative
intent as much as possible and achieve consistent color reproduction on
different viewing displays, it is useful for the display pipeline to
know the color volume of the original reference monitor where content
was created or tuned. This avoids performing unnecessary mapping of
colors that are not displayable on the original reference monitor. The
metadata also includes the maxContentLightLevel and
maxFrameAverageLightLevel as defined by CTA 861.3.
While the general purpose of the metadata is to assist in the transformation between different color volumes of different displays and help achieve better color reproduction, it is not in the scope of this extension to define how exactly the metadata should be used in such a process. It is up to the implementation to determine how to make use of the metadata.
New Commands
New Structures
New Enum Constants
Issues
1) Do we need a query function?
PROPOSED: No, Vulkan does not provide queries for state that the application can track on its own.
2) Should we specify default if not specified by the application?
PROPOSED: No, that leaves the default up to the display.
Version History
Revision 1, 2016-12-27 (Courtney Goeltzenleuchter)
- Initial version
Revision 2, 2018-12-19 (Courtney Goeltzenleuchter)
- Correct implicit validity for VkHdrMetadataEXT structure
See Also
HdrMetadataEXT, XYColorEXT, setHdrMetadataEXT
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
- setHdrMetadataEXT :: forall io. MonadIO io => Device -> ("swapchains" ::: Vector SwapchainKHR) -> ("metadata" ::: Vector HdrMetadataEXT) -> io ()
- data XYColorEXT = XYColorEXT {}
- data HdrMetadataEXT = HdrMetadataEXT {}
- type EXT_HDR_METADATA_SPEC_VERSION = 2
- pattern EXT_HDR_METADATA_SPEC_VERSION :: forall a. Integral a => a
- type EXT_HDR_METADATA_EXTENSION_NAME = "VK_EXT_hdr_metadata"
- pattern EXT_HDR_METADATA_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a
- newtype SwapchainKHR = SwapchainKHR Word64
Documentation
Arguments
| :: forall io. MonadIO io | |
| => Device |
|
| -> ("swapchains" ::: Vector SwapchainKHR) |
|
| -> ("metadata" ::: Vector HdrMetadataEXT) |
|
| -> io () |
vkSetHdrMetadataEXT - Set Hdr metadata
Valid Usage (Implicit)
-
devicemust be a validDevicehandle
-
pSwapchainsmust be a valid pointer to an array ofswapchainCountvalidSwapchainKHRhandles -
pMetadatamust be a valid pointer to an array ofswapchainCountvalidHdrMetadataEXTstructures -
swapchainCountmust be greater than0 - Both of
device, and the elements ofpSwapchainsmust have been created, allocated, or retrieved from the sameInstance
See Also
data XYColorEXT Source #
Constructors
| XYColorEXT | |
Instances
data HdrMetadataEXT Source #
VkHdrMetadataEXT - Specify Hdr metadata
Valid Usage (Implicit)
Note
The validity and use of this data is outside the scope of Vulkan.
See Also
VK_EXT_hdr_metadata,
StructureType, XYColorEXT,
setHdrMetadataEXT
Constructors
| HdrMetadataEXT | |
Fields
| |
Instances
type EXT_HDR_METADATA_SPEC_VERSION = 2 Source #
pattern EXT_HDR_METADATA_SPEC_VERSION :: forall a. Integral a => a Source #
type EXT_HDR_METADATA_EXTENSION_NAME = "VK_EXT_hdr_metadata" Source #
pattern EXT_HDR_METADATA_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #
newtype SwapchainKHR Source #
VkSwapchainKHR - Opaque handle to a swapchain object
Description
A swapchain is an abstraction for an array of presentable images that
are associated with a surface. The presentable images are represented by
Image objects created by the platform. One image
(which can be an array image for multiview/stereoscopic-3D surfaces)
is displayed at a time, but multiple images can be queued for
presentation. An application renders to the image, and then queues the
image for presentation to the surface.
A native window cannot be associated with more than one non-retired swapchain at a time. Further, swapchains cannot be created for native windows that have a non-Vulkan graphics API surface associated with them.
Note
The presentation engine is an abstraction for the platform’s compositor or display engine.
The presentation engine may be synchronous or asynchronous with respect to the application and/or logical device.
Some implementations may use the device’s graphics queue or dedicated presentation hardware to perform presentation.
The presentable images of a swapchain are owned by the presentation
engine. An application can acquire use of a presentable image from the
presentation engine. Use of a presentable image must occur only after
the image is returned by
acquireNextImageKHR, and before it
is released by queuePresentKHR.
This includes transitioning the image layout and rendering commands.
An application can acquire use of a presentable image with
acquireNextImageKHR. After
acquiring a presentable image and before modifying it, the application
must use a synchronization primitive to ensure that the presentation
engine has finished reading from the image. The application can then
transition the image’s layout, queue rendering commands to it, etc.
Finally, the application presents the image with
queuePresentKHR, which releases the
acquisition of the image.
The presentation engine controls the order in which presentable images are acquired for use by the application.
Note
This allows the platform to handle situations which require out-of-order return of images after presentation. At the same time, it allows the application to generate command buffers referencing all of the images in the swapchain at initialization time, rather than in its main loop.
See Also
VK_KHR_swapchain,
AcquireNextImageInfoKHR,
BindImageMemorySwapchainInfoKHR,
ImageSwapchainCreateInfoKHR,
PresentInfoKHR,
SwapchainCreateInfoKHR,
acquireFullScreenExclusiveModeEXT,
acquireNextImageKHR,
createSharedSwapchainsKHR,
createSwapchainKHR,
destroySwapchainKHR,
getPastPresentationTimingGOOGLE,
getRefreshCycleDurationGOOGLE,
getSwapchainCounterEXT,
getSwapchainImagesKHR,
getSwapchainStatusKHR,
releaseFullScreenExclusiveModeEXT,
setHdrMetadataEXT,
setLocalDimmingAMD,
waitForPresentKHR
Constructors
| SwapchainKHR Word64 |