Permalink
Browse files

Change log for November 27, 2017 Vulkan 1.0.66 spec update:

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

Github Issues:

  * Clarified how and when ename:VK_ERROR_TOO_MANY_OBJECTS is generated in
    flink:vkAllocate Memory, and remove incorrect valid usage statement
    about exceeding the API limit (public issue 356).
  * Minor clarification of the description of
    flink:vkUpdateDescriptorSetWithTemplateKHR::pname:descriptorUpdateTemplate
    (public issue 564).
  * Minor fixes for flink:vkCmdSetViewportWScalingNV (public pull request
    588).
  * Fix random name markup issues (public pull request 603).
  * Fix code:BuiltIn decoration typo in the <<fxvertex-attrib, Vertex
    Attributes>> section (public pull request 606).
  * Fix synchronization language following the definition of
    flink:vkAcquireNextImageKHR (public issue 607).
  * Restore descriptions of several commands and structures missing from the
    generated spec due to a mistyped asciidoctor conditional (public issue
    612).
  * Fix 1.0.41 changelog to refer to public issues 403/404 (public issue
    618).

Internal Issues:

  * Refactor valid usage statements with internal conditionals in
    `copies.txt`, `pipelines.txt`, `renderpass.txt`, and `resources.txt` so
    each branch of the conditional appears as a standalone statement which
    can contain a separate VUID. This should have no impact on the generated
    specs, but is necessary given the present state of the VU extractor and
    the validation layer code that consumes them (internal issue 1043).
  * Fix VkQueueGlobalPriorityEXT enum values missing _EXT suffix (internal
    issue 1045).
  * Clarified initial ownership of resources bound to shared memory objects,
    (internal issue 1068).
  * Fix duplicated valid usage ID tag for flink:vkCmdCopyImage, and make the
    required layouts include ename:VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIONAL in
    both cases (internal issue 1084).

Other Issues:

  * Remove the noise functions from GLSL for SPIR-V for Vulkan in the
    `GL_KHR_vulkan_glsl.txt` extension.

New Extensions:

  * `VK_EXT_external_memory_host`
  * `VK_EXT_external_memory_dma_buf`
  * `VK_EXT_queue_family_foreign`
  • Loading branch information...
Jon Leech
Jon Leech committed Nov 27, 2017
1 parent b29521b commit 64fa8ef4df3bff37214e717abe490f7ea7ea44b0
Showing with 1,053 additions and 184 deletions.
  1. +55 −1 ChangeLog.txt
  2. +6 −2 doc/specs/misc/GL_KHR_vulkan_glsl.txt
  3. +1 −1 doc/specs/vulkan/Makefile
  4. +1 −1 doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt
  5. +60 −0 doc/specs/vulkan/appendices/VK_EXT_external_memory_dma_buf.txt
  6. +110 −0 doc/specs/vulkan/appendices/VK_EXT_external_memory_host.txt
  7. +6 −3 doc/specs/vulkan/appendices/VK_EXT_global_priority.txt
  8. +43 −0 doc/specs/vulkan/appendices/VK_EXT_queue_family_foreign.txt
  9. +2 −2 doc/specs/vulkan/appendices/VK_KHR_maintenance1.txt
  10. +4 −4 doc/specs/vulkan/appendices/VK_KHR_shader_draw_parameters.txt
  11. +2 −2 doc/specs/vulkan/appendices/VK_KHR_wayland_surface.txt
  12. +2 −3 doc/specs/vulkan/appendices/VK_NVX_multiview_per_view_attributes.txt
  13. +12 −0 doc/specs/vulkan/appendices/extensions.txt
  14. +5 −0 doc/specs/vulkan/appendices/glossary.txt
  15. +2 −1 doc/specs/vulkan/chapters/VK_KHR_display/display.txt
  16. +11 −17 doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt
  17. +2 −1 doc/specs/vulkan/chapters/VK_NV_clip_space_w_scaling/vertexpostproc.txt
  18. +129 −43 doc/specs/vulkan/chapters/copies.txt
  19. +1 −1 doc/specs/vulkan/chapters/descriptorsets.txt
  20. +9 −7 doc/specs/vulkan/chapters/devsandqueues.txt
  21. +84 −3 doc/specs/vulkan/chapters/features.txt
  22. +187 −28 doc/specs/vulkan/chapters/memory.txt
  23. +33 −7 doc/specs/vulkan/chapters/pipelines.txt
  24. +21 −1 doc/specs/vulkan/chapters/renderpass.txt
  25. +71 −12 doc/specs/vulkan/chapters/resources.txt
  26. +54 −19 doc/specs/vulkan/chapters/synchronization.txt
  27. +1 −1 doc/specs/vulkan/reflow_count.py
  28. +23 −0 src/ext_loader/vulkan_ext.c
  29. +56 −15 src/spec/vk.xml
  30. +60 −9 src/vulkan/vulkan.h
