Skip to content
Permalink
Browse files

Change log for December 10, 2016 Vulkan 1.0.37 spec update:

  * Bump API patch number and header version number to 37 for this update.

Github Issues:

  * Add usability guarantees on the values returned by
    flink:vkGetPhysicalDeviceSurfaceCapabilitiesKHR in the
    slink:VkSurfaceCapabilitiesKHR structure and by
    flink:vkGetPhysicalDeviceSurfaceFormatsKHR in the
    pname:pSurfaceFormatCount parameter (public issue 385).
  * Add elink:VkDebugReportObjectTypeEXT enumerants for new object types
    introduced by new extensions (public issue 408).
  * Add +VK_NVX_device_generated_commands+ etext:ACCESS bits and define how
    they are used (public issue 415).
  * Fix indentation for slink:VkDebugReportCallbackCreateInfoEXT member
    descriptions (public issue 419).

Internal Issues:

  * Expand requirements memory binding of non-sparse images and buffers from
    the <<resources-association,Resource Memory Association>> section into
    valid usage statements for all of the applicable API calls (internal
    issue 508).
  * Explicitly state that valid usage of flink:vkCreateImage requires that
    flink:vkGetPhysicalDeviceImageFormatProperties would return
    ename:VK_SUCCESS for the requested image configuration (internal issue
    598).
  • Loading branch information...
oddhack committed Dec 11, 2016
1 parent 7cba8f5 commit 8f014fa579ba050d9c5a3df2bdbca04107846c45
@@ -1680,8 +1680,8 @@ Github Issues:
* Added validation language for slink:VkSubpassDependency and in the
<<synchronization-access-types-supported,supported access types>>
section to catch access masks that include bits which are not supported
by pipeline stages in the stage masks (partially addresses public issue
1006).
by pipeline stages in the stage masks (partially addresses
github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/1006 ).

Internal Issues:

@@ -1707,3 +1707,34 @@ Other Issues:
* Add validity language requiring that
slink:VkPushConstantRange::pname:offset be a multiple of 4, as stated in
the spec language.

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

Change log for December 10, 2016 Vulkan 1.0.37 spec update:

* Bump API patch number and header version number to 37 for this update.

Github Issues:

* Add usability guarantees on the values returned by
flink:vkGetPhysicalDeviceSurfaceCapabilitiesKHR in the
slink:VkSurfaceCapabilitiesKHR structure and by
flink:vkGetPhysicalDeviceSurfaceFormatsKHR in the
pname:pSurfaceFormatCount parameter (public issue 385).
* Add elink:VkDebugReportObjectTypeEXT enumerants for new object types
introduced by new extensions (public issue 408).
* Add +VK_NVX_device_generated_commands+ etext:ACCESS bits and define how
they are used (public issue 415).
* Fix indentation for slink:VkDebugReportCallbackCreateInfoEXT member
descriptions (public issue 419).

Internal Issues:

* Expand requirements memory binding of non-sparse images and buffers from
the <<resources-association,Resource Memory Association>> section into
valid usage statements for all of the applicable API calls (internal
issue 508).
* Explicitly state that valid usage of flink:vkCreateImage requires that
flink:vkGetPhysicalDeviceImageFormatProperties would return
ename:VK_SUCCESS for the requested image configuration (internal issue
598).
@@ -160,7 +160,7 @@ GENDEPENDS = api/timeMarker validity/timeMarker hostsynctable/timeMarker
COMMONDOCS = $(CHAPTERS) $(GENINCLUDE) $(GENDEPENDS)
# A generated included file containing the spec version, date, and git commit
SPECVERSION = specversion.txt
SPECREVISION = 1.0.36
SPECREVISION = 1.0.37
SPECREMARK =

# Spec targets
@@ -8,9 +8,9 @@
*Registered Extension Number*::
12
*Last Modified Date*::
2016-09-17
2016-12-08
*Revision*::
3
4
*IP Status*::
No known IP claims.
*Dependencies*::
@@ -19,6 +19,7 @@
- Courtney Goeltzenleuchter, LunarG
- Dan Ginsburg, Valve
- Jon Ashburn, LunarG
- Mark Lobodzinski, LunarG
*Contacts*::
- Courtney Goeltzenleuchter

@@ -152,9 +153,18 @@ We should probably add some.

=== Version History

