status-im
/
Vulkan-Docs
mirror of https://github.com/status-im/Vulkan-Docs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
Vulkan-Docs/appendices/VK_EXT_transform_feedback.txt

142 lines
4.9 KiB
Plaintext
Raw Normal View History

Change log for October 13, 2018 Vulkan 1.1.88 spec update: * Update release number to 88. Public Issues: * Make clear that tname:PFN_vkDebugUtilsMessengerCallbackEXT::pname:messageTypes is a bitmask, and correct a typo in the spelling of slink:VkDebugUtilsMessengerCreateInfoEXT.txt::pname:messageType (public pull request 800). * Make an ABI-compatible change of the type of slink:VkPhysicalDeviceDriverPropertiesKHR::pname:driverID to use the new elink:VkDriverIdKHR type (public issue 811). Internal Issues: * Clarify for the <<features-features-shaderStorageImageExtendedFormats>> feature and in the <<spirvenv-capabilities-table>> that the feature means that all of the formats are supported, and that otherwise the features can be queried per-format (internal issue 1273). * Clarified interactions of `VK_EXT_external_memory_host` with host cache management commands and structures flink:vkMapMemory, flink:vkFlushMappedMemoryRanges, slink:VkMappedMemoryRange, and flink:vkUnmapMemory using the new glossary term "`Host Mapped Device Memory`" (internal issue 1385). * Update the language for flink:vkCreateViSurfaceNN.txt describing the pname:currentExtent of a VI surface to more accurately reflect current capabilities, replacing "`undefined`" with more explicit behavior (internal issue 1410). New Extensions: * `VK_EXT_calibrated_timestamps` * `VK_EXT_image_drm_format_modifier` (this extension was previously disabled in vk.xml, and has now been enabled after some changes to fix performance issues). * `VK_EXT_pci_bus_info` * `VK_EXT_transform_feedback` * `VK_GOOGLE_hlsl_functionality1`, exposing support for `SPV_GOOGLE_hlsl_functionality1`. * `VK_GOOGLE_decorate_string`, exposing support for `SPV_GOOGLE_decorate_string`.
2018-10-13 10:23:03 +00:00
include::meta/VK_EXT_transform_feedback.txt[]
*Last Modified Data*::
2018-10-09
*Contributors*::
- Baldur Karlsson, Valve
- Boris Zanin, Mobica
- Daniel Rakos, AMD
- Donald Scorgie, Imagination
- Henri Verbeet, CodeWeavers
- Jan-Harald Fredriksen, Arm
- Jason Ekstrand, Intel
- Jeff Bolz, NVIDIA
- Jesse Barker, Unity
- Jesse Hall, Google
- Pierre-Loup Griffais, Valve
- Philip Rebohle, DXVK
- Ruihao Zhang, Qualcomm
- Samuel Pitoiset, Valve
- Slawomir Grajewski, Intel
- Stu Smith, Imagination Technologies
This extension adds transform feedback to the Vulkan API by exposing the
SPIR-V code:TransformFeedback and code:GeometryStreams capabilities to
capture vertex, tessellation or geometry shader outputs to one or more
buffers.
It adds API functionality to bind transform feedback buffers to capture the
primitives emitted by the graphics pipeline from SPIR-V outputs decorated
for transform feedback.
The transform feedback capture can be paused and resumed by way of storing
and retrieving a byte counter.
The captured data can be drawn again where the vertex count is derived from
the byte counter without CPU intervention.
If the implementation is capable, a vertex stream other than zero can be
rasterized.
All these features are designed to match the full capabilities of OpenGL
core transform feedback functionality and beyond.
Many of the features are optional to allow base OpenGL ES GPUs to also
implement this extension.
The primary purpose of the functionality exposed by this extension is to
support translation layers from other 3D APIs.
This functionality is not considered forward looking, and is not expected to
be promoted to a KHR extension or to core Vulkan.
Unless this is needed for translation, it is recommended that developers use
alternative techniques of using the GPU to process and capture vertex data.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_FEATURES_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_PROPERTIES_EXT
** ename:VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_STREAM_CREATE_INFO_EXT
* Extending elink:VkQueryType:
** ename:VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT
* Extending elink:VkBufferUsageFlagBits:
** ename:VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT
** ename:VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT
* Extending elink:VkAccessFlagBits:
** ename:VK_ACCESS_TRANSFORM_FEEDBACK_WRITE_BIT_EXT
** ename:VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT
** ename:VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT
* Extending elink:VkPipelineStageFlagBits:
** ename:VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT
=== New Enums
* elink:VkPipelineRasterizationStateStreamCreateFlagsEXT
=== New Structures
* Extending slink:VkPhysicalDeviceFeatures2:
** slink:VkPhysicalDeviceTransformFeedbackFeaturesEXT
* Extending slink:VkPhysicalDeviceProperties2:
** slink:VkPhysicalDeviceTransformFeedbackPropertiesEXT
* Extending slink:VkPipelineRasterizationStateCreateInfo
** slink:VkPipelineRasterizationStateStreamCreateInfoEXT
=== New Functions
* flink:vkCmdBindTransformFeedbackBuffersEXT
* flink:vkCmdBeginTransformFeedbackEXT
* flink:vkCmdEndTransformFeedbackEXT
* flink:vkCmdBeginQueryIndexedEXT
* flink:vkCmdEndQueryIndexedEXT
* flink:vkCmdDrawIndirectByteCountEXT
=== Issues
1) Should we include pause/resume functionality?
*RESOLVED*: Yes, this is needed to ease layering other APIs which have this
functionality.
To pause use fname:vkCmdEndTransformFeedbackEXT and provide valid buffer
handles in the pname:pCounterBuffers array and offsets in the
pname:pCounterBufferOffsets array for the implementation to save the resume
points.
Then to resume use fname:vkCmdBeginTransformFeedbackEXT with the previous
pname:pCounterBuffers and pname:pCounterBufferOffsets values.
Between the pause and resume there needs to be a memory barrier for the
counter buffers with a source access of
ename:VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT at pipeline stage
ename:VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT to a destination access
of ename:VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT at pipeline stage
ename:VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT.
2) How does this interact with multiview?
*RESOLVED*: Transform feedback cannot be made active in a render pass with
multiview enabled.
3) How should queries be done?
*RESOLVED*: There is a new query type
ename:VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT.
 query pool created with this type will capture 2 integers -
numPrimitivesWritten and numPrimitivesNeeded - for the specified vertex
stream output from the last vertex processing stage.
The vertex stream output queried is zero by default, but can be specified
with the new fname:vkCmdBeginQueryIndexedEXT and
fname:vkCmdEndQueryIndexedEXT commands.
=== Version History
* Revision 1, 2018-10-09 (Piers Daniell)
- Internal revisions