@@ -8,6 +8,60 @@ public pull requests that have been accepted.
-----------------------------------------------------
Change log for November 27, 2017 Vulkan 1.0.66 spec update:
* Bump API patch number and header version number to 66 for this update.
Github Issues:
* Clarified how and when ename:VK_ERROR_TOO_MANY_OBJECTS is generated in
flink:vkAllocate Memory, and remove incorrect valid usage statement
about exceeding the API limit (public issue 356).
* Minor clarification of the description of
flink:vkUpdateDescriptorSetWithTemplateKHR::pname:descriptorUpdateTemplate
(public issue 564).
* Minor fixes for flink:vkCmdSetViewportWScalingNV (public pull request
588).
* Fix random name markup issues (public pull request 603).
* Fix code:BuiltIn decoration typo in the <<fxvertex-attrib, Vertex
Attributes>> section (public pull request 606).
* Fix synchronization language following the definition of
flink:vkAcquireNextImageKHR (public issue 607).
* Restore descriptions of several commands and structures missing from the
generated spec due to a mistyped asciidoctor conditional (public issue
612).
* Fix 1.0.41 changelog to refer to public issues 403/404 (public issue
618).
Internal Issues:
* Refactor valid usage statements with internal conditionals in
`copies.txt`, `pipelines.txt`, `renderpass.txt`, and `resources.txt` so
each branch of the conditional appears as a standalone statement which
can contain a separate VUID. This should have no impact on the generated
specs, but is necessary given the present state of the VU extractor and
the validation layer code that consumes them (internal issue 1043).
* Fix VkQueueGlobalPriorityEXT enum values missing _EXT suffix (internal
issue 1045).
* Clarified initial ownership of resources bound to shared memory objects,
(internal issue 1068).
* Fix duplicated valid usage ID tag for flink:vkCmdCopyImage, and make the
required layouts include ename:VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIONAL in

This comment has been minimized.

@krOoze

krOoze Nov 27, 2017

Contributor

typo

This comment has been minimized.

@oddhack

oddhack Nov 27, 2017

Contributor

I'll fix this the next time we do a public spec update. Thanks.