[NOTE]
.Note
====
There is no revision history in the current spec.
We should probably add some.
====
* Revision 1, 2015-05-20 (Courtney Goetzenleuchter)
- Initial draft, based on LunarG KHR spec, other KHR specs

* Revision 2, 2016-02-16 (Courtney Goetzenleuchter)
- Update usage, documentation

* Revision 3, 2016-06-14 (Courtney Goetzenleuchter)
- Update VK_EXT_DEBUG_REPORT_SPEC_VERSION to indicate added support for
vkCreateInstance and vkDestroyInstance

* Revision 4, 2016-12-08 (Mark Lobodzinski)
- Added Display_KHR, DisplayModeKHR extension objects
- Added ObjectTable_NVX, IndirectCommandsLayout_NVX extension objects
- Bumped spec revision
- Retroactively added version history
@@ -95,7 +95,7 @@ shaders...).
* sname:VkObjectTableNVX
* sname:VkIndirectCommandsLayoutNVX

== New Flag Types
=== New Flag Types

* sname:VkIndirectCommandsLayoutUsageFlagsNVX
* sname:VkObjectEntryUsageFlagsNVX
@@ -313,11 +313,35 @@ vkCmdProcessCommandsNVX
22) In which pipeline stage do the device generated command expansion
happen?

This is required in order to allow applications to properly syncronize
access (e.g. via memory barriers) when writing to the buffers referenced
by vkCmdProcessCommandsNVX
vkCmdProcessCommandsNVX is treated as if it occurs in a separate logical
pipeline from either graphics or compute, and that pipeline only includes
TOP_OF_PIPE, a new stage ename:VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT, and
BOTTOM_OF_PIPE.
This new stage has two corresponding new access types,
ename:VK_ACCESS_COMMAND_PROCESS_READ_BIT_NVX and
ename:VK_ACCESS_COMMAND_PROCESS_WRITE_BIT_NVX, used to synchronize reading
the buffer inputs and writing the command buffer memory output.
The output written in the target command buffer is considered to be
consumed by the DRAW_INDIRECT pipeline stage.

added VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT
Thus, to synchronize from writing the input buffers to executing
flink:vkCmdProcessCommandsNVX, use:

* dstStageMask = VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX
* dstAccessMask = VK_ACCESS_COMMAND_PROCESS_READ_BIT_NVX

To synchronize from executing flink:vkCmdProcessCommandsNVX to executing
the generated commands, use

* srcStageMask = VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX
* srcAccessMask = VK_ACCESS_COMMAND_PROCESS_WRITE_BIT_NVX
* dstStageMask = VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT
* dstAccessMask = VK_ACCESS_INDIRECT_COMMAND_READ_BIT

When flink:vkCmdProcessCommandsNVX is used with a
pname:targetCommandBuffer of `NULL`, the generated commands are
immediately executed and there is implicit synchronization between
generation and execution.

23) What if most token data is "static", but we frequently want to render a
subsection?
@@ -360,13 +384,34 @@ TODO links to gameworks & designworks samples
// If you modify the input buffer data referenced by VkCmdProcessCommandsInfoNVX,
// ensure you have added the appropriate barriers prior generation process.
// When regenerating the content of the same reserved space, ensure prior operations have completed
vkCmdPipelineBarrier (mainCmd, VK_PIPELINE_STAGE_ALL_COMMANDS_BIT, VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX, ...);

VkMemoryBarrier memoryBarrier = { VK_STRUCTURE_TYPE_MEMORY_BARRIER };
memoryBarrier.srcAccessMask = ...;
memoryBarrier.dstAccessMask = VK_ACCESS_COMMAND_PROCESS_READ_BIT_NVX;

vkCmdPipelineBarrier(mainCmd,
/*srcStageMask*/VK_PIPELINE_STAGE_ALL_COMMANDS_BIT,
/*dstStageMask*/VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX,
/*dependencyFlags*/0,
/*memoryBarrierCount*/1,
/*pMemoryBarriers*/&memoryBarrier,
...);

vkCmdProcessCommandsNVX(mainCmd, &processInfo);
...
// execute the secondary command buffer and ensure the processing that modifies command-buffer content
// has completed
vkCmdPipelineBarrier(mainCmd, VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX, VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT, ...)

memoryBarrier.srcAccessMask = VK_ACCESS_COMMAND_PROCESS_WRITE_BIT_NVX;
memoryBarrier.dstAccessMask = VK_ACCESS_INDIRECT_COMMAND_READ_BIT;

