Author Topic: Vulkan API specifications 1.0.4 released  (Read 310595 times)

0 Members and 1 Guest are viewing this topic.

JeGX

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2921
    • Geeks3D.com
Vulkan API specifications 1.2.200 released
« Reply #160 on: November 24, 2021, 12:17:41 PM »
Quote
Change log for November 23, 2021 Vulkan 1.2.200 spec update:
  * Update release number to 200 for this update.

Github Issues:

  * Refer to flink:vkCmdPipelineBarrier2KHR::pname:pDependencyInfo as a
    pointer, not an array (public issue 1456).
  * Fix spelling and add backwards-compatibility aliases for some
    elink:VkPipelinCreateFlagBits values (public issue 1676).
  * Fix typo in apiext:VK_INTEL_shader_integer_functions2 (public issue
    1696).
  * Replace usage of {depth, color} buffer with {depth, color} attachment
    (public pull request 1701).
  * Add restriction to the <<formats-mandatory-features-depth-stencil,
    manadatory format support table>> for depth/stencil formats preventing
    implementations from advertising those bits in
    slink:VkFormatProperties::pname:bufferFeatures (public
    Vulkan-ValidationLayers issue 3225).

Internal Issues:

  * Add an additional guarantee for buffer memory requirements in
    slink:VkMemoryRequirements as a minor update to the
    apiext:VK_KHR_maintenance4 extension (internal issue 2885).
  * Add a <<fundamentals-api-name-aliases, section to the fundamentals
    chapter>> describing typo aliases (internal issue 2897).
  * Determine extensions dependencies directly from `vk.xml` in the build
    scripts, rather than generating an auxiliary `extDependency.py` target
    (internal issue 2923).
  * Remove redundant SPIR-V `RuntimeSpirv` valid usage statements 04830,
    06271, 06374, and 06375 (internal merge requests 4827, 4830).
  * Suppress file-not-found `include::` errors for validusage target, using
    an IncludeProcessor extension, due to the way in which the validusage
    extension processes conditionals. Make all include paths absolute and
    require this in the style guide (internal merge request 4925).
  * Add missing `optional="true"` attribute to
    slink:VkCommandBufferInheritanceRenderingInfoKHR::pname:colorAttachmentCount
    (internal merge request 4935).
  * Remove references to apiext:VK_KHR_synchronization2 enums when that
    extension is not enabled in the specification being built (internal
    merge request 4937).
  * Minor wording changes for style guide compliance and consistency
    (internal merge request 4938).
  * Ignore etext:*_EXTENSION_NAME and etext:*_SPEC_VERSION aliases in
    `makemanaliases.py` script since there are no corresponding refpages for
    these meta-enums.

New Extensions:

  * apiext:VK_ARM_rasterization_order_attachment_access (internal merge
    request 3856).
  * apiext:VK_EXT_depth_clip_control (public issues 986 and 1054).

source: https://github.com/KhronosGroup/Vulkan-Docs/commit/9ed8caef1a0b5abe9778adb39feff435b2328f1b

New extensions:
- VK_ARM_rasterization_order_attachment_access
Quote
Renderpasses, and specifically
<<synchronization-pipeline-barriers-subpass-self-dependencies, subpass
self-dependencies>> enable much of the same functionality as the framebuffer
fetch and pixel local storage extensions did for OpenGL ES.
But certain techniques such as programmable blending are awkward or
impractical to implement with these alone, in part because a self-dependency
is required every time a fragment will read a value at a given sample
coordinate.

This extension extends the mechanism of input attachments to allow access to
framebuffer attachments when used as both input and color, or depth/stencil,
attachments from one fragment to the next, in rasterization order, without
explicit synchronization.

- VK_EXT_depth_clip_control
Quote
This extension allows the application to use the OpenGL depth range in NDC,
i.e. with depth in range [eq]#[-1, 1]#, as opposed to Vulkan's default of
[eq]#[0, 1]#.
The purpose of this extension is to allow efficient layering of OpenGL over
Vulkan, by avoiding emulation in the pre-rasterization shader stages.
This emulation, which effectively duplicates gl_Position but with a
different depth value, costs ALU and consumes shader output components that
the implementation may not have to spare to meet OpenGL minimum
requirements.