both cases (internal issue 1084).
Other Issues:
* Remove the noise functions from GLSL for SPIR-V for Vulkan in the
`GL_KHR_vulkan_glsl.txt` extension.
New Extensions:
* `VK_EXT_external_memory_host`
* `VK_EXT_external_memory_dma_buf`
* `VK_EXT_queue_family_foreign`
-----------------------------------------------------
Change log for October 27, 2017 Vulkan 1.0.65 spec update:
* Bump API patch number and header version number to 65 for this update.
@@ -1168,7 +1222,7 @@ Github Issues:
* Made all uses of `NULL` vs. code:VK_NULL_HANDLE consistent (public issue
276).
* Clarify render pass compatibility in different usage scenarios (public
issues 303 and 304).
issues 403 and 404).
* Add valid usage statements to slink:VkFramebufferCreateInfo requiring
that the width, height, and number of layers of the framebuffer all be
nonzero (public issue 432).
@@ -33,8 +33,8 @@ Status
Version
Last Modified Date: 07-Jul-2017
Revision: 42
Last Modified Date: 25-Oct-2017
Revision: 43
Number
@@ -66,6 +66,7 @@ Overview
* subroutines
* shared and packed block layouts
* the already deprecated texturing functions (e.g., texture2D())
* the already deprecated noise functions (e.g., noise1())
* compatibility-mode-only features
* gl_DepthRangeParameters and gl_NumSamples
* gl_VertexID and gl_InstanceID
@@ -1245,6 +1246,8 @@ Changes to Chapter 8 of the OpenGL Shading Language Specification
Remove section 8.10 Atomic-Counter Functions
Remove section 8.14 Noise Functions
Add a section
"8.X Subpass Functions
@@ -1401,6 +1404,7 @@ Revision History
Rev. Date Author Changes
---- ----------- ------- --------------------------------------------
43 25-Oct-2017 JohnK remove the already deprecated noise functions
42 07-Jul-2017 JohnK arrays of buffers consume only one binding
41 05-Jul-2017 JohnK allow std430 on push_constant declarations
40 21-May-2017 JohnK Require in/out explicit locations
@@ -92,7 +92,7 @@ VERBOSE =
# $(EXTENSIONS))
# ADOCOPTS options for asciidoc->HTML5 output
NOTEOPTS = -a editing-notes -a implementation-guide
SPECREVISION = 1.0.65
SPECREVISION = 1.0.66
# Spell out ISO 8601 format as not all date commands support --rfc-3339
SPECDATE = $(shell echo `date -u "+%Y-%m-%d %TZ"`)
@@ -27,7 +27,7 @@ color sample 0 will be in bits 0-3 of the fragment mask, for color sample 7
the index will be in bits 28-31.
The color fragment for a particular color sample may then be fetched with
the correspoding fragment mask value using the code:fragmentFetchAMD shader
the corresponding fragment mask value using the code:fragmentFetchAMD shader
function.
=== New Object Types
@@ -0,0 +1,60 @@
include::meta/VK_EXT_external_memory_dma_buf.txt[]
*Last Modified Date*::
2017-10-10
*IP Status*::
No known IP claims.
*Contributors*::
- Chad Versace, Google
- James Jones, NVIDIA
- Jason Ekstrand, Intel
A dma_buf is a type of file descriptor, defined by the Linux kernel, that
allows sharing memory across kernel device drivers and across processes.
This extension enables applications to import a dma_buf as
slink:VkDeviceMemory; to export slink:VkDeviceMemory as a dma_buf; and to
create slink:VkBuffer objects that can: be bound to that memory.
=== New Enum Constants
* Extending elink:VkExternalMemoryHandleTypeFlagBitsKHR:
** ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT
=== Issues
1.
How does the application, when creating a slink:VkImage that it intends
to bind to dma_buf slink:VkDeviceMemory that contains an externally
produced image, specify the memory layout (such as row pitch and DRM
format modifier) of the slink:VkImage? In other words, how does the
application achieve behavior comparable to that provided by
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt[EGL_EXT_image_dma_buf_import]
and
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt[EGL_EXT_image_dma_buf_import_modifiers]?
+
--
*RESOLVED*.
Features comparable to those in
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt[EGL_EXT_image_dma_buf_import]
and
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt[EGL_EXT_image_dma_buf_import_modifiers]
will be provided by an extension layered atop this one.
--
2.
Without the ability to specify the memory layout of external dma_buf
images, how is this extension useful?
+
--
*RESOLVED*.
This extension provides exactly one new feature: the ability to
import/export between dma_bufs and slink:VkDeviceMemory.
This feature, together with features provided by
<<VK_KHR_external_memory_fd>>, is sufficient to bind a slink:VkBuffer to
dma_buf.
--
=== Version History
* Revision 1, 2017-10-10 (Chad Versace)
- Squashed internal revisions
@@ -0,0 +1,110 @@
include::meta/VK_EXT_external_memory_host.txt[]
*Last Modified Date*::
2017-11-10
*IP Status*::
No known IP claims.
*Contributors*::
- Jaakko Konttinen, AMD
- David Mao, AMD
- Daniel Rakos, AMD
- Tobias Hector, Imagination Technologies
- Jason Ekstrand, Intel
- James Jones, NVIDIA
This extension enables an application to import host allocations and host
mapped foreign device memory to Vulkan memory objects.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_IMPORT_MEMORY_HOST_POINTER_INFO_EXT
** ename:VK_STRUCTURE_TYPE_MEMORY_HOST_POINTER_PROPERTIES_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_HOST_PROPERTIES_EXT
* Extending elink:VkExternalMemoryHandleTypeFlagBitsKHR:
** ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT
** ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_MAPPED_FOREIGN_MEMORY_BIT_EXT
=== New Enums
None.
=== New Structs
* slink:VkImportMemoryHostPointerInfoEXT
* slink:VkMemoryHostPointerPropertiesEXT
* slink:VkPhysicalDeviceExternalMemoryHostPropertiesEXT
=== New Functions
* flink:vkGetMemoryHostPointerPropertiesEXT
=== Issues
1) What memory type has to be used to import host pointers?
RESOLVED: Depends on the implementation.
Applications have to use the new flink:vkGetMemoryHostPointerPropertiesEXT
command to query the supported memory types for a particular host pointer.
The reported memory types may include memory types that come from a memory
heap that is otherwise not usable for regular memory object allocation and
thus such a heap's size may be zero.
2) Can the application still access the contents of the host allocation
after importing?
RESOLVED: Yes.
However, usual synchronization requirements apply.
3) Can the application free the host allocation?
RESOLVED: No, it violates valid usage conditions.
Using the memory object imported from a host allocation that's already freed
thus results in undefined behavior.
4) Is flink:vkMapMemory expected to return the same host address which was
specified when importing it to the memory object?
RESOLVED: No.
Implementations are allowed to return the same address but it's not
required.
Some implementations might return a different virtual mapping of the
allocation, although the same physical pages will be used.
5) Is there any limitation on the alignment of the host pointer and/or size?
RESOLVED: Yes.
Both the address and the size have to be an integer multiple of
pname:minImportedHostPointerAlignment.
In addition, some platforms and foreign devices may have additional
restrictions.
6) Can the same host allocation be imported multiple times into a given
physical device?
RESOLVED: No, at least not guaranteed by this extension.
Some platforms do not allow locking the same physical pages for device
access multiple times, so attempting to do it may result in undefined
behavior.
7) Does this extension support exporting the new handle type?
RESOLVED: No.
8) Should we include the possibility to import host mapped foreign device
memory using this API?
RESOLVED: Yes, through a separate handle type.
Implementations are still allowed to support only one of the handle types
introduced by this extension by not returning import support for a
particular handle type as returned in slink:VkExternalMemoryPropertiesKHR.
=== Version History
* Revision 1, 2017-11-10 (Daniel Rakos)
- Internal revisions
@@ -15,7 +15,7 @@ In some cases it may be useful to extend this concept to a system-wide
scope.
This extension provides a mechanism for caller's to set their system-wide
priority.
The default queue priority is ename:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM.
The default queue priority is ename:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT.
The driver implementation will attempt to skew hardware resource allocation
in favour of the higher-priority task.
@@ -29,8 +29,8 @@ per-process queue priority
Abuse of this feature may result in starving the rest of the system from
hardware resources.
Therefore, the driver implementation may deny requests to acquire a priority
above the default priority (ename:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM) if the
caller does not have sufficient privileges.
above the default priority (ename:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT) if
the caller does not have sufficient privileges.
In this scenario ename:VK_ERROR_NOT_PERMITTED_EXT is returned.
The driver implementation may fail the queue allocation request if resources
@@ -68,5 +68,8 @@ None.
=== Version History
* Revision 2, 2017-11-03 (Andres Rodriguez)
- Fixed VkQueueGlobalPriorityEXT missing _EXT suffix
* Revision 1, 2017-10-06 (Andres Rodriguez)
- First version.
@@ -0,0 +1,43 @@
include::meta/VK_EXT_queue_family_foreign.txt[]
*Last Modified Date*::
2017-11-01
*IP Status*::
No known IP claims.
*Contributors*::
- Chad Versace, Google
- James Jones, NVIDIA
- Jason Ekstrand, Intel
- Jesse Hall, Google
- Daniel Rakos, AMD
- Ray Smith, ARM
This extension defines a special queue family,
ename:VK_QUEUE_FAMILY_FOREIGN_EXT, which can be used to transfer ownership
of resources backed by external memory to foreign, external queues.
This is similar to ename:VK_QUEUE_FAMILY_EXTERNAL_KHR, defined in
<<VK_KHR_external_memory>>.
The key differences between the two are:
* The queues represented by ename:VK_QUEUE_FAMILY_EXTERNAL_KHR must share
the same physical device and the same driver version as the current
slink:VkInstance.
ename:VK_QUEUE_FAMILY_FOREIGN_EXT has no such restrictions.
It can represent devices and drivers from other vendors, and can even
represent non-Vulkan-capable devices.
* All resources backed by external memory support
ename:VK_QUEUE_FAMILY_EXTERNAL_KHR.
Support for ename:VK_QUEUE_FAMILY_FOREIGN_EXT is more restrictive.
* Applications should expect transitions to/from
ename:VK_QUEUE_FAMILY_FOREIGN_EXT to be more expensive than transitions
to/from ename:VK_QUEUE_FAMILY_EXTERNAL_KHR.
=== New Enum Constants
* Special constants:
** ename:VK_QUEUE_FAMILY_FOREIGN_EXT
=== Version History
* Revision 1, 2017-11-01 (Chad Versace)
- Squashed internal revisions
@@ -34,8 +34,8 @@ The new features are as follows:
This extension allows copying from layers of a 2D array image to slices
of a 3D image and vice versa.
* Allow negative height to be specified in the
slink:VkViewport::pname:height field to perform y-inversion of
the clip-space to framebuffer-space transform.
slink:VkViewport::pname:height field to perform y-inversion of the
clip-space to framebuffer-space transform.
This allows apps to avoid having to use `gl_Position.y = -gl_Position.y`
in shaders also targeting other APIs.
* Allow implementations to express support for doing just transfers and
Oops, something went wrong.

0 comments on commit 64fa8ef

Please sign in to comment.