vkCmdPipelineBarrier(mainCmd,
/*srcStageMask*/VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX,
/*dstStageMask*/VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT,
/*dependencyFlags*/0,
/*memoryBarrierCount*/1,
/*pMemoryBarriers*/&memoryBarrier,
...)
vkCmdExecuteCommands(mainCmd, 1, &generatedCmdBuffer);

---------------------------------------------------
@@ -54,10 +54,14 @@ include::../api/enums/VkDebugReportFlagBitsEXT.txt[]

* ename:VK_DEBUG_REPORT_ERROR_BIT_EXT indicates an error that may cause
undefined results, including an application crash.
* ename:VK_DEBUG_REPORT_WARNING_BIT_EXT indicates an unexpected use.
E.g. Not destroying objects prior to destroying the containing object or
potential inconsistencies between descriptor set layout and the layout
in the corresponding shader, etc.
* ename:VK_DEBUG_REPORT_WARNING_BIT_EXT indicates use of Vulkan that may
expose an app bug.
Such cases may not be immediately harmful, such as a fragment shader
outputting to a location with no attachment.
Other cases may point to behavior that is almost certainly bad when
unintended such as using an image whose memory hasn't been filled.
In general if you see a warning but you know that the behavior is
intended/desired, then simply ignore the warning.
* ename:VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT indicates a
potentially non-optimal use of Vulkan.
E.g. using flink:vkCmdClearColorImage when a RenderPass load_op would
@@ -67,10 +71,10 @@ include::../api/enums/VkDebugReportFlagBitsEXT.txt[]
application.
* ename:VK_DEBUG_REPORT_DEBUG_BIT_EXT indicates diagnostic information
from the loader and layers.

--
+
* pname:pfnCallback is the application callback function to call.
* pname:pUserData is user data to be passed to the callback.
--

For each sname:VkDebugReportCallbackEXT that is created the flags determine
when that function is called.
@@ -232,9 +232,11 @@ The sname:VkSurfaceCapabilitiesKHR structure is defined as:
include::../../api/structs/VkSurfaceCapabilitiesKHR.txt[]

* pname:minImageCount is the minimum number of images the specified device
supports for a swapchain created for the surface.
supports for a swapchain created for the surface, and will be at least
one.
* pname:maxImageCount is the maximum number of images the specified device
supports for a swapchain created for the surface.
supports for a swapchain created for the surface, and will be either 0,
or greater than or equal to pname:minImageCount.
A value of 0 means that there is no limit on the number of images,
though there may: be limits related to the total amount of memory used
by swapchain images.
@@ -244,20 +246,33 @@ include::../../api/structs/VkSurfaceCapabilitiesKHR.txt[]
the surface.
* pname:minImageExtent contains the smallest valid swapchain extent for
the surface on the specified device.
The pname:width and pname:height of the extent will each be less than or
equal to the corresponding pname:width and pname:height of
pname:currentExtent, unless pname:currentExtent has the special value
described above.
* pname:maxImageExtent contains the largest valid swapchain extent for the
surface on the specified device.
The pname:width and pname:height of the extent will each be greater than
or equal to the corresponding pname:width and pname:height of
pname:minImageExtent.
The pname:width and pname:height of the extent will each be greater than
or equal to the corresponding pname:width and pname:height of
pname:currentExtent, unless pname:currentExtent has the special value
described above.
* pname:maxImageArrayLayers is the maximum number of layers swapchain
images can: have for a swapchain created for this device and surface.
images can: have for a swapchain created for this device and surface,
and will be at least one.
* pname:supportedTransforms is a bitmask of
elink:VkSurfaceTransformFlagBitsKHR, describing the presentation
transforms supported for the surface on the specified device.
* pname:currentTransform is a bitmask of
elink:VkSurfaceTransformFlagBitsKHR, describing the surface's current
transform relative to the presentation engine's natural orientation.
transforms supported for the surface on the specified device, and at
least one bit will be set.
* pname:currentTransform is the surface's current transform relative to
the presentation engine's natural orientation, as described by
elink:VkSurfaceTransformFlagBitsKHR.
* pname:supportedCompositeAlpha is a bitmask of
elink:VkCompositeAlphaFlagBitsKHR, representing the alpha compositing
modes supported by the presentation engine for the surface on the
specified device.
specified device, and at least one bit will be set.
Opaque composition can: be achieved in any alpha compositing mode by
either using a swapchain image format that has no alpha component, or by
ensuring that all pixels in the swapchain images have an alpha value of
@@ -279,8 +294,10 @@ include::../../validity/structs/VkSurfaceCapabilitiesKHR.txt[]

