Vulkan-Docs/appendices/VK_KHR_shader_float_controls.txt
Jon Leech 56e0289318 Change log for January 05, 2019 Vulkan 1.1.97 spec update:
* Update release number to 97.

Public Issues:

  * Add a special case to the <<renderpass-compatibility, Render Pass
    Compatibility>> rules allowing single-subpass renderpasses to be
    compatible even if they have different resolve attachment references
    (public issue 835).
  * Fix the miss shader binding table record address rule in the
    <<shader-binding-table-indexing-rules, Miss Shaders>> section to index
    by code:missIndex, not code:sbtOffset (public issue 875).

Internal Issues:

  * Add a missing anchor to the elink:VkSamplerCreateFlagBits language
    (internal issue 1483).
  * Add missing implicit valid usage include for slink:VkHdrMetadataEXT and
    corresponding `noautovalidity` attributes in `vk.xml` for the
    externally-defined metadata properties (internal issue 1514).
  * Remove restrictions on the `mask` parameter of SPIR-V's
    code:OpGroupNonUniformXor in the <<spirvenv-module-validation,
    Validation Rules within a Module>> appendix (internal merge request
    2971).
  * Restore `noautovalidity` attribute for
    slink:VkPipelineViewportWScalingStateCreateInfoNV::pname:pViewportWScalings
    in `vk.xml` (internal merge request 2975).
  * Update copyright dates on Khronos-copyrighted files to 2019 (internal
    merge request 2980).

New Extensions:

  * `VK_KHR_depth_stencil_resolve`
  * `VK_EXT_buffer_device_address`
  * `VK_EXT_memory_budget`
  * `VK_EXT_memory_priority`
  * `VK_EXT_validation_features`
2019-01-05 19:40:12 -08:00

103 lines
3.3 KiB
Plaintext

// Copyright (c) 2014-2019 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_shader_float_controls.txt[]
*Last Modified Date*::
2018-09-11
*IP Status*::
No known IP claims.
*Interactions and External Dependencies*::
- This extension requires
https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_float_controls.html[`SPV_KHR_float_controls`]
*Contributors*::
- Alexander Galazin, Arm
- Jan-Harald Fredriksen, Arm
- Jeff Bolz, NVIDIA
- Graeme Leese, Broadcom
- Daniel Rakos, AMD
=== Description
The `VK_KHR_shader_float_controls` extension enables efficient use of
floating-point computations through the ability to query and override the
implementation's default behavior for rounding modes, denormals, signed
zero, and infinity.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR
=== New Enums
* None
=== New Structures
* slink:VkPhysicalDeviceFloatControlsPropertiesKHR
=== New Functions
* None
=== New SPIR-V Capabilities
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:DenormPreserve>>
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:DenormFlushToZero>>
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:SignedZeroInfNanPreserve>>
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:RoundingModeRTE>>
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:RoundingModeRTZ>>
=== Issues
1) Which instructions must flush denorms?
*RESOLVED*: Only floating-point conversion, floating-point arithmetic,
floating-point relational (except code:OpIsNaN, code:OpIsInf), and
floating-point GLSL.std.450 extended instructions must flush denormals.
2) What is the denorm behavior for intermediate results?
*RESOLVED*: When a SPIR-V instruction is implemented as a sequence of other
instructions:
- in the code:DenormFlushToZero execution mode the intermediate
instructions may flush denormals, the final result of the sequence must:
not be denormal.
- in the code:DenormPreserve execution mode denormals must be preserved
throughout the whole sequence.
3) Do denorm and rounding mode controls apply to code:OpSpecConstantOp?
*RESOLVED*: Yes, except when the opcode is code:OpQuantizeToF16.
4) The SPIR-V specification says that code:OpConvertFToU and
code:OpConvertFToS unconditionally round towards zero.
Do the rounding mode controls specified through the execution modes apply to
them?
*RESOLVED*: No, these instructions unconditionally round towards zero.
5) Do any of the "Pack" GLSL.std.450 instructions count as conversion
instructions and have the rounding mode apply?
*RESOLVED*: No, only instructions listed in the section "3.32.11.
Conversion Instructions" of the SPIR-V specification count as conversion
instructions.
6) When using inf/nan-ignore mode, what is expected of code:OpIsNan and
code:OpIsInf?
*RESOLVED*: These instructions must always accurately detect inf/nan if it
is passed to them.
=== Version History
* Revision 3, 2018-09-11 (Alexander Galazin)
- Minor restructuring
* Revision 2, 2018-04-17 (Alexander Galazin)
- Added issues and resolutions
* Revision 1, 2018-04-11 (Alexander Galazin)
- Initial draft