2016-02-16 09:53:44 +00:00
|
|
|
// Copyright (c) 2015-2016 The Khronos Group Inc.
|
|
|
|
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
|
|
|
|
|
|
|
|
[[fxvertex]]
|
|
|
|
= Fixed-Function Vertex Processing
|
|
|
|
|
|
|
|
Some implementations have specialized fixed-function hardware for fetching
|
|
|
|
and format-converting vertex input data from buffers, rather than performing
|
Change log for April 29, 2016 Vulkan 1.0.12 spec update:
* Bump API patch number and header version number to 12 for this
update.
Github Issues:
* Change valid usage statements intended to be "sub-points" to
be actual sub-points (public issue 66).
* Replace double negation in description of
slink:VkRenderPassBeginInfo::pname:pClearValues (based on public
merge 142).
* Cleanup minor typos in spec, ref pages and XML, including those
proposed in public pull requests 144, 150, 151, 167, 168, 181, and
186.
* Use *strict subset* in describing the partial order of memory
property types for slink:VkMemoryType, and update the style guide
accordingly (public issue 190).
* Fix various "a image" -> "an image" typos (public issue 191).
* Note in the <<fundamentals-validusage,Valid Usage>> and
<<extensions-interactions,Extension Interactions>> sections that
structures defined by extensions which may be passed in structure
chains using the ptext:pNext member must: include initial
ptext:sType and ptext:pNext members (public issue 192).
Internal Issues:
* Remove duplicate language from the description of the pname:fence
parameter to flink:vkQueueSubmit and improve validity language
(internal issue 91).
* Added documentation for "optional" attribute to XML readme.tex/pdf
(internal issue 149).
* Clarify the host-side data validity rules and behavior of
flink:vkFlushMappedMemoryRanges and
flink:vkInvalidateMappedMemoryRanges (internal issue 266).
Other Commits:
* Added clarification to flink:vkCmdFillBuffer regarding the use of
ename:VK_WHOLE_SIZE.
* Fixed and documented implementation of "validextensionstructs"
attribute. in XML processing scripts and readme.tex/pdf.
* Add missing validity statements to flink:vkResetEvent and
flink:vkCmdResetEvent.
* Fix validity for the
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag.
Correct all the draw/dispatch commands to mention optimally tiled
images as well as linear tiled images, and say image VIEWS instead
of images. Add validity statement to flink:vkCmdBlitImage
* Replace the {apiname} macro with hardcoded "Vulkan", now that we've
committed to that name.
* Add the VK_AMD_rasterization_order extension to vk.xml.
2016-04-29 12:53:46 +00:00
|
|
|
the fetch as part of the vertex shader. Vulkan includes a vertex
|
2016-02-16 09:53:44 +00:00
|
|
|
attribute fetch stage in the graphics pipeline in order to take advantage of
|
|
|
|
this.
|
|
|
|
|
|
|
|
|
|
|
|
[[fxvertex-attrib]]
|
|
|
|
== Vertex Attributes
|
|
|
|
|
|
|
|
Vertex shaders can: define input variables, which receive _vertex attribute_
|
|
|
|
data transferred from one or more sname:VkBuffer(s) by drawing commands.
|
|
|
|
Vertex shader input variables are bound to buffers via an indirect binding
|
|
|
|
where the vertex shader associates a _vertex input attribute_ number with
|
|
|
|
each variable, vertex input attributes are associated to _vertex input
|
|
|
|
bindings_ on a per-pipeline basis, and vertex input bindings are associated
|
|
|
|
with specific buffers on a per-draw basis via the
|
|
|
|
fname:vkCmdBindVertexBuffers command. Vertex input attribute and vertex
|
|
|
|
input binding descriptions also contain format information controlling how
|
|
|
|
data is extracted from buffer memory and converted to the format expected by
|
|
|
|
the vertex shader.
|
|
|
|
|
|
|
|
There are sname:VkPhysicalDeviceLimits::pname:maxVertexInputAttributes
|
|
|
|
number of vertex input attributes and
|
|
|
|
sname:VkPhysicalDeviceLimits::pname:maxVertexInputBindings number of
|
|
|
|
vertex input bindings (each referred to
|
|
|
|
by zero-based indices), where there are at least as many vertex input
|
|
|
|
attributes as there are vertex input bindings. Applications can: store
|
|
|
|
multiple vertex input attributes interleaved in a single buffer, and use a
|
|
|
|
single vertex input binding to access those attributes.
|
|
|
|
|
|
|
|
In GLSL, vertex shaders associate input variables with a vertex input
|
|
|
|
attribute number using the code:location layout qualifier. The
|
|
|
|
code:component layout qualifier associates components of a vertex shader
|
|
|
|
input variable with components of a vertex input attribute.
|
|
|
|
|
|
|
|
.GLSL example
|
|
|
|
[source,{basebackend@docbook:c:glsl}]
|
|
|
|
---------------------------------------------------
|
|
|
|
// Assign location M to variableName
|
|
|
|
layout (location=M, component=2) in vec2 variableName;
|
|
|
|
|
|
|
|
// Assign locations [N,N+L) to the array elements of variableNameArray
|
|
|
|
layout (location=N) in vec4 variableNameArray[L];
|
|
|
|
---------------------------------------------------
|
|
|
|
|
|
|
|
In SPIR-V, vertex shaders associate input variables with a vertex input
|
|
|
|
attribute number using the code:Location decoration. The code:Component
|
|
|
|
decoration associates components of a vertex shader input variable with
|
|
|
|
components of a vertex input attribute. The code:Location and code:Component
|
|
|
|
decorations are specified via the code:OpDecorate instruction.
|
|
|
|
|
|
|
|
.SPIR-V example
|
|
|
|
---------------------------------------------------
|
|
|
|
...
|
|
|
|
%1 = OpExtInstImport "GLSL.std.450"
|
|
|
|
...
|
|
|
|
OpName %9 "variableName"
|
|
|
|
OpName %15 "variableNameArray"
|
Change log for June 24, 2016 Vulkan 1.0.18 spec update:
* Bump API patch number and header version number to 18 for this
update.
Github Issues:
* Added "queue operation" terminology, and modified spec to actually
use this terminology (public issue 155). The act of submitting a
piece of work to a queue now generates "operations" for the queue to
execute, including operations to wait on/signal semaphores and
fences. Synchronization waits on these operations, making execution
dependency chains more obvious for semaphores and fences (though
additional work is still needed here). These changes include:
** Overview of "queue submission" commands in chapter
<<devsandqueues-submission>>.
** Updated descriptions for fence and semaphore waits and signals in
the synchronization chapter <<synchronization-semaphores-waiting>>,
<<synchronization-semaphores-signaling>> and
<<synchronization-fences-waiting>>.
** Clarifications to semaphore and fence operation within queue
submission functions.
** New glossary terms.
** Moved device idle and queue wait idle to synchronization chapter in
order to describe them in terms of other synchronization
primitives.
** Clarifications to semaphore and fence operation allowed removal of
the "implicit ordering guarantees" section, as this information is
now wholly covered where these primitives are described.
*** The "host writes" section of this is still there for now - in its
own section. This could probably be merged into other sections
later.
*** Modified fundamentals chapter on queue ordering to make sense in
context of the new changes, and avoid duplication.
<<fundamentals-queueoperation>>
* Added "aspect" and "component" definitions to the glossary, and made
sure these terms are referenced correctly (public issue 163).
* Update valid usage for ftext:vkGet*ProcAddr to only include
conditions that must be met to get a valid result. In particular,
it's okay to call flink:vkGetDeviceProcAddr with any string and will
get a code:NULL if that string is not a core Vulkan function or an
enabled extension function (addresses but does not fully close
public issue 214).
* Change the WSI extension dependencies to refer to version 1.0 of the
Vulkan API, instead of the pre-1.0-release internal revisions
numbers (public issue 238).
* Specified that <<interfaces-fragmentoutput,undeclared fragment
shader outputs>> result in undefined values input to the blending
unit or color attachment (public issue 240).
Internal Issues:
* Better documented that the registry XML "optional" tag for values
only applies when that value is the size of an array (internal issue
335).
* Add a stronger definition for the valid usages of
VkSpecializationMapEntry.size in the
<<pipelines-specialization-constants,Specialization Constants>>
section (internal issue 345).
* Change code:OpName to code:OpDecorate (along with appropriate
syntax) for vertex shader built-ins (internal issue 368).
* Add missing ref pages (those which are not currently stubs) to
apispec.txt for the single-page version of the ref pages (internal
issue 378).
Other Commits:
* Fix example in the <<descriptorsets,Descriptor Sets>> section to use
M, N, and I, describing set, binding, and index, consistently
throughout the example code.
2016-06-23 10:18:00 +00:00
|
|
|
OpDecorate %18 Builtin VertexIndex
|
|
|
|
OpDecorate %19 Builtin InstanceIndex
|
2016-02-16 09:53:44 +00:00
|
|
|
OpDecorate %9 Location M
|
|
|
|
OpDecorate %9 Component 2
|
|
|
|
OpDecorate %15 Location N
|
|
|
|
...
|
|
|
|
%2 = OpTypeVoid
|
|
|
|
%3 = OpTypeFunction %2
|
|
|
|
%6 = OpTypeFloat 32
|
|
|
|
%7 = OpTypeVector %6 2
|
|
|
|
%8 = OpTypePointer Input %7
|
|
|
|
%9 = OpVariable %8 Input
|
|
|
|
%10 = OpTypeVector %6 4
|
|
|
|
%11 = OpTypeInt 32 0
|
|
|
|
%12 = OpConstant %11 L
|
|
|
|
%13 = OpTypeArray %10 %12
|
|
|
|
%14 = OpTypePointer Input %13
|
|
|
|
%15 = OpVariable %14 Input
|
|
|
|
...
|
|
|
|
---------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
[[fxvertex-attrib-location]]
|
|
|
|
=== Attribute Location and Component Assignment
|
|
|
|
|
|
|
|
Vertex shaders allow code:Location and code:Component decorations on
|
|
|
|
input variable declarations. The code:Location decoration specifies which
|
|
|
|
vertex input attribute is used to read and interpret the data that
|
|
|
|
a variable will consume. The code:Component decoration allows the location
|
|
|
|
to be more finely specified for scalars and vectors, down to the
|
|
|
|
individual components within a location that are consumed. The
|
|
|
|
components within a location are 0, 1, 2, and 3. A variable starting
|
|
|
|
at component N will consume components N, N+1, N+2, ... up through
|
|
|
|
its size. For single precision types, it is invalid if the sequence
|
|
|
|
of components gets larger than 3.
|
|
|
|
|
|
|
|
When a vertex shader input variable declared using a scalar or vector
|
|
|
|
32-bit data type is assigned a location, its value(s) are taken from
|
|
|
|
the components of the input attribute specified with the corresponding
|
|
|
|
sname:VkVertexInputAttributeDescription::pname:location.
|
Change log for March 10, 2016 Vulkan 1.0.6 spec update:
* Bump API patch number and header version number to 6 for this
update.
Github Issues:
* Define 'invocation group' for compute and graphics shaders. Cleanup
definition and use of 'workgroup', and add glossary entries (public
issue 1).
* Various minor editorial fixes (public issue 33).
* Clarify locations for block members in the
<<interfaces-iointerfaces-locations,Location Assignment>>
section (public issue 45).
* Editorial fixes for <<commandbuffer-allocation,Command Buffer
Allocation>> section (public issues 54, 59).
* Clarify behavior of depth test in the <<fragops-depth,Depth
Test>> section (public issues 80, 81).
* Remove discussion of return codes from
flink:vkGetPhysicalDeviceSparseImageFormatProperties and
flink:vkGetImageSparseMemoryRequirements, which don't return values
(public issue 82).
* Allow flink:vkCmdDrawIndirect and flink:vkCmdDrawIndexedIndirect
pname:drawCount of 0, as well as 1, when the multiDrawIndirect
feature is not supported (public issue 88).
* Remove confusing wording in the <<features-limits,Limits>>
section describing the slink:VkPhysicalDeviceLimits
pname:minTexelBufferOffsetAlignment,
pname:minUniformBufferOffsetAlignment, and
pname:minStorageBufferOffsetAlignment members as both minimums and
maximums (public issue 91).
* Clarified that only the RGB components should be affected in places
where sRGB is referred to in the spec, such as ASTC formats. Minor
re-wording to avoid "color space" when actively incorrect, now that
we refer to the Data Format Spec which actually makes a distinction
between color space and transfer function (public issue 94).
* Treat pname:pPropertyCount == 0 consistently in
flink:vkEnumerateInstanceLayerProperties and
flink:vkEnumerateDeviceLayerProperties (public issue 99)
* Cleanup minor editorial issues in chapters 14-17 (public issue 100).
* Clarify definition of flink:vkEnumerateInstanceExtensionProperties
and flink:vkEnumerateDeviceExtensionProperties (public issue 101).
* Define the flink:vkEnumerateInstanceExtensionProperties and
flink:vkEnumerateDeviceExtensionProperties pname:pLayerName
parameter to be a pointer to a null-terminated UTF-8 string (public
issue 101).
* Rearrange "Missing information" references in mandatory format
tables (public issue 101).
* Clarify that the enumerated extensions returned by
flink:vkEnumerateInstanceExtensionProperties and
flink:vkEnumerateDeviceExtensionProperties will only include
extensions provided by the platform or extensions implemented in
implicitly enabled layers (public issue 101).
* Miscellaneous editorial fixes. Include the Vulkan spec patch number
in the PDF title. Fix label on <<fig-non-strict-lines,Non
strict lines>> diagram. Use more easily distinguished symbols in
tables in the <<features-required-format-support,Required
Format Support>> section. Don't require FQDNs used as layer names be
encoded in lower case if not possible, in the
<<extensions-naming-conventions, Extension and Layer Naming
Conventions>> section (public issues 101, 119, 121).
Internal Issues:
* Fixed excessive spacing in tables in XHTML (internal issue 18).
* Clarify that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT
applies to secondary command buffers. Previously spec only referred
to the members of pname:pCommandBuffers being affected by this bit.
Added a separate slink:VkSubmitInfo Valid Usage restriction
specifying that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT
also applies to any secondary command buffers that are recorded into
the primary command buffers in pname:pCommandBuffers (internal issue
106).
* Clarify that slink:VkDeviceCreateInfo::pname:pEnabledFeatures can be
NULL (internal issue 117).
* Remove "the value of" where it is redundant (e.g. speaking of an API
parameter, struct member, or SPIR-V variable, but not when speaking
of color components) (internal issue 175).
* Forced patch version to always be 0 in the header. Add a
"VK_API_VERSION_<major>_<minor>" macro for people to use to do the
right thing. Add a VK_HEADER_VERSION which captures the header
release number independent of the spec patch number (internal issue
176).
* Correct description of
slink:VkPipelineShaderStageCreateInfo::pname:pName to "a pointer to
a null-terminated UTF-8 string" (internal issue #197).
Other Commits:
* Updated DataFormat spec reference to the new date for revision 5 of
that spec.
* Fixed KEEP option (to retain LaTeX intermediate files) in the
Makefile to be included when edited there, as well as set on the
command line.
* Reserve and add "VK_IMG_filter_cubic" to the registry, and implement
script functionality to add and remove validity from existing
functions. Includes schema and readme changes.
* Update GL_KHR_vulkan_glsl so push_constants do not have descriptor
sets.
2016-03-11 01:33:02 +00:00
|
|
|
The components used depend on the type of variable and the
|
2016-02-16 09:53:44 +00:00
|
|
|
code:Component decoration specified in the variable declaration,
|
|
|
|
as identified in <<fxvertex-attrib-components>>. Any 32-bit scalar
|
|
|
|
or vector input will consume a single location. For 32-bit data types,
|
|
|
|
missing components are filled in with default values as described
|
|
|
|
<<fxvertex-input-extraction,below>>.
|
|
|
|
|
|
|
|
|
|
|
|
[[fxvertex-attrib-components]]
|
|
|
|
.Input attribute components accessed by 32-bit input variables
|
|
|
|
[width="65%",cols="<5,<3,<3",options="header"]
|
|
|
|
|=============================================
|
|
|
|
| 32-bit data type | code:Component decoration | Components consumed
|
|
|
|
| scalar | 0 or unspecified | (x, o, o, o)
|
|
|
|
| scalar | 1 | (o, y, o, o)
|
|
|
|
| scalar | 2 | (o, o, z, o)
|
|
|
|
| scalar | 3 | (o, o, o, w)
|
|
|
|
| two-component vector | 0 or unspecified | (x, y, o, o)
|
|
|
|
| two-component vector | 1 | (o, y, z, o)
|
|
|
|
| two-component vector | 2 | (o, o, z, w)
|
|
|
|
| three-component vector| 0 or unspecified | (x, y, z, o)
|
|
|
|
| three-component vector| 1 | (o, y, z, w)
|
|
|
|
| four-component vector | 0 or unspecified | (x, y, z, w)
|
|
|
|
|=============================================
|
|
|
|
|
|
|
|
Components indicated by `o' are available for use by other input variables
|
|
|
|
which are sourced from the same attribute, and if used, are either filled
|
|
|
|
with the corresponding component from the input format (if present), or
|
|
|
|
the default value.
|
|
|
|
|
|
|
|
When a vertex shader input variable declared using a 32-bit floating point
|
|
|
|
matrix type is assigned a location _i_, its values are taken from
|
|
|
|
consecutive input attributes starting with the corresponding
|
|
|
|
sname:VkVertexInputAttributeDescription::pname:location. Such matrices are
|
|
|
|
treated as an array of column vectors with values taken from the input
|
|
|
|
attributes identified in <<fxvertex-attrib-matrix>>. The
|
|
|
|
sname:VkVertexInputAttributeDescription::pname:format must: be specified
|
|
|
|
with a elink:VkFormat that corresponds to the appropriate type of column
|
|
|
|
vector. The code:Component decoration mustnot: be used with matrix types.
|
|
|
|
|
|
|
|
[[fxvertex-attrib-matrix]]
|
|
|
|
.Input attributes accessed by 32-bit input matrix variables
|
|
|
|
[width="100%",cols="<10%,<24%,<21%,<45%",options="header"]
|
|
|
|
|=============================================
|
|
|
|
| Data type | Column vector type | Locations consumed | Components consumed
|
|
|
|
| mat2 | two-component vector | i, i+1 | (x, y, o, o), (x, y, o, o)
|
|
|
|
| mat2x3 | three-component vector | i, i+1 | (x, y, z, o), (x, y, z, o)
|
|
|
|
| mat2x4 | four-component vector | i, i+1 | (x, y, z, w), (x, y, z, w)
|
|
|
|
| mat3x2 | two-component vector | i, i+1, i+2 | (x, y, o, o), (x, y, o, o), (x, y, o, o)
|
|
|
|
| mat3 | three-component vector | i, i+1, i+2 | (x, y, z, o), (x, y, z, o), (x, y, z, o)
|
|
|
|
| mat3x4 | four-component vector | i, i+1, i+2 | (x, y, z, w), (x, y, z, w), (x, y, z, w)
|
|
|
|
| mat4x2 | two-component vector | i, i+1, i+2, i+3 | (x, y, o, o), (x, y, o, o), (x, y, o, o), (x, y, o, o)
|
|
|
|
| mat4x3 | three-component vector | i, i+1, i+2, i+3 | (x, y, z, o), (x, y, z, o), (x, y, z, o), (x, y, z, o)
|
|
|
|
| mat4 | four-component vector | i, i+1, i+2, i+3 | (x, y, z, w), (x, y, z, w), (x, y, z, w), (x, y, z, w)
|
|
|
|
|=============================================
|
|
|
|
|
|
|
|
Components indicated by `o' are available for use by other input variables
|
|
|
|
which are sourced from the same attribute, and if used, are either filled
|
|
|
|
with the corresponding component from the input (if present), or
|
|
|
|
the default value.
|
|
|
|
|
|
|
|
When a vertex shader input variable declared using a scalar or vector
|
|
|
|
64-bit data type is assigned a location _i_, its values are taken from
|
|
|
|
consecutive input attributes starting with the corresponding
|
|
|
|
sname:VkVertexInputAttributeDescription::pname:location. The locations
|
|
|
|
and components used depend on the type of variable and the code:Component
|
|
|
|
decoration specified in the variable declaration, as identified in
|
|
|
|
<<fxvertex-attrib-double>>. For 64-bit data types, no default
|
|
|
|
attribute values are provided. Input variables mustnot: use more
|
|
|
|
components than provided by the attribute. Input attributes which have
|
|
|
|
one- or two-component 64-bit formats will consume a single location.
|
|
|
|
Input attributes which have three- or four-component 64-bit formats
|
|
|
|
will consume two consecutive locations. A 64-bit scalar
|
|
|
|
data type will consume two components, and a 64-bit two-component
|
|
|
|
vector data type will consume all four components available within
|
|
|
|
a location. A three- or four-component 64-bit data type mustnot:
|
|
|
|
specify a component. A three-component 64-bit data type will consume
|
|
|
|
all four components of the first location and components 0 and 1 of
|
|
|
|
the second location. This leaves components 2 and 3 available for
|
|
|
|
other component-qualified declarations. A four-component 64-bit
|
|
|
|
data type will consume all four components of the first location
|
|
|
|
and all four components of the second location. It is invalid for
|
|
|
|
a scalar or two-component 64-bit data type to specify a component
|
|
|
|
of 1 or 3.
|
|
|
|
|
|
|
|
[[fxvertex-attrib-double]]
|
|
|
|
.Input attribute locations and components accessed by 64-bit input variables
|
|
|
|
[width="100%",cols="<18%,^12%,<25%,^14%,^18%,<13%",options="header"]
|
|
|
|
|=============================================
|
|
|
|
^.^| Input format | Locations consumed
|
|
|
|
^.^| 64-bit data type |code:Location decoration |code:Component decoration ^| 32-bit components consumed
|
|
|
|
| R64 | i
|
|
|
|
| scalar | i | 0 or unspecified | (x, y, -, -)
|
|
|
|
.3+<.^| R64G64 .3+^.^| i
|
|
|
|
| scalar | i | 0 or unspecified | (x, y, o, o)
|
|
|
|
| scalar | i | 2 | (o, o, z, w)
|
|
|
|
| two-component vector | i | 0 or unspecified | (x, y, z, w)
|
|
|
|
.5+<.^| R64G64B64 .5+^.^| i, i+1
|
|
|
|
| scalar | i | 0 or unspecified | (x, y, o, o), (o, o, -, -)
|
|
|
|
| scalar | i | 2 | (o, o, z, w), (o, o, -, -)
|
|
|
|
| scalar | i+1 | 0 or unspecified | (o, o, o, o), (x, y, -, -)
|
|
|
|
| two-component vector | i | 0 or unspecified | (x, y, z, w), (o, o, -, -)
|
|
|
|
| three-component vector | i | unspecified | (x, y, z, w), (x, y, -, -)
|
|
|
|
.8+<.^| R64G64B64A64 .8+^.^| i, i+1
|
|
|
|
| scalar | i | 0 or unspecified | (x, y, o, o), (o, o, o, o)
|
|
|
|
| scalar | i | 2 | (o, o, z, w), (o, o, o, o)
|
|
|
|
| scalar | i+1 | 0 or unspecified | (o, o, o, o), (x, y, o, o)
|
|
|
|
| scalar | i+1 | 2 | (o, o, o, o), (o, o, z, w)
|
|
|
|
| two-component vector | i | 0 or unspecified | (x, y, z, w), (o, o, o, o)
|
|
|
|
| two-component vector | i+1 | 0 or unspecified | (o, o, o, o), (x, y, z, w)
|
|
|
|
| three-component vector | i | unspecified | (x, y, z, w), (x, y, o, o)
|
|
|
|
| four-component vector | i | unspecified | (x, y, z, w), (x, y, z, w)
|
|
|
|
|=============================================
|
|
|
|
|
|
|
|
Components indicated by `o' are available for use by other input variables
|
|
|
|
which are sourced from the same attribute.
|
|
|
|
Components indicated by `-' are not available for input variables
|
|
|
|
as there are no default values provided for 64-bit data types, and
|
|
|
|
there is no data provided by the input format.
|
|
|
|
|
|
|
|
When a vertex shader input variable declared using a 64-bit floating-point
|
|
|
|
matrix type is assigned a location _i_, its values are taken from
|
|
|
|
consecutive input attribute locations. Such matrices are treated as an array
|
|
|
|
of column vectors with values taken from the input attributes as shown in
|
|
|
|
<<fxvertex-attrib-double>>. Each column vector starts at the location
|
|
|
|
immediately following the last location of the previous column vector. The
|
|
|
|
number of attributes and components assigned to each matrix is determined by
|
|
|
|
the matrix dimensions and ranges from two to eight locations.
|
|
|
|
|
|
|
|
When a vertex shader input variable declared using an array type
|
|
|
|
is assigned a location, its values are taken from consecutive
|
|
|
|
input attributes starting with the corresponding
|
|
|
|
sname:VkVertexInputAttributeDescription::pname:location. The number
|
|
|
|
of attributes and components assigned to each element are determined
|
|
|
|
according to the data type of the array elements and code:Component
|
|
|
|
decoration (if any) specified in the declaration of the array, as described
|
|
|
|
above. Each element of the array, in order, is assigned to consecutive
|
|
|
|
locations, but all at the same specified component within each location.
|
|
|
|
|
|
|
|
Only input variables declared with the data types and component decorations
|
|
|
|
as specified above are supported. _Location aliasing_ is
|
|
|
|
causing two variables to have the same location number. _Component aliasing_
|
|
|
|
is assigning the same (or overlapping) component number for
|
|
|
|
two location aliases. Location aliasing is allowed only if it does
|
Change log for March 25, 2016 Vulkan 1.0.7 spec update:
* Bump API patch number and header version number to 7 for this
update.
Github Issues:
* Fix slink:VkSpecializationMapEntry example to avoid C/C++ strict
aliasing issues (public issue 14).
* Clarify the meaning of "matching" in flink:vkCmdBindDescriptorSets
validity language (public issue 33).
* Add stub reference pages so xrefs to not-yet-written pages don't
generate 404 errors. However, the actual content of these pages
still needs to be filled in as time allows (public issue 44, but
does not close that issue out).
* Remove incorrect validity statement for
flink:vkGetImageSparseMemoryRequirements (public issue 85).
* Reword the
<<features-limits-bufferImageGranularity,bufferImageGranularity>>
feature in terms of "aliasing", and clarify that it applies to
bindings in the same memory object (public issue 90).
* Clarify the relationship of the slink:VkPhysicalDeviceLimits
pname:maxViewportDimensions and pname:viewportBoundsRange limits
(public issue 92).
* Specify sparse unbound texture replacement in the
<<textures-texel-replacement,Texel Replacement>> section
independently of robust buffer access language (public issue 100).
* Add the <<fundamentals-architecture-model,Architecture Model>>
section to explain architecture constraints Vulkan has chosen to
accept in order to enable portable and performant code (public issue
122).
* State that an object must not be destroyed until *all* (not *any*)
uses of that object have completed (public issue 123).
* Minor editorial cleanup (public issues 129, 134, 146, 148).
* Add validity language for layer and extension names to
slink:VkDeviceCreateInfo matching that used for
slink:VkInstanceCreateInfo (public issue 130).
* Clean up terminology for the case when the bits set in one bitmask
are a subset of the bits set in another bitmask (public issue 138).
* Document that input attachments are UniformConstant not Input, in
the <<interfaces-inputattachment,Fragment Input Attachment
Interface>> section (public glslang bug 169).
Internal Issues:
* Add max enum values to "flag bits" enums (internal issue #136).
* Clarify language around the various uses of the term "block" in the
<<appendix-compressedtex-bc,Block Compressed Image Formats>> section
(internal issue #202).
* Removed "expand" dependency from <enums> groups in vk.xml and added
auto-generation code in the scripts to infer it instead, to ensure
consistency. This caused renaming of sname:VkColorSpaceKHR and
sname:VkPresentModeKHR etext:BEGIN_RANGE (etc.) tokens, but those
tokens are metadata, not part of the API, and the Vulkan WG is OK
with this change. This change adds ranges to two additional enums
that were missing them due to not defining the "expand" attribute
(internal issue 217).
* Tweak makefile to generate ref page nroff (.3) files in the right
output directory, working around an a2x limitation (internal issue
223).
Other Commits:
* Add validity requirements for flink:vkCmdCopyQueryPoolResults
pname:dstBuffer parameter.
* Fix ref page build to generate .3 targets in the right output
directory.
2016-03-25 09:25:04 +00:00
|
|
|
not cause component aliasing. Further, when location aliasing, the
|
2016-02-16 09:53:44 +00:00
|
|
|
aliases sharing the location must: have the same underlying numerical
|
|
|
|
type (floating-point or integer). Failure to meet these requirements
|
|
|
|
will result in an invalid pipeline.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[[fxvertex-input]]
|
|
|
|
== Vertex Input Description
|
|
|
|
|
|
|
|
Applications specify vertex input attribute and vertex input binding
|
2016-04-21 08:08:38 +00:00
|
|
|
descriptions as part of graphics pipeline creation. The
|
|
|
|
slink:VkGraphicsPipelineCreateInfo::pname:pVertexInputState points to a
|
|
|
|
structure of type sname:VkPipelineVertexInputStateCreateInfo.
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-04-21 08:08:38 +00:00
|
|
|
The sname:VkPipelineVertexInputStateCreateInfo structure is defined as:
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-04-21 08:08:38 +00:00
|
|
|
include::../structs/VkPipelineVertexInputStateCreateInfo.txt[]
|
2016-02-16 09:53:44 +00:00
|
|
|
|
|
|
|
* pname:sType is the type of this structure.
|
|
|
|
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
|
|
|
|
* pname:flags is reserved for future use.
|
|
|
|
* pname:vertexBindingDescriptionCount is the number of vertex binding
|
|
|
|
descriptions provided in pname:pVertexBindingDescriptions.
|
|
|
|
* pname:pVertexBindingDescriptions is a pointer to an array of
|
|
|
|
sname:VkVertexInputBindingDescription structures.
|
|
|
|
* pname:vertexAttributeDescriptionCount is the number of vertex attribute
|
|
|
|
descriptions provided in pname:pVertexAttributeDescriptions.
|
|
|
|
* pname:pVertexAttributeDescriptions is a pointer to an array of
|
|
|
|
sname:VkVertexInputAttributeDescription structures.
|
|
|
|
|
|
|
|
include::../validity/structs/VkPipelineVertexInputStateCreateInfo.txt[]
|
|
|
|
|
|
|
|
Each vertex input binding is specified by an instance of the
|
2016-04-21 08:08:38 +00:00
|
|
|
sname:VkVertexInputBindingDescription structure.
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-04-21 08:08:38 +00:00
|
|
|
The sname:VkVertexInputBindingDescription structure is defined as:
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-04-21 08:08:38 +00:00
|
|
|
include::../structs/VkVertexInputBindingDescription.txt[]
|
2016-02-16 09:53:44 +00:00
|
|
|
|
|
|
|
* pname:binding is the binding number that this structure
|
|
|
|
describes.
|
|
|
|
* pname:stride is the distance in bytes between two
|
|
|
|
consecutive elements within the buffer.
|
|
|
|
* pname:inputRate is a elink:VkVertexInputRate value that specifies
|
|
|
|
whether vertex attribute addressing is a function of the vertex index or
|
|
|
|
of the instance index.
|
|
|
|
|
|
|
|
include::../validity/structs/VkVertexInputBindingDescription.txt[]
|
|
|
|
|
2016-04-21 08:08:38 +00:00
|
|
|
elink:VkVertexInputRate is defined as:
|
2016-02-16 09:53:44 +00:00
|
|
|
|
|
|
|
include::../enums/VkVertexInputRate.txt[]
|
|
|
|
|
|
|
|
The values of elink:VkVertexInputRate have the following meanings:
|
|
|
|
|
|
|
|
* ename:VK_VERTEX_INPUT_RATE_VERTEX indicates that vertex attribute
|
|
|
|
addressing is a function of the vertex index.
|
|
|
|
* ename:VK_VERTEX_INPUT_RATE_INSTANCE indicates that vertex attribute
|
|
|
|
addressing is a function of the instance index.
|
|
|
|
|
|
|
|
Each vertex input attribute is specified by an instance of the
|
2016-04-21 08:08:38 +00:00
|
|
|
sname:VkVertexInputAttributeDescription structure.
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-04-21 08:08:38 +00:00
|
|
|
The sname:VkVertexInputAttributeDescription structure is defined as:
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-04-21 08:08:38 +00:00
|
|
|
include::../structs/VkVertexInputAttributeDescription.txt[]
|
2016-02-16 09:53:44 +00:00
|
|
|
|
|
|
|
* pname:location is the shader binding location number for this
|
|
|
|
attribute.
|
|
|
|
* pname:binding is the binding number which this attribute takes
|
|
|
|
its data from.
|
|
|
|
* pname:format is the size and type of the vertex attribute data.
|
|
|
|
* pname:offset is a byte offset of this attribute relative
|
|
|
|
to the start of an element in the vertex input binding.
|
|
|
|
|
|
|
|
include::../validity/structs/VkVertexInputAttributeDescription.txt[]
|
|
|
|
|
|
|
|
Vertex buffers are bound to a command buffer for use in subsequent draw
|
|
|
|
commands by calling:
|
|
|
|
|
|
|
|
include::../protos/vkCmdBindVertexBuffers.txt[]
|
|
|
|
|
|
|
|
* pname:commandBuffer is the command buffer into which the command is
|
|
|
|
recorded.
|
|
|
|
* pname:firstBinding is the index of the first vertex input binding whose
|
|
|
|
state is updated by the command.
|
|
|
|
* pname:bindingCount is the number of vertex input bindings whose state is
|
|
|
|
updated by the command.
|
|
|
|
* pname:pBuffers is a pointer to an array of buffer handles.
|
|
|
|
* pname:pOffsets is a pointer to an array of buffer offsets.
|
|
|
|
|
|
|
|
The values taken from elements latexmath:[$i$] of pname:pBuffers and
|
|
|
|
pname:pOffsets replace the current state for the vertex input binding
|
|
|
|
latexmath:[$\mathit{firstBinding}+i$], for latexmath:[$i$] in
|
|
|
|
latexmath:[$[0, bindingCount)$]. The vertex input binding is updated to
|
|
|
|
start at the offset indicated by pname:pOffsets[i] from the start of the
|
|
|
|
buffer pname:pBuffers[i]. All vertex input attributes that use each of these
|
|
|
|
bindings will use these updated addresses in their address calculations for
|
|
|
|
subsequent draw commands.
|
|
|
|
|
|
|
|
include::../validity/protos/vkCmdBindVertexBuffers.txt[]
|
|
|
|
|
|
|
|
The address of each attribute for each code:vertexIndex and
|
|
|
|
code:instanceIndex is calculated as follows:
|
|
|
|
|
|
|
|
- Let attribDesc be the member of
|
|
|
|
sname:VkPipelineVertexInputStateCreateInfo::pname:pVertexAttributeDescriptions
|
|
|
|
with sname:VkVertexInputAttributeDescription::pname:location equal to
|
|
|
|
the vertex input attribute number.
|
|
|
|
- Let bindingDesc be the member of
|
|
|
|
sname:VkPipelineVertexInputStateCreateInfo::pname:pVertexBindingDescriptions
|
|
|
|
with sname:VkVertexInputAttributeDescription::pname:binding equal to
|
|
|
|
attribDesc.binding.
|
|
|
|
- Let code:vertexIndex be the index of the vertex within the draw (a value
|
|
|
|
between pname:firstVertex and pname:firstVertex+pname:vertexCount for
|
|
|
|
fname:vkCmdDraw, or a value taken from the index buffer for
|
|
|
|
fname:vkCmdDrawIndexed), and let code:instanceIndex be the instance
|
|
|
|
number of the draw (a value between pname:firstInstance and
|
|
|
|
pname:firstInstance+pname:instanceCount).
|
|
|
|
|
|
|
|
[source,c]
|
|
|
|
---------------------------------------------------
|
|
|
|
bufferBindingAddress = buffer[binding].baseAddress + offset[binding];
|
|
|
|
|
|
|
|
if (bindingDesc.inputRate == VK_VERTEX_INPUT_RATE_VERTEX)
|
|
|
|
vertexOffset = vertexIndex * bindingDesc.stride;
|
|
|
|
else
|
|
|
|
vertexOffset = instanceIndex * bindingDesc.stride;
|
|
|
|
|
|
|
|
attribAddress = bufferBindingAddress + vertexOffset + attribDesc.offset;
|
|
|
|
---------------------------------------------------
|
|
|
|
|
|
|
|
[[fxvertex-input-extraction]]
|
|
|
|
For each attribute, raw data is extracted starting at `attribAddress` and is
|
|
|
|
converted from the sname:VkVertexInputAttributeDescription's pname:format to
|
|
|
|
either to floating-point, unsigned integer, or signed integer based on the
|
|
|
|
base type of the format; the base type of the format must: match the base
|
|
|
|
type of the input variable in the shader. If pname:format is a packed
|
|
|
|
format, `attribAddress` must: be a multiple of the size in bytes of the
|
|
|
|
whole attribute data type as described in <<features-formats-packed,Packed
|
|
|
|
Formats>>. Otherwise, `attribAddress` must: be a multiple of the size in
|
|
|
|
bytes of the component type indicated by pname:format (see
|
|
|
|
<<features-formats,Formats>>). If the format does not include G, B, or A
|
|
|
|
components, then those are filled with (0,0,1) as needed (using either 1.0f
|
|
|
|
or integer 1 based on the format) for attributes that are not 64-bit data
|
|
|
|
types. The number of components in the vertex shader input variable need not
|
|
|
|
exactly match the number of components in the format. If the vertex shader
|
|
|
|
has fewer components, the extra components are discarded.
|
|
|
|
|
|
|
|
|
|
|
|
[[fxvertex-example]]
|
|
|
|
== Example
|
|
|
|
|
|
|
|
To create a graphics pipeline that uses the following vertex description:
|
|
|
|
|
|
|
|
[source,{basebackend@docbook:c++:cpp}]
|
|
|
|
---------------------------------------------------
|
|
|
|
struct Vertex
|
|
|
|
{
|
|
|
|
float x, y, z, w;
|
|
|
|
uint8_t u, v;
|
|
|
|
};
|
|
|
|
---------------------------------------------------
|
|
|
|
|
|
|
|
The application could use the following set of structures:
|
|
|
|
|
|
|
|
[source,{basebackend@docbook:c++:cpp}]
|
|
|
|
---------------------------------------------------
|
|
|
|
const VkVertexInputBindingDescription binding =
|
|
|
|
{
|
|
|
|
0, // binding
|
|
|
|
sizeof(Vertex), // stride
|
|
|
|
VK_VERTEX_INPUT_RATE_VERTEX // inputRate
|
|
|
|
};
|
|
|
|
|
|
|
|
const VkVertexInputAttributeDescription attributes[] =
|
|
|
|
{
|
|
|
|
{
|
|
|
|
0, // location
|
|
|
|
binding.binding, // binding
|
|
|
|
VK_FORMAT_R32G32B32A32_SFLOAT, // format
|
|
|
|
0 // offset
|
|
|
|
},
|
|
|
|
{
|
|
|
|
1, // location
|
|
|
|
binding.binding, // binding
|
|
|
|
VK_FORMAT_R8G8_UNORM, // format
|
|
|
|
4 * sizeof(float) // offset
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
const VkPipelineVertexInputStateCreateInfo viInfo =
|
|
|
|
{
|
|
|
|
VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_CREATE_INFO, // sType
|
|
|
|
NULL, // pNext
|
|
|
|
0, // flags
|
|
|
|
1, // vertexBindingDescriptionCount
|
|
|
|
&binding, // pVertexBindingDescriptions
|
|
|
|
2, // vertexAttributeDescriptionCount
|
|
|
|
&attributes[0] // pVertexAttributeDescriptions
|
|
|
|
};
|
|
|
|
---------------------------------------------------
|