// refBegin VkSurfaceTransformFlagBitsKHR - presentation transforms supported on a device

The pname:supportedTransforms and pname:currentTransform members are of type
ename:VkSurfaceTransformFlagBitsKHR, which contains the following values:
slink:VkSurfaceCapabilitiesKHR::pname:supportedTransforms is a bitmask of,
and slink:VkSurfaceCapabilitiesKHR::pname:currentTransform is a single bit
from ename:VkSurfaceTransformFlagBitsKHR, which contains the following
values:

include::../../api/enums/VkSurfaceTransformFlagBitsKHR.txt[]

@@ -362,6 +379,7 @@ include::../../api/protos/vkGetPhysicalDeviceSurfaceFormatsKHR.txt[]
If pname:pSurfaceFormats is `NULL`, then the number of format pairs
supported for the given pname:surface is returned in
pname:pSurfaceFormatCount.
The number of format pairs supported will be greater than or equal to 1.
Otherwise, pname:pSurfaceFormatCount must: point to a variable set by the
user to the number of elements in the pname:pSurfaceFormats array, and on
return the variable is overwritten with the number of structures actually
@@ -43,7 +43,7 @@ include::../../api/structs/VkWaylandSurfaceCreateInfoKHR.txt[]

include::../../validity/structs/VkWaylandSurfaceCreateInfoKHR.txt[]

On Wayland, pname:currentExtent is undefined [eq]#(0,0)#.
On Wayland, pname:currentExtent is undefined [eq]#(0xFFFFFFFF, 0xFFFFFFFF)#.
Whatever the application sets a swapchain's pname:imageExtent to will be the
size of the window, after the first image is presented.
pname:minImageExtent is [eq]#(1,1)#, and pname:maxImageExtent is the maximum
@@ -25,6 +25,14 @@ Similar to sname:VkDescriptorSet special care must be taken for the lifetime
of resources referenced in sname:VkObjectTableNVX, which may be accessed at
either generation or execution time.

flink:vkCmdProcessCommandsNVX executes in a separate logical pipeline from
either graphics or compute.
When generating commands into a secondary command buffer, the command
generation must: be explicitly synchronized against the secondary command
buffer's execution.
When not using a secondary command buffer, the command generation is
automatically synchronized against the command execution.

== Features and Limitations

// refBegin vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX Returns device-generated commands related properties of a physical device
@@ -44,6 +44,8 @@ pname:pColor.
****
* pname:image must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* If pname:image is non-sparse then it must: be bound completely and
contiguously to a single sname:VkDeviceMemory object
* pname:imageLayout must: specify the layout of the image subresource
ranges of pname:image specified in pname:pRanges at the time this
command is executed on a sname:VkDevice
@@ -90,6 +92,8 @@ include::../api/protos/vkCmdClearDepthStencilImage.txt[]
****
* pname:image must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* If pname:image is non-sparse then it must: be bound completely and
contiguously to a single sname:VkDeviceMemory object
* pname:imageLayout must: specify the layout of the image subresource
ranges of pname:image specified in pname:pRanges at the time this
command is executed on a sname:VkDevice
@@ -339,6 +343,8 @@ fname:vkCmdFillBuffer.
multiple of `4`
* pname:dstBuffer must: have been created with
ename:VK_BUFFER_USAGE_TRANSFER_DST_BIT usage flag
* If pname:dstBuffer is non-sparse then it must: be bound completely and
contiguously to a single sname:VkDeviceMemory object
****

include::../validity/protos/vkCmdFillBuffer.txt[]
@@ -384,6 +390,8 @@ fname:vkCmdUpdateBuffer.
pname:dstBuffer minus pname:dstOffset
* pname:dstBuffer must: have been created with
ename:VK_BUFFER_USAGE_TRANSFER_DST_BIT usage flag
* If pname:dstBuffer is non-sparse then it must: be bound completely and
contiguously to a single sname:VkDeviceMemory object
* pname:dstOffset must: be a multiple of `4`
* pname:dataSize must: be less than or equal to `65536`
* pname:dataSize must: be a multiple of `4`

0 comments on commit 8f014fa

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