Vulkan-Docs/doc/specs/vulkan/appendices/VK_EXT_sample_locations.txt

92 lines
3.2 KiB
Plaintext
Raw Normal View History

Change log for September 5, 2017 Vulkan 1.0.60 spec update: * Bump API patch number and header version number to 60 for this update. Github Issues: * Document that <<queries-timestamps, Timestamp Queries>> can only be meaningfully compared when they are written from the same queue (public issue 216). * Document that the `<extension>` tag `type` attribute is required for non-disabled extensions (derived from, but does not close public issue 354). * Clean up registry schema length attribute descriptions to be consistent and correct (public issue 555). Internal Issues: * Replace as much of the hand-written extension appendix metadata as possible with asciidoc includes generated from corresponding attributes of +vk.xml+, and enhance the style guide to match. This avoids inconsistencies between +vk.xml+ and the appendices, and produces a more uniform style (internal issue 137). * Remove the generated extDependency.{py,sh} files from the tree and create them dynamically on demand instead, reducing merge conflicts (internal issue 713). * Add a prototype tool for generating in-place difference markup for sections guarded by asciidoc conditionals, and new syntax for open blocks to support it (internal issue 833). * Remove unnecessary restriction of etext:*SYNC_FD_BIT_KHR external handle types to the same physical device in the slink:VkPhysicalDeviceIDPropertiesKHR, flink:VkImportMemoryWin32HandleInfoKHR, slink:VkImportFenceWin32HandleInfoKHR, slink:VkImportFenceFdInfoKHR, slink:VkImportSemaphoreWin32HandleInfoKHR, slink:VkImportSemaphoreFdInfoKHR <<external-memory-handle-types-compatibility, External memory handle types compatibility>>, <<external-semaphore-handle-types-compatibility, External semaphore handle types compatibility>>, and <<external-fence-handle-types-compatibility, External fence handle types compatibility>> sections (internal issue 956). Other Issues: * Remove dependency of +VK_KHX_device_group+ on +VK_KHR_swapchain+ (there is an interaction, but not a strict dependency), and add a new `extension` attribute to the `<require` XML tag to allow classifying a subset of interfaces of an extension as requiring another extension. Update the registry schema and documentation accordingly. New Extensions: * `VK_AMD_shader_fragment_mask` (and related `GL_AMD_shader_fragment_mask` GLSL extension) * `VK_EXT_sample_locations` * `VK_EXT_validation_cache`
2017-09-04 10:06:55 +00:00
include::meta/VK_EXT_sample_locations.txt[]
*Last Modified Date*::
2017-08-02
*Contributors*::
- Mais Alnasser, AMD
- Matthaeus G.
Chajdas, AMD
- Maciej Jesionowski, AMD
- Daniel Rakos, AMD
- Slawomir Grajewski, Intel
- Jeff Bolz, NVIDIA
- Bill Licea-Kane, Qualcomm
This extension allows an application to modify the locations of samples
within a pixel used in rasterization.
Additionally, it allows applications to specify different sample locations
for each pixel in a group of adjacent pixels, which can: increase
antialiasing quality (particularly if a custom resolve shader is used that
takes advantage of these different locations).
It is common for implementations to optimize the storage of depth values by
storing values that can: be used to reconstruct depth at each sample
location, rather than storing separate depth values for each sample.
For example, the depth values from a single triangle may: be represented
using plane equations.
When the depth value for a sample is needed, it is automatically evaluated
at the sample location.
Modifying the sample locations causes the reconstruction to no longer
evaluate the same depth values as when the samples were originally
generated, thus the depth aspect of a depth/stencil attachment must: be
cleared before rendering to it using different sample locations.
Some implementations may: need to evaluate depth image values while
performing image layout transitions.
To accommodate this, instances of the slink:VkSampleLocationsInfoEXT
structure can: be specified for each situation where an explicit or
automatic layout transition has to take place.
slink:VkSampleLocationsInfoEXT can: be chained from
slink:VkImageMemoryBarrier structures to provide sample locations for layout
transitions performed by flink:vkCmdWaitEvents and
flink:VkCmdPipelineBarrier calls, and
slink:VkRenderPassSampleLocationsBeginInfoEXT can: be chained from
slink:VkRenderPassBeginInfo to provide sample locations for layout
transitions performed implicitly by a render pass instance.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkImageCreateFlagBits:
** ename:VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT
** ename:VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT
** ename:VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLE_LOCATIONS_PROPERTIES_EXT
** ename:VK_STRUCTURE_TYPE_MULTISAMPLE_PROPERTIES_EXT
* Extending elink:VkDynamicState:
** ename:VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT
=== New Enums
None.
=== New Structures
* slink:VkSampleLocationEXT
* slink:VkSampleLocationsInfoEXT
* slink:VkAttachmentSampleLocationsEXT
* slink:VkSubpassSampleLocationsEXT
* slink:VkRenderPassSampleLocationsBeginInfoEXT
* slink:VkPipelineSampleLocationsStateCreateInfoEXT
* slink:VkPhysicalDeviceSampleLocationsPropertiesEXT
* slink:VkMultisamplePropertiesEXT
=== New Functions
* flink:vkCmdSetSampleLocationsEXT
* flink:vkGetPhysicalDeviceMultisamplePropertiesEXT
=== Issues
None.
=== Version History
* Revision 1, 2017-08-02 (Daniel Rakos)
- Internal revisions