Skip to content
Permalink
Browse files

Change log for September 8, 2018 Vulkan 1.1.84 spec update:

  * Update release number to 84.

Public Issues:

  * Fix code sample in the `<<VK_EXT_debug_utils>>` extension (public issue
    751).
  * Fix misleading comment in `vk.xml` for
    slink:VkDescriptorBufferInfo::pname:buffer (public pull request 762).
  * Fix formatting of deprecation attributes in schema doc (public pull
    request 767).
  * Change `can` to `may` in the description of
    elink:VkSparseImageFormatFlagBits, which are return values from queries
    (public pull request 768).
  * Prettify generated contact list in extension appendices, adding logos
    and a New Issue link (public pull request 770).
  * Enable sRGB conversion based on the image view format, not the image
    format, in the <<textures-format-conversion, Format Conversion>> section
    (public pull request 773).
  * Fix typo in equation in the <<primsrast-lines-basic, Basic Line Segment
    Rasterization>> section (public pull request 780).
  * Fix special characters in GitHub contacts links (public pull request
    783).
  * Make clean_pdf target remove pdf folder (public pull request 784).
  * Fix styleguide bad markup of block continuation (public pull request
    792).

Other Issues:

  * Allow a zero vertex attribute divisor in the
    `<<VK_EXT_vertex_attribute_divisor>>` extension, exposed via the
    slink:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT feature.
  * Add missing `structextends="VkDeviceCreateInfo"` to
    slink:VkPhysicalDeviceShaderDrawParameterFeatures and
    slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT.

New Extensions:

  * `VK_KHR_memory_model`
  * `VK_EXT_astc_decode_mode`
  * `VK_EXT_inline_uniform_block`
  • Loading branch information...
oddhack committed Sep 8, 2018
1 parent 89155fa commit adadfce8a3610c026e56d2e026c0c6387e2bbdad
@@ -8,6 +8,51 @@ public pull requests that have been accepted.

-----------------------------------------------------

Change log for September 8, 2018 Vulkan 1.1.84 spec update:

* Update release number to 84.

Public Issues:

* Fix code sample in the `<<VK_EXT_debug_utils>>` extension (public issue
751).
* Fix misleading comment in `vk.xml` for
slink:VkDescriptorBufferInfo::pname:buffer (public pull request 762).
* Fix formatting of deprecation attributes in schema doc (public pull
request 767).
* Change `can` to `may` in the description of
elink:VkSparseImageFormatFlagBits, which are return values from queries
(public pull request 768).
* Prettify generated contact list in extension appendices, adding logos
and a New Issue link (public pull request 770).
* Enable sRGB conversion based on the image view format, not the image
format, in the <<textures-format-conversion, Format Conversion>> section
(public pull request 773).
* Fix typo in equation in the <<primsrast-lines-basic, Basic Line Segment
Rasterization>> section (public pull request 780).
* Fix special characters in GitHub contacts links (public pull request
783).
* Make clean_pdf target remove pdf folder (public pull request 784).
* Fix styleguide bad markup of block continuation (public pull request
792).

Other Issues:

* Allow a zero vertex attribute divisor in the
`<<VK_EXT_vertex_attribute_divisor>>` extension, exposed via the
slink:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT feature.
* Add missing `structextends="VkDeviceCreateInfo"` to
slink:VkPhysicalDeviceShaderDrawParameterFeatures and
slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT.

New Extensions:

* `VK_KHR_memory_model`
* `VK_EXT_astc_decode_mode`
* `VK_EXT_inline_uniform_block`

-----------------------------------------------------

Change log for August 13, 2018 Vulkan 1.1.83 spec update:

* Update release number to 83.
@@ -107,7 +107,7 @@ VERBOSE =
# EXTRAATTRIBS sets additional attributes, if passed to make
# ADOCOPTS options for asciidoc->HTML5 output
NOTEOPTS = -a editing-notes -a implementation-guide
PATCHVERSION = 83
PATCHVERSION = 84
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
SPECREVISION = 1.1.$(PATCHVERSION)
else
@@ -0,0 +1,113 @@
// Copyright (c) 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_EXT_astc_decode_mode.txt[]

Last Modified Date::
2018-08-07
Contributors::
- Jan-Harald Fredriksen, Arm

