Permalink
Browse files

Change log for November 25, 2018 Vulkan 1.1.94 spec update:

  * Update release number to 94.

Public Issues:

  * Use the terms "`texel block`" and "`texel block size`" instead of "`data
    element`" and "`element size`", and define "`element`" as an array slot.
    In addition to the terminology changes, retitled the <<texel-block-size,
    Representation and Texel Block Size>> section and added texel block size
    / no. of texels/block information to the
    <<features-formats-compatibility, Compatible Formats>> table. There is
    some additional work underway to make sure the compatibility language
    makes sense for all of uncompressed, compressed, and multiplanar formats
    (public issue 763).
  * Cleanup `VK_NV_ray_tracing` language (public issues 858, 859).

Internal Issues:

  * Specify in <<shaders-invocationgroups, Invocation and Derivative
    Groups>> and <<textures-output-format-conversion, Texel Output Format
    Conversion>> that derivative groups are quads when code:SubgroupSize >=
    4 (internal issue 1390).
  * Make the type of slink:VkDescriptorUpdateTemplateCreateInfo::pNext
    `const` following pattern for the other stext:Vk*CreateInfo structures
    (internal issue 1459).
  * Specify that flink:vkCmdClearAttachments executes as a drawing command,
    rather than a transfer command (internal issue 1463).
  * Update `VK_NV_ray_tracing` to use code:InstanceId instead of
    code:InstanceIndex.

New Extensions:

  * `VK_KHR_swapchain_mutable_format`
  * `VK_EXT_fragment_density_map`
  • Loading branch information...
Jon Leech
Jon Leech committed Nov 26, 2018
1 parent 256a1ef commit c24b84795f6c083df107d8639286881a23894679
@@ -115,7 +115,7 @@ VERBOSE =
# ADOCOPTS options for asciidoc->HTML5 output

NOTEOPTS = -a editing-notes -a implementation-guide
PATCHVERSION = 93
PATCHVERSION = 94
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
SPECREVISION = 1.1.$(PATCHVERSION)
else
@@ -0,0 +1,89 @@
include::meta/VK_EXT_fragment_density_map.txt[]

*Last Modified Date*::
2018-09-25
*Interactions and External Dependencies*::
- This extension requires the
https://www.khronos.org/registry/spir-v/extensions/EXT/SPV_EXT_fragment_invocation_density.html[+SPV_EXT_fragment_invocation_density+]
SPIR-V extension.
*Contributors*::
- Matthew Netsch, Qualcomm Technologies, Inc.
- Robert VanReenen, Qualcomm Technologies, Inc.
- Jonathan Wicks, Qualcomm Technologies, Inc.
- Tate Hornbeck, Qualcomm Technologies, Inc.
- Sam Holmes, Qualcomm Technologies, Inc.
- Jeff Leger, Qualcomm Technologies, Inc.
- Jan-Harald Fredriksen, ARM
- Jeff Bolz, NVIDIA
- Pat Brown, NVIDIA
- Daniel Rakos, AMD
- Piers Daniell, NVIDIA

This extension allows an application to specify areas of the render target
where the fragment shader may be invoked fewer times.
These fragments are broadcasted out to multiple pixels to cover the render
target.

The primary use of this extension is to reduce workloads in areas where
lower quality may not be perceived such as the distorted edges of a lens or
the periphery of a user's gaze.

=== New Object Types

None.

=== New Enum Constants

* Extending elink:VkAccessFlagBits:
** ename:VK_ACCESS_FRAGMENT_DENSITY_MAP_READ_BIT_EXT
* Extending elink:VkFormatFeatureFlagBits:
** ename:VK_FORMAT_FEATURE_FRAGMENT_DENSITY_MAP_BIT_EXT
* Extending elink:VkImageCreateFlagBits:
** ename:VK_IMAGE_CREATE_SUBSAMPLED_BIT_EXT
* Extending elink:VkImageLayout:
** ename:VK_IMAGE_LAYOUT_FRAGMENT_DENSITY_MAP_OPTIMAL_EXT
* Extending elink:VkImageUsageFlagBits:
** ename:VK_IMAGE_USAGE_FRAGMENT_DENSITY_MAP_BIT_EXT
* Extending elink:VkImageViewCreateFlagBits:
** ename:VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DYNAMIC_BIT_EXT
* Extending elink:VkPipelineStageFlagBits:
** ename:VK_PIPELINE_STAGE_FRAGMENT_DENSITY_PROCESS_BIT_EXT
* Extending elink:VkSamplerCreateFlagBits:
** ename:VK_SAMPLER_CREATE_SUBSAMPLED_BIT_EXT
** ename:VK_SAMPLER_CREATE_SUBSAMPLED_COARSE_RECONSTRUCTION_BIT_EXT
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_FEATURES_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_PROPERTIES_EXT
** ename:VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_CREATE_INFO_EXT

=== New Enums

None.

=== New Structures

* slink:VkPhysicalDeviceFragmentDensityMapFeaturesEXT
* slink:VkPhysicalDeviceFragmentDensityMapPropertiesEXT
* slink:VkRenderPassFragmentDensityMapCreateInfoEXT

=== New Functions

None.

=== New or Modified Built-In Variables

* <<interfaces-builtin-variables-fraginvocationcount,code:FragInvocationCountEXT>>
* <<interfaces-builtin-variables-fragsize,code:FragSizeEXT>>

=== New Variable Decorations

None.

=== New SPIR-V Capabilities

* <<spirvenv-capabilities-table-fragmentdensity,FragmentDensityEXT>>

=== Version History

* Revision 1, 2018-09-25 (Matthew Netsch)
- Initial version
@@ -0,0 +1,82 @@
// Copyright (c) 2014-2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/

include::meta/VK_KHR_swapchain_mutable_format.txt[]

*Last Modified Date*::
2018-03-28
*IP Status*::
No known IP claims.
*Contributors*::
- Jason Ekstrand, Intel
- Jan-Harald Fredriksen, ARM
- Jesse Hall, Google
- Daniel Rakos, AMD
- Ray Smith, ARM

=== Short Description

Allows processing of swapchain images as different formats to that used by
the window system, which is particularly useful for switching between sRGB
and linear RGB formats.

=== Description

This extension adds a new swapchain creation flag that enables creating
image views from presentable images with a different format than the one
used to create the swapchain.

=== New Object Types

None.

=== New Enum Constants

* Extending elink:VkSwapchainCreateFlagBitsKHR:
** ename:VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR

=== New Enums

None.

=== New Structures

None.

=== New Functions

None.

=== Issues

1) Are there any new capabilities needed?

*RESOLVED*: No.
It is expected that all implementations exposing this extension support
swapchain image format mutability.

2) Do we need a separate etext:VK_SWAPCHAIN_CREATE_EXTENDED_USAGE_BIT_KHR?

*RESOLVED*: No.
This extension requires `VK_KHR_maintenance2` and presentable images of
swapchains created with ename:VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR are
created internally in a way equivalent to specifying both
ename:VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT and
ename:VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR.

3) Do we need a separate structure to allow specifying an image format list
for swapchains?

*RESOLVED*: No.
We simply use the same slink:VkImageFormatListCreateInfoKHR structure
introduced by `VK_KHR_image_format_list`.
The structure is required to be included in the pname:pNext chain of
slink:VkSwapchainCreateInfoKHR for swapchains created with
ename:VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR.


=== Version History

* Revision 1, 2018-03-28 (Daniel Rakos)
- Internal revisions.
@@ -1,7 +1,7 @@
include::meta/VK_NV_ray_tracing.txt[]

*Last Modified Date*::
2018-09-11
2018-11-20

*Interactions and External Dependencies*::
- This extension requires the
@@ -141,12 +141,12 @@ This extension adds support for the following SPIR-V extension in Vulkan:
* <<interfaces-builtin-variables-raytmin,code:RayTminNV>>
* <<interfaces-builtin-variables-raytmax,code:RayTmaxNV>>
* <<interfaces-builtin-variables-instancecustomindex,code:InstanceCustomIndexNV>>
* <<interfaces-builtin-variables-instanceid,code:InstanceId>>
* <<interfaces-builtin-variables-objecttoworld,code:ObjectToWorldNV>>
* <<interfaces-builtin-variables-worldtoobject,code:WorldToObjectNV>>
* <<interfaces-builtin-variables-hitt,code:HitTNV>>
* <<interfaces-builtin-variables-hitkind,code:HitKindNV>>
* <<interfaces-builtin-variables-incomingrayflags,code:IncomingRayFlagsNV>>
* (modified)code:InstanceIndex
* (modified)code:PrimitiveId

=== New SPIR-V Capabilities
@@ -190,3 +190,8 @@ void main()

* Revision 1, 2018-09-11 (Robert Stepinski, Nuno Subtil, Eric Werness)
- Internal revisions
* Revision 2, 2018-10-19 (Eric Werness)
- rename to VK_NV_ray_tracing, add support for callables.
- too many updates to list
* Revision 3, 2018-11-20 (Daniel Koch)
- update to use InstanceId instead of InstanceIndex as implemented.
@@ -184,32 +184,31 @@ the same footprint image texels.
Techniques can be used to reduce the number of atomic operations performed
when accumulating coverage include:

* Have logic that detects returned footprints where all components of the
returned offset vector are zero.
In that case, the mask returned by the footprint function is guaranteed to
be aligned with the footprint image texels and affects only a single
footprint image texel.

* Have fragment shaders communicate using built-in functions from the
`VK_NV_shader_subgroup_partitioned` extension or other shader subgroup
extensions.
If you have multiple invocations in a subgroup that need to update the
same texel (x,y) in the footprint image, compute an aggregate footprint
mask across all invocations in the subgroup updating that texel and have a
single invocation perform an atomic operation using that aggregate mask.

* When the returned footprint spans multiple texels in the footprint image,
each invocation need to perform four atomic operations.
In the previous issue, we had an example that computed separate masks for
"`topLeft`", "`topRight`", "`bottomLeft`", and "`bottomRight`".
When the invocations in a subgroup have good locality, it might be the
case the "`top left`" for some invocations might refer to footprint image
texel (10,10), while neighbors might have their "`top left`" texels at
(11,10), (10,11), and (11,11).
If you compute separate masks for even/odd x and y values instead of
left/right or top/bottom, the "`odd/odd`" mask for all invocations in the
subgroup hold coverage for footprint image texel (11,11), which can be
updated by a single atomic operation for the entire subgroup.
* Have logic that detects returned footprints where all components of the
returned offset vector are zero.
In that case, the mask returned by the footprint function is guaranteed
to be aligned with the footprint image texels and affects only a single
footprint image texel.
* Have fragment shaders communicate using built-in functions from the
`VK_NV_shader_subgroup_partitioned` extension or other shader subgroup
extensions.
If you have multiple invocations in a subgroup that need to update the
same texel (x,y) in the footprint image, compute an aggregate footprint
mask across all invocations in the subgroup updating that texel and have
a single invocation perform an atomic operation using that aggregate
mask.
* When the returned footprint spans multiple texels in the footprint
image, each invocation need to perform four atomic operations.
In the previous issue, we had an example that computed separate masks
for "`topLeft`", "`topRight`", "`bottomLeft`", and "`bottomRight`".
When the invocations in a subgroup have good locality, it might be the
case the "`top left`" for some invocations might refer to footprint
image texel (10,10), while neighbors might have their "`top left`"
texels at (11,10), (10,11), and (11,11).
If you compute separate masks for even/odd x and y values instead of
left/right or top/bottom, the "`odd/odd`" mask for all invocations in
the subgroup hold coverage for footprint image texel (11,11), which can
be updated by a single atomic operation for the entire subgroup.

=== Examples

@@ -37,12 +37,11 @@ That extension provides two fragment shader variable decorations that allow
fragment shaders to determine the shading rate used for processing the
fragment:

* code:FragmentSizeNV, which indicates the width and height of the set of
pixels processed by the fragment shader.

* code:InvocationsPerPixel, which indicates the maximum number of fragment
shader invocations that could be spawned for the pixel(s) covered by the
fragment.
* code:FragmentSizeNV, which indicates the width and height of the set of
pixels processed by the fragment shader.
* code:InvocationsPerPixel, which indicates the maximum number of fragment
shader invocations that could be spawned for the pixel(s) covered by the
fragment.

When using SPIR-V in conjunction with the OpenGL Shading Language (GLSL),
the fragment shader capabilities are provided by the
@@ -57,30 +56,24 @@ None.
=== New Enum Constants

* Extending elink:VkStructureType:

** ename:VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SHADING_RATE_IMAGE_STATE_CREATE_INFO_NV
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_FEATURES_NV
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_PROPERTIES_NV
** ename:VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_COARSE_SAMPLE_ORDER_STATE_CREATE_INFO_NV

* Extending elink:VkImageLayout:

** ename:VK_IMAGE_LAYOUT_SHADING_RATE_OPTIMAL_NV

* Extending elink:VkDynamicState:

** ename:VK_DYNAMIC_STATE_VIEWPORT_SHADING_RATE_PALETTE_NV

* Extending elink:VkAccessFlagBits:

** ename:VK_ACCESS_SHADING_RATE_IMAGE_READ_BIT_NV

* Extending elink:VkImageUsageFlagBits:

** ename:VK_IMAGE_USAGE_SHADING_RATE_IMAGE_BIT_NV

* Extending elink:VkPipelineStageFlagBits

** ename:VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV

=== New Enums
@@ -417,10 +417,11 @@ Dynamically Uniform::
See _Dynamically Uniform_ in section 2.2 "`Terms`" of the
<<spirv-spec,Khronos SPIR-V Specification>>.

Element Size::
The size (in bytes) used to store one element of an uncompressed format
or the size (in bytes) used to store one block of a block-compressed
format.
Element::
Arrays are composed of multiple elements, where each element exists at a
unique index within that array.
Used primarily to describe data passed to or returned from the Vulkan
API.

Explicitly-Enabled Layer::
A layer enabled by the application by adding it to the enabled layer
@@ -510,6 +511,17 @@ Fragment::
Fragment Area::
The width and height, in pixels, of a fragment.

ifdef::VK_EXT_fragment_density_map[]
[[glossary-fragment-density]]
Fragment Density::
The ratio of fragments per framebuffer area in the x and y direction.

[[glossary-fragment-density-texel-size]]
Fragment Density Texel Size::
The [eq]#(w,h)# framebuffer region in pixels that each texel in a
fragment density map applies to.
endif::VK_EXT_fragment_density_map[]

Fragment Input Attachment Interface::
Variables with code:UniformConstant storage class and a decoration of
code:InputAttachmentIndex that are statically used by a fragment
@@ -963,7 +975,7 @@ Ownership (Resource)::
to that resource is well-defined for access by that entity.

Packed Format::
A format whose components are stored as a single data element in memory,
A format whose components are stored as a single texel block in memory,
with their relative locations defined within that element.

ifdef::VK_NV_geometry_shader_passthrough[]
@@ -1315,9 +1327,8 @@ endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]

Size-Compatible Image Formats::
When a compressed image format and an uncompressed image format are
size-compatible, it means that the element size of the uncompressed
format must: equal the element size (compressed texel block size) of the
compressed format.
size-compatible, it means that the texel block size of the uncompressed
format must: equal the texel block size of the compressed format.

Sparse Block::
An element of a sparse resource that can be independently bound to
@@ -1393,6 +1404,15 @@ Subset (Self-Dependency)::
each contain a subset of the bits set in the identically named mask in
the self-dependency.

Texel Block::
A single addressable element of an image with an uncompressed
elink:VkFormat, or a single compressed block of an image with a
compressed elink:VkFormat.

Texel Block Size::
The size (in bytes) used to store a texel block of a compressed or
uncompressed image.

Texel Coordinate System::
One of three coordinate systems (normalized, unnormalized, integer) that
define how texel coordinates are interpreted in an image or a specific
Oops, something went wrong.

0 comments on commit c24b847

Please sign in to comment.