Vulkan-Docs/appendices/VK_EXT_buffer_device_address.txt
Jon Leech 22a5a1459f Change log for October 6, 2019 Vulkan 1.1.124 spec update:
* Update release number to 124.

Github Issues:

  * Fix Makefile SPECREMARK macro to work when not building in a git tree
    (public issue 992).
  * Ignore pname:aspectMask for unused attachments in
    slink:VkSubpassDescription2KHR valid usage statements (public pull
    request 1028).
  * Minor markup / spelling fixes (public pull requests 1035, 1045).

Internal Issues:

  * Fix markup in Valid Usage statement for slink:VkCreateFramebuffer
    (internal issue 1823).
  * Add a new <<synchronization-signal-operation-order, _signal operation
    order_>> section to the synchronization chapter which describes in
    detail the ordering guarantees provided by the API between fence and
    semaphore signal operations (internal merge request 3368).
  * Move generated `appendix/meta/` files into the Makefile GENERATED
    directory (internal merge request 3381).

New Extensions

  * `<<VK_KHR_shader_clock>>`
  * `<<VK_KHR_timeline_semaphore>>`
2019-10-06 12:42:12 -07:00

85 lines
2.4 KiB
Plaintext

include::{generated}/meta/VK_EXT_buffer_device_address.txt[]
*Last Modified Date*::
2019-01-06
*IP Status*::
No known IP claims.
*Contributors*::
- Jeff Bolz, NVIDIA
- Neil Henning, AMD
- Tobias Hector, AMD
- Jason Ekstrand, Intel
- Baldur Karlsson, Valve
This extension allows the application to query a 64-bit buffer device
address value for a buffer, which can be used to access the buffer memory
via the code:PhysicalStorageBufferEXT storage class in the
https://github.com/KhronosGroup/GLSL/blob/master/extensions/ext/GLSL_EXT_buffer_reference.txt[`GL_EXT_buffer_reference`]
GLSL extension and
{spirv}/EXT/SPV_EXT_physical_storage_buffer.html[`SPV_EXT_physical_storage_buffer`]
SPIR-V extension.
It also allows buffer device addresses to be provided by a trace replay
tool, so that it matches the address used when the trace was captured.
=== New Object Types
None
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT
** ename:VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_EXT
** ename:VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_CREATE_INFO_EXT
* Extending elink:VkBufferUsageFlagBits:
** ename:VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_EXT
* Extending elink:VkBufferCreateFlagBits:
** ename:VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_EXT
* Extending elink:VkResult:
** ename:VK_ERROR_INVALID_DEVICE_ADDRESS_EXT
=== New Enums
None
=== New Structures
* slink:VkPhysicalDeviceBufferDeviceAddressFeaturesEXT
* slink:VkBufferDeviceAddressInfoEXT
* slink:VkBufferDeviceAddressCreateInfoEXT
=== New Functions
* flink:vkGetBufferDeviceAddressEXT
=== New Built-In Variables
None
=== New SPIR-V Capabilities
* <<spirvenv-capabilities-table-physicalstoragebufferaddresses,code:PhysicalStorageBufferAddressesEXT>>
=== Issues
1) Where is VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT
and VkPhysicalDeviceBufferAddressFeaturesEXT?
*RESOLVED*: They were renamed as
ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT
and slink:VkPhysicalDeviceBufferDeviceAddressFeaturesEXT accordingly for
consistency.
Even though, the old names can still be found in the generated header files
for compatibility.
=== Version History
* Revision 1, 2018-11-01 (Jeff Bolz)
- Internal revisions
* Revision 2, 2019-01-06 (Jon Leech)
- Minor updates to appendix for publication