The existing specification requires that low dynamic range (LDR) ASTC
textures are decompressed to FP16 values per component.
In many cases, decompressing LDR textures to a lower precision intermediate
result gives acceptable image quality.
Source material for LDR textures is typically authored as 8-bit UNORM
values, so decoding to FP16 values adds little value.
On the other hand, reducing precision of the decoded result reduces the size
of the decompressed data, potentially improving texture cache performance
and saving power.

The goal of this extension is to enable this efficiency gain on existing
ASTC texture data.
This is achieved by giving the application the ability to select the
intermediate decoding precision.

Three decoding options are provided:

* Decode to elink:VK_FORMAT_R16G16B16A16_SFLOAT precision: This is the
default, and matches the required behavior in the core API.
* Decode to elink:VK_FORMAT_R8G8B8A8_UNORM precision: This is provided as
an option in LDR mode.
* Decode to elink:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 precision: This is
provided as an option in both LDR and HDR mode.
In this mode, negative values cannot be represented and are clamped to
zero.
The alpha component is ignored, and the results are as if alpha was 1.0.
This decode mode is optional and support can be queried via the physical
device properties.

=== New Enum Constants

* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT

=== New Enums

None.

=== New Structures

* slink:VkImageViewASTCDecodeModeEXT
* slink:VkPhysicalDeviceASTCDecodeFeaturesEXT

=== New Functions

None.

=== Issues

1) Are implementations allowed to decode at a higher precision than what is
requested?

RESOLUTION: No.
If we allow this, then this extension could be exposed on all
implementations that support ASTC.
But developers would have no way of knowing what precision was actually
used, and thus whether the image quality is sufficient at reduced
precision.

2) Should the decode mode be image view state and/or sampler state?

RESOLUTION: Image view state only.
Some implementations treat the different decode modes as different
texture formats.

=== Example

Create an image view that decodes to VK_FORMAT_R8G8B8A8_UNORM precision:

[source,c++]
----------------------------------------

VkImageViewASTCDecodeModeEXT decodeMode =
{
VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT, // sType
NULL, // pNext
VK_FORMAT_R8G8B8A8_UNORM // decode mode
};

VkImageViewCreateInfo createInfo =
{
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO, // sType
&decodeMode, // pNext
// flags, image, viewType set to application-desired values
VK_FORMAT_ASTC_8x8_UNORM_BLOCK, // format
// components, subresourceRange set to application-desired values
};

VkImageView imageView;
VkResult result = vkCreateImageView(
device,
&createInfo,
NULL,
&imageView);
----------------------------------------

=== Version History

* Revision 1, 2018-08-07 (Jan-Harald Fredriksen)
- Initial revision

@@ -152,15 +152,15 @@ happens and the third will log warnings to stdout.
myOutputDebugString, // pfnUserCallback
NULL // pUserData
};
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, &cb1);
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, NULL, &cb1);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}

callback1.messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT;
callback1.pfnCallback = myDebugBreak;
callback1.pUserData = NULL;
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, &cb2);
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, NULL, &cb2);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}
@@ -175,17 +175,17 @@ happens and the third will log warnings to stdout.
mystdOutLogger, // pfnUserCallback
NULL // pUserData
};
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback3, &cb3);
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback3, NULL, &cb3);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}

...

// Remove callbacks when cleaning up
pfnDestroyDebugUtilsMessengerEXT(instance, cb1);
pfnDestroyDebugUtilsMessengerEXT(instance, cb2);
pfnDestroyDebugUtilsMessengerEXT(instance, cb3);
pfnDestroyDebugUtilsMessengerEXT(instance, cb1, NULL);
pfnDestroyDebugUtilsMessengerEXT(instance, cb2, NULL);
pfnDestroyDebugUtilsMessengerEXT(instance, cb3, NULL);
------------------------------------------------------------------------------

**Example 2**
@@ -0,0 +1,112 @@
include::meta/VK_EXT_inline_uniform_block.txt[]

*Last Modified Date*::
2018-08-01
*IP Status*::
No known IP claims.
*Contributors*::
- Daniel Rakos, AMD
- Jeff Bolz, NVIDIA
- Slawomir Grajewski, Intel
- Neil Henning, Codeplay

This extension introduces the ability to back uniform blocks directly with
descriptor sets by storing inline uniform data within descriptor pool
storage.
Compared to push constants this new construct allows uniform data to be
reused across multiple disjoint sets of draw or dispatch commands and may:
enable uniform data to be accessed with less indirections compared to
uniforms backed by buffer memory.

=== New Object Types

None

=== New Enum Constants

* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT
** ename:VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT
** ename:VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT

* Extending elink:VkDescriptorType:
** ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT

=== New Enums

None

=== New Structures

* slink:VkPhysicalDeviceInlineUniformBlockFeaturesEXT
* slink:VkPhysicalDeviceInlineUniformBlockPropertiesEXT
* slink:VkWriteDescriptorSetInlineUniformBlockEXT
* slink:VkDescriptorPoolInlineUniformBlockCreateInfoEXT

=== New Functions

None

=== New Built-In Variables

None

=== Issues

1) Do we need a new storage class for inline uniform blocks vs uniform
blocks?

*RESOLVED*: No.
The code:Uniform storage class is used to allow the same syntax used for
both uniform buffers and inline uniform blocks.

2) Is the descriptor array index and array size expressed in terms of bytes
or dwords for inline uniform block descriptors?

*RESOLVED*: In bytes, but both must: be a multiple of 4, similar to how push
constant ranges are specified.
The pname:descriptorCount of sname:VkDescriptorSetLayoutBinding thus
provides the total number of bytes a particular binding with an inline
uniform block descriptor type can hold, while the pname:srcArrayElement,
pname:dstArrayElement, and pname:descriptorCount members of
sname:VkWriteDescriptorSet, sname:VkCopyDescriptorSet, and
sname:VkDescriptorUpdateTemplateEntry (where applicable) specify the byte
offset and number of bytes to write/copy to the binding's backing store.
Additionally, the pname:stride member of
sname:VkDescriptorUpdateTemplateEntry is ignored for inline uniform blocks
and a default value of one is used, meaning that the data to update inline
uniform block bindings with must be contiguous in memory.

3) What layout rules apply for uniform blocks corresponding to inline
constants?

*RESOLVED*: They use the same layout rules as uniform buffers.

4) Do we need to add non-uniform indexing features/properties as introduced
by `VK_EXT_descriptor_indexing` for inline uniform blocks?

*RESOLVED*: No, because inline uniform blocks are not allowed to be
"arrayed".
A single binding with an inline uniform block descriptor type corresponds to
a single uniform block instance and the array indices inside that binding
refer to individual offsets within the uniform block (see issue #2).
However, this extension does introduce new features/properties about the
level of support for update-after-bind inline uniform blocks.

5) Is the pname:descriptorBindingVariableDescriptorCount feature introduced
by `VK_EXT_descriptor_indexing` supported for inline uniform blocks?

*RESOLVED*: Yes, as long as other inline uniform block specific limits are
respected.

6) Do the robustness guarantees of pname:robustBufferAccess apply to inline
uniform block accesses?

*RESOLVED*: No, similarly to push constants, as they are not backed by
buffer memory like uniform buffers.

=== Version History

* Revision 1, 2018-08-01 (Daniel Rakos)
- Internal revisions
@@ -1,7 +1,7 @@
include::meta/VK_EXT_vertex_attribute_divisor.txt[]

*Last Modified Date*::
2018-07-16
2018-08-03
*IP Status*::
No known IP claims.
*Contributors*::
@@ -33,6 +33,8 @@ None.
** slink:VkPipelineVertexInputDivisorStateCreateInfoEXT
* slink:VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT
* slink:VkVertexInputBindingDivisorDescriptionEXT
* Extending slink:VkPhysicalDeviceFeatures2:
** slink:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT

=== New Functions

@@ -48,9 +50,8 @@ offsets.

2) Should zero be an allowed divisor?

*RESOLVED*: No.
The zero case in OpenGL is handled in Vulkan by setting the pname:inputRate
on the binding to ename:VK_VERTEX_INPUT_RATE_VERTEX.
*RESOLVED*: Yes.
A zero divisor means the vertex attribute is repeated for all instances.


=== Examples
@@ -101,3 +102,6 @@ application could use the following set of structures:
- Adjust the interaction between fname:divisor and pname:firstInstance
to match the OpenGL convention.
- Disallow divisors of zero.
* Revision 3, 2018-08-03 (Vikram Kushwaha)
- Allow a zero divisor.
- Add a physical device features structure to query/enable this feature.

0 comments on commit adadfce

Please sign in to comment.
You can’t perform that action at this time.