Cybernetic Vermin posted:

half life 3 will surely usher in the era of vulcan

Tankakern posted:

good for you i guess

graph posted:

did apple create the whole metanarrative thing when they'd do the white background jony ive videos for loving everything like 8 years ago

PleasureKevin posted:

I feel like Vulkan is one of those things everyone talks about assuming it will be the future but 5 years from now we'll all be like hey whatever happened to that thing

The_Franz posted:

https://www.youtube.com/watch?v=FnKu7MLB7vQ

akadajet posted:

never forget:

akadajet posted:

never forget:

Amethyst posted:

this is the best summary i've seen on why vulkan is a thing http://blog.mecheye.net/2015/12/why-im-excited-for-vulkan/

Amethyst posted:

this is the best summary i've seen on why vulkan is a thing http://blog.mecheye.net/2015/12/why-im-excited-for-vulkan/

PleasureKevin posted:

dude this says nothing about why people will actually use it. in fact it says the opposite. it says nVidia hates it and Microsoft is rushing to kill it. maybe you're not aware but these are powerful companies that tend to bend things to their will with money. plus it says it's as hard to use as PS2 development.

Amethyst posted:

you're an idiot

PleasureKevin posted:

like from a business perspective why is everyone actually going to adopt it. mantle existed and was pushed by a real company and went no where.

Mr Dog posted:

With due respect to Suspicious Dish I'm not sure that nVidia can't continue nVidia'ing even with Vulkan.

Nothing stops them from detecting particular AAA games and swapping out their shaders just like they already do for DX<12 and GL, for instance.

quote:

Those of you who have seen the Vulkan API (and there are plenty of details on the open web, even if the specs are currently behind NDA), you know that there isn’t any equivalent to glClear or similar. The designs of Vulkan are that you control a modern GPU from start to finish. You control all of these steps, you control what gets scheduled and when.

zen death robot posted:

lol

PleasureKevin posted:

also MS and Oculus partnered so VR requires DX 12 or some poo poo

Amethyst posted:

you're an idiot

The_Franz posted:

PleasureKevin posted:

they cancelled mac and Linux support and a few weeks later said

“The Rift will natively work with Windows 10. And we all know that VR experiences require the highest performance, and with Direct X 12, we believe we’ll be able to create state of the art virtual reality experiences on top of Windows.”

no idea if they'll just build direct x tools or what that means

PleasureKevin posted:

they cancelled mac and Linux support and a few weeks later said

“The Rift will natively work with Windows 10. And we all know that VR experiences require the highest performance, and with Direct X 12, we believe we’ll be able to create state of the art virtual reality experiences on top of Windows.”

no idea if they'll just build direct x tools or what that means

Mr Dog posted:

lol thanks for the kickstarter money dumbasses XD

PleasureKevin posted:

they cancelled mac and Linux support and a few weeks later said

“The Rift will natively work with Windows 10. And we all know that VR experiences require the highest performance, and with Direct X 12, we believe we’ll be able to create state of the art virtual reality experiences on top of Windows.”

no idea if they'll just build direct x tools or what that means

Cybernetic Vermin posted:

half life 3 will surely usher in the era of vulcan

quote:

Skip to content
This repository
Search
Pull requests
Issues
Gist
@techjanitor
Watch 87
Star 470
Fork 38 KhronosGroup/Vulkan-Docs
Code Issues 49 Pull requests 8 Wiki Pulse Graphs
Browse files
Change log for February 25, 2015 Vulkan 1.0.4 spec update:
* Bump API patch number from 3 to 4 for the first public update to the
spec. Add patch number to the spec title (this will be done
automatically from XML, later).
* Fixes for numerous editorial issues. Regularize descriptions of
variable-length array queries. Properly tag enumerants so they come
out in the right font (many were mislabeled in usage tags in vk.xml,
or not tagged). Spelling and markup corrections (public issue 4).
* Fix typos and clearly separate description of different types of
memory areas (public issue 5).
* Use standards-compliant preprocessor guard symbols on headers
(public issue 7).
* Note that Github users can't currently set labels on issues, and
recommend a fallback approach (public issue 15).
* Use latexmath prefix on len= attributes (public issue 29).
* Make flink:vkCmdUpdateBuffer pname:dataSize limit consistent (public
issue 65).
* Add VK_KHR_mirror_clamp_to_edge extension to core API branch, as an
optional feature not introducing new commands or enums (internal
issue 104).
* Cleanup invariance language inherited from the GL specification to
not refer to nonexistent (GL-specific) state (internal issue 111).
* Modify the flink:vkCmdDrawIndexed pname:vertexOffset definition to
not be the "base offset within the index buffer" but rather the
"value added to the vertex index before indexing into the vertex
buffer" (internal issue 118).
* Fix drawing chapter in the "Programmable Primitive Shading" section
where it described categories of drawing commands. It referenced
flink:vkCmdDrawIndexed twice. Replace the second reference with
flink:vkCmdDrawIndexedIndirect (internal issue 119).
* Typo fixed in <<sparsememory-examples-advanced,Advanced Sparse
Resources>> sparse memory example (internal issue 122).
* Add flink:VkDisplayPlaneAlphaFlagsKHR to <require> section of
VK_KHR_display extension (internal issue 125)
* Add missing optional="false,true" to
flink:vkGetImageSparseMemoryRequirements
pname:pSparseMemoryRequirementCount parameter (internal issue 132)
* Rename ename:VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT to
ename:VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT
(internal issue 133)
* Fix a handful of broken cross-references in the
<<samplers,Samplers>> chapter (internal issue 134).
* Fix "Input Attachement" GLSL example to use correct syntax (internal
issue 135).
* Update XML schema and documentation to accomodate recently added
attributes for validity. Add some introductory material describing
design choices and pointing to the public repository to file issues.
* Put include of validity in the core spec extensions chapter on its
own line, so that asciidoc is happy.
* Fix vertexOffset language to specify that it's the value added to
the vertex index before indexing into the vertex buffer, not the
base offset within the index buffer.
* Fix error in the description of flink:vkCmdNextSubpass.
1.0
1 parent 8555ed8 commit 5a4c5e5925c65c6e6677c1fb21571684b4b0a77b Jon Leech committed 2 days ago
Unified Split
Showing 52 changed files with 514 additions and 356 deletions.
View 2 doc/specs/vulkan/Makefile
@@ -126,7 +126,7 @@ INCLUDES := $(wildcard protos/*.txt structs/*.txt flags/*.txt enums/*.txt funcpo
COMMONDOCS := $(CHAPTERS) $(INCLUDES)
# A generate included file with the spec version, date, and git commit
SPECVERSION = specversion.txt
-SPECREVISION = 1.0
+SPECREVISION = 1.0.4
SPECREMARK =

# Spec targets
View 59 doc/specs/vulkan/appendices/VK_KHR_sampler_mirror_clamp_to_edge.txt
@@ -0,0 +1,59 @@
+== VK_KHR_sampler_mirror_clamp_to_edge
+
+*Name String*:: VK_KHR_sampler_mirror_clamp_to_edge
+*Extension Type*:: Device extension
+*Registered Extension Number*:: 15
+*Status*:: Final
+*Last Modified Date*:: 16/02/2016
+*Revision*:: 1
+*Dependencies*::
+ - This extension is written against version 1.0. of the {apiname} API.
+*Contributors*::
+ - Tobias Hector, Imagination Technologies
+*Contacts*::
+ - Tobias Hector (tobias.hector@imgtec.com)
+
+VK_KHR_sampler_mirror_clamp_to_edge extends the set of sampler address modes to
+include an additional mode (ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE)
+that effectively uses a texture map twice as large as the original image in
+which the additional half of the new image is a mirror image of the original
+image.
+
+This new mode relaxes the need to generate images whose opposite edges
+match by using the original image to generate a matching "mirror image".
+This mode allows the texture to be mirrored only once in the negative
+s, t, and r directions.
+
+=== New Enum Constants
+
+ * Extending ename:VkSamplerAddressMode:
+ ** ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE
+
+=== Example
+
+Creating a sampler with the new address mode in each dimension
+
+
+[source,{basebackend@docbook:C++:cpp}]
+----------------------------------------
+ VkSamplerCreateInfo createInfo =
+ {
+ VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO // sType
+ // Other members set to application-desired values
+ };
+
+ createInfo.addressModeU = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
+ createInfo.addressModeV = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
+ createInfo.addressModeW = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
+
+ VkSampler sampler;
+ VkResult result = vkCreateSampler(
+ device,
+ &createInfo,
+ &sampler);
+----------------------------------------
+
+=== Version History
+
+ * Revision 1, 2016-02-16 (Tobias Hector)
+ - Initial draft
View 2 doc/specs/vulkan/appendices/invariance.txt
@@ -76,7 +76,7 @@ use of any other state value is not affected by the change):_
* _Pixel storage state_

*Corollary 1* _Fragment generation is invariant with respect to the state
-values marked with * in Rule 2._
+values listed in Rule 2._

*Rule 3* _The arithmetic of each per-fragment operation is invariant except
with respect to parameters that directly control it._
View 4 doc/specs/vulkan/chapters/cmdbuffers.txt
@@ -203,13 +203,15 @@ include::../protos/vkResetCommandBuffer.txt[]
can: be in any state, and is put in the initial state.
* pname:flags is of type elink:VkCommandBufferResetFlags:
+
+--
include::../enums/VkCommandBufferResetFlagBits.txt[]
-+
+
If pname:flags includes ename:VK_COMMAND_BUFFER_RESET_RELEASE_RESOURCES_BIT,
then most or all memory resources currently owned by the command buffer
should: be returned to the parent command pool. If this flag is not set,
then the command buffer may: hold onto memory resources and reuse them when
recording commands.
+--

include::../validity/protos/vkResetCommandBuffer.txt[]

View 2 doc/specs/vulkan/chapters/descriptorsets.txt
@@ -503,7 +503,7 @@ attachment index in addition to descriptor set and binding numbers.
.GLSL example
[source,{basebackend@docbookglsl}]
---------------------------------------------------
-layout (input_attachment_index=i, set=m, binding=n) uniform subpass myInputAttachment;
+layout (input_attachment_index=i, set=m, binding=n) uniform subpassInput myInputAttachment;
---------------------------------------------------

.SPIR-V example
View 23 doc/specs/vulkan/chapters/devsandqueues.txt
@@ -23,13 +23,20 @@ include::../protos/vkEnumeratePhysicalDevices.txt[]

* pname:instance is a handle to a {apiname} instance previously created
with fname:vkCreateInstance.
- * If pname:pPhysicalDevices is `NULL`, the number of physical devices
- available is returned in pname:pPhysicalDeviceCount. If
- pname:pPhysicalDevices is not `NULL`,
- * pname:pPhysicalDeviceCount must: point to a variable set by the user to
- the size of the array pointed to by pname:pPhysicalDevices, and is
- overwritten with the number of physical devices actually written to
- pname:pPhysicalDevices.
+ * pname:pPhysicalDeviceCount is a pointer to an integer related to the
+ number of physical devices available or queried, as described below.
+ * pname:pPhysicalDevices is either `NULL` or a pointer to an
+ array of sname:VkPhysicalDevice structures.
+
+If pname:pPhysicalDevices is `NULL`, then the number of physical devices
+available is returned in pname:pPhysicalDeviceCount. Otherwise,
+pname:pPhysicalDeviceCount must: point to a variable set by the user to
+the number of elements in the pname:pPhysicalDevices array, and on
+return the variable is overwritten with the number of structures actually
+written to pname:pPhysicalDevices. If the value of
+pname:pPhysicalDeviceCount is less than the number of physical devices
+available, at most pname:pPhysicalDeviceCount structures will be
+written.

include::../validity/protos/vkEnumeratePhysicalDevices.txt[]

@@ -142,7 +149,7 @@ include::../protos/vkGetPhysicalDeviceQueueFamilyProperties.txt[]
* pname:pQueueFamilyPropertyCount is a pointer to an integer related to
the number of queue families available or queried, as described below.
* pname:pQueueFamilyProperties is either `NULL` or a pointer to an array
- of sname:VkQueueFamilyProperties structures.
+ of slink:VkQueueFamilyProperties structures.

If pname:pQueueFamilyProperties is `NULL`, then the number of queue families
available is returned in pname:pQueueFamilyPropertyCount. Otherwise,
View 3 doc/specs/vulkan/chapters/drawing.txt
@@ -427,7 +427,8 @@ include::../protos/vkCmdDrawIndexed.txt[]
* pname:indexCount is the number of vertices to draw.
* pname:instanceCount is the number of instances to draw.
* pname:firstIndex is the base index within the index buffer.
- * pname:vertexOffset is the base offset within the index buffer.
+ * pname:vertexOffset is the value added to the vertex index before indexing
+ into the vertex buffer.
* pname:firstInstance is the instance ID of the first instance to draw.

When the command is executed, primitives are assembled using the current
View 93 doc/specs/vulkan/chapters/extensions.txt
@@ -36,11 +36,10 @@ To query the available instance layers, call:

include::../protos/vkEnumerateInstanceLayerProperties.txt[]

- * pname:pPropertyCount is the number of layer properties that can be
- returned in pname:pProperties.
- * pname:pProperties is an array of slink:VkLayerProperties structures in
- which properties of instance layers available on this implementation are
- returned.
+ * pname:pPropertyCount is a pointer to an integer related to the number of
+ layer properties available or queried, as described below.
+ * pname:pProperties is either `NULL` or a pointer to an array of
+ slink:VkLayerProperties structures.

include::../validity/protos/vkEnumerateInstanceLayerProperties.txt[]

@@ -53,11 +52,10 @@ To query the layers available to a given physical device, call:
include::../protos/vkEnumerateDeviceLayerProperties.txt[]

* pname:physicalDevice is the physical device that will be queried.
- * pname:pPropertyCount is the number of layer properties that can be
- returned in pname:pProperties.
- * pname:pProperties is an array of slink:VkLayerProperties structures in
- which properties of layers available on pname:physicalDevice are
- returned.
+ * pname:pPropertyCount is a pointer to an integer related to the number of
+ layer properties available or queried, as described below.
+ * pname:pProperties is either `NULL` or a pointer to an array of
+ slink:VkLayerProperties structures.

include::../validity/protos/vkEnumerateDeviceLayerProperties.txt[]

@@ -65,17 +63,18 @@ To enable a device layer, the name of the layer should be added to the
pname:ppEnabledLayerNames member of slink:VkDeviceCreateInfo when creating
a slink:VkDevice.

-Both commands will return an array of sname:VkLayerProperties of the
-respective instance or device layers present. Calling
-fname:vkEnumerateInstanceLayerProperties or
-fname:vkEnumerateDeviceLayerProperties with pname:pProperties set to `NULL`
-will return the number of supported layers in the basetype:uint32_t variable
-pointed to by pname:pPropertyCount. If pname:pProperties is not set to
-`NULL`, the query will fill the array and update pname:pPropertyCount to
-indicate the number of sname:VkLayerProperties filled in. If
-pname:pPropertyCount is smaller than the number of layers available,
-ename:VK_INCOMPLETE will be returned instead of ename:VK_SUCCESS, to
-indicate that not all the available properties were returned.
+For both flink:vkEnumerateInstanceLayerProperties and
+flink:vkEnumerateDeviceLayerProperties, if pname:pProperties is `NULL`, then
+the number of layer properties available is returned in pname:pPropertyCount.
+Otherwise, pname:pPropertyCount must: point to a variable set by the user to
+the number of elements in the pname:pProperties array, and on return the
+variable is overwritten with the number of structures actually written to
+pname:pProperties. If the value of pname:pPropertyCount is less than the
+number of layer properties available, at most pname:pPropertyCount
+structures will be written. If pname:pPropertyCount is smaller than the
+number of layers available, ename:VK_INCOMPLETE will be returned instead of
+ename:VK_SUCCESS, to indicate that not all the available properties were
+returned.

The definition of sname:VkLayerProperties is:

@@ -123,14 +122,14 @@ include::../protos/vkEnumerateInstanceExtensionProperties.txt[]

* pname:pLayerName is either `NULL` or the name of a instance layer to
retrieve extensions from.
- * pname:pPropertyCount is the number of extension properties that can be
- returned in pname:pProperties.
- * pname:pProperties is an array of slink:VkExtensionProperties structures
- in which properties of instance extensions available on this
- implementation are returned.
-
-include::../validity/protos/vkEnumerateInstanceExtensionProperties.txt[] Any
-instance extensions provided by the {apiname} implementation or by
+ * pname:pPropertyCount is a pointer to an integer related to the number of
+ extension properties available or queried, as described below.
+ * pname:pProperties is either `NULL` or a pointer to an array of
+ slink:VkExtensionProperties structures.
+
+include::../validity/protos/vkEnumerateInstanceExtensionProperties.txt[]
+
+Any instance extensions provided by the {apiname} implementation or by
implicitly enabled layers, but not by explicitly enabled layers, are
returned when pname:pLayerName parameter is `NULL`. When pname:pLayerName is
the name of a layer, the instance extensions provided by that layer are
@@ -147,11 +146,10 @@ include::../protos/vkEnumerateDeviceExtensionProperties.txt[]
* pname:physicalDevice is the physical device that will be queried.
* pname:pLayerName is either `NULL` or the name of a device layer to
retrieve extensions from.
- * pname:pPropertyCount is the number of extension properties that can be
- returned in pname:pProperties.
- * pname:pProperties is an array of slink:VkExtensionProperties structures
- in which properties of extensions available on pname:physicalDevice are
- returned.
+ * pname:pPropertyCount is a pointer to an integer related to the number of
+ extension properties available or queried, as described below.
+ * pname:pProperties is either `NULL` or a pointer to an array of
+ slink:VkExtensionProperties structures.

include::../validity/protos/vkEnumerateDeviceExtensionProperties.txt[]

@@ -165,21 +163,18 @@ To enable a device layer, the name of the layer should be added to the
pname:ppEnabledExtensionNames member of slink:VkDeviceCreateInfo when
creating a slink:VkDevice.

-Both commands return an array of sname:VkExtensionProperties
-for any extensions implemented by the given pname:pLayerName.
-Set pname:pLayerName to `NULL` to query for extensions not part of any
-layer. Calling fname:vkEnumerateInstanceExtensionProperties or
-fname:vkEnumerateDeviceExtensionProperties with pname:pProperties set to
-`NULL` will return the count of extensions for the given layer in the
-basetype:uint32_t variable pointed to by pname:pPropertyCount. With
-pname:pProperties pointing to an array of sname:VkExtensionProperties,
-fname:vkEnumerateInstanceExtensionProperties
-and fname:vkEnumerateDeviceExtensionProperties will fill the array and
-update the count to indicate the number of sname:VkExtensionProperties
-filled in. If the provided count is smaller than the number of extensions
-available, ename:VK_INCOMPLETE will be returned
-instead of ename:VK_SUCCESS to indicate that not all the
-available properties were returned.
+For both flink:vkEnumerateInstanceExtensionProperties and
+flink:vkEnumerateDeviceExtensionProperties, if pname:pProperties is `NULL`,
+then the number of extensions properties available is returned in
+pname:pPropertyCount. Otherwise, pname:pPropertyCount must: point to a
+variable set by the user to the number of elements in the pname:pProperties
+array, and on return the variable is overwritten with the number of
+structures actually written to pname:pProperties. If the value of
+pname:pPropertyCount is less than the number of extension properties
+available, at most pname:pPropertyCount structures will be written. If
+pname:pPropertyCount is smaller than the number of extensions available,
+ename:VK_INCOMPLETE will be returned instead of ename:VK_SUCCESS, to
+indicate that not all the available properties were returned.

The definition of sname:VkExtensionProperties is:

View 2 doc/specs/vulkan/chapters/features.txt
@@ -979,7 +979,7 @@ different equations in the spec).
subpixel precision that floating-point viewport bounds are interpreted
at is given by this limit.
* [[features-limits-minMemoryMapAlignment]] pname:minMemoryMapAlignment is
- the minimum required alignment, in bytes, of host-visible memory
+ the minimum required alignment, in bytes, of host visible memory
allocations within the host address space. When mapping a memory
allocation with flink:vkMapMemory, subtracting pname:offset bytes from
the returned pointer will always produce an integer multiple of this
View 39 doc/specs/vulkan/chapters/fundamentals.txt
@@ -42,12 +42,16 @@ advertise one or more heaps, representing different areas of memory. Memory
heaps are either device local or host local, but are always visible to the
device. Further detail about memory heaps is exposed via memory types
available on that heap. Examples of memory areas that may: be available on
-an implementation include _device local_ (memory that is physically
-connected to the device), _device local, host visible_ (device local memory
-that is visible to the host) and _host local, host visible_ (memory that is
-local to the host and visible to the device and host). On other
-architectures, there may: only be a single heap that can: be used for any
-purpose.
+an implementation include:
+
+ * _device local_ is memory that is physically connected to the device.
+ * _device local, host visible_ is device local memory that is visible to
+ the host.
+ * _host local, host visible_ is memory that is local to the host and
+ visible to the device and host.
+
+On other architectures, there may: only be a single heap that can: be used
+for any purpose.

A {apiname} application controls a set of devices through the submission of
command buffers which have recorded device commands issued via {apiname}
@@ -73,8 +77,9 @@ the responsibility of the application.
{apiname} queues provide an interface to the execution engines of a device.
Commands are recorded into command buffers ahead of execution time.
These command buffers are then submitted to queues for execution. Command
-buffers submitted to a single queue play back the commands in the order
-they were recorded, both within and across command buffer boundaries.
+buffers submitted to a single queue are played back in the order they were
+submitted, and commands within each buffer are played back in the order they
+were recorded.
Work performed by those commands respects the ordering guarantees provided
by explicit and implicit dependencies, as described below. Work submitted
to separate queues may: execute in any relative order unless otherwise
@@ -206,7 +211,7 @@ There are two classes of handles, dispatchable and non-dispatchable.
_Dispatchable_ handle types are a pointer to an opaque type. This pointer
may: be used by layers as part of intercepting API commands, and thus each
API command takes a dispatchable type as its first parameter. Each object of
-a dispatchable type has a unique handle value.
+a dispatchable type must: have a unique handle value during its lifetime.

_Non-dispatchable_ handle types are a 64-bit integer type whose meaning is
implementation-dependent, and may: encode object information directly in the
@@ -301,7 +306,7 @@ reset, then it can: be used as if it never used the freed object. An
exception to this is when there is a parent/child relationship between
objects. In this case, the application mustnot: destroy a parent object
before its children, except when the parent is explicitly defined to free
-its children when it is destroyed (i.e. for pool objects, as defined below).
+its children when it is destroyed (e.g. for pool objects, as defined below).

sname:VkCommandPool objects are parents of sname:VkCommandBuffer objects.
sname:VkDescriptorPool objects are parents of sname:VkDescriptorSet objects.
@@ -520,19 +525,19 @@ by the command, and all fundamental types accessed through the pointer (e.g.
as elements of an array or as members of a structure) satisfy the alignment
requirements of the host processor.

-Any parameter that is an enumerant must: be a valid value for that enumerant
-type. A value is valid for an enumerant if:
+Any parameter of an enumerated type must: be a valid enumerant for that
+type. A enumerant is valid if:

- * The value is defined as part of the enumerant type.
- * The value is not one of the special values defined for an enumerant
- type, which are suffixed with etext:_BEGIN_RANGE, etext:_END_RANGE,
- etext:_RANGE_SIZE or etext:_MAX_ENUM.
+ * The enumerant is defined as part of the enumerated type.
+ * The enumerant is not one of the special values defined for the
+ enumerated type, which are suffixed with etext:_BEGIN_RANGE,
+ etext:_END_RANGE, etext:_RANGE_SIZE or etext:_MAX_ENUM.

Any parameter that is a flag value must: be a valid combination of bit
flags. A valid combination is either zero or the bitwise OR of valid bit
flags. A bit flag is valid if:

- * The value is defined as part of the bits type, where the bits type is
+ * The flag is defined as part of the bits type, where the bits type is
obtained by taking the flag type and replacing the trailing etext:Flags
with etext:FlagBits. For example, a flag value of type
elink:VkColorComponentFlags must: contain only values selected from the
View 5 doc/specs/vulkan/chapters/introduction.txt
@@ -94,7 +94,10 @@ http://github.com/KhronosGroup/Vulkan-Docs

Please tag issues with appropriate labels, such as ``Specification'',
``Ref Pages'' or ``Registry'', to help us triage and assign them
-appropriately.
+appropriately. Unfortunately, Github does not currently let users who do not
+have write access to the repository set Github labels on issues. In the
+meantime, they can be added to the title line of the issue set in brackets,
+e.g. ''[Specification]''.


[[introduction-terminology]]
View 2 doc/specs/vulkan/chapters/renderpass.txt
@@ -817,7 +817,7 @@ include::../protos/vkCmdNextSubpass.txt[]

* pname:commandBuffer is the command buffer in which to record the
command.
- * pname:contents specifies how the commands in the first subpass will be
+ * pname:contents specifies how the commands in the next subpass will be
provided, in the same fashion as the corresponding parameter of
flink:vkCmdBeginRenderPass.

View 15 doc/specs/vulkan/chapters/samplers.txt
@@ -42,7 +42,7 @@ include::../enums/VkFilter.txt[]
* pname:minFilter is the minification filter to apply to lookups, and is
of type elink:VkFilter.
* pname:mipmapMode is the mipmap filter to apply to lookups as described
- in the <<texture-texel-filtering, Texel Filtering>> section, and is of
+ in the <<textures-texel-filtering, Texel Filtering>> section, and is of
type:
+
--
@@ -61,7 +61,7 @@ include::../enums/VkSamplerMipmapMode.txt[]
Level-of-Detail Operation>> section.
* [[samplers-maxAnisotropy]] pname:anisotropyEnable is ename:VK_TRUE to
enable anisotropic filtering, as described in the
- <<texture-anisotropic-texel-selection, Anisotropic Texel Selection>>
+ <<textures-texel-anisotropic-filtering, Texel Anisotropic Filtering>>
section, or ename:VK_FALSE otherwise.
* pname:maxAnisotropy is the anisotropy value clamp.
* pname:compareEnable is ename:VK_TRUE to enable comparison against a
@@ -69,14 +69,14 @@ include::../enums/VkSamplerMipmapMode.txt[]
** Note: Some implementations will default to shader state if this member
does not match.
* pname:compareOp is the comparison function to apply to fetched data
- before filtering as described in the <<texture-depth-compare-operation,
+ before filtering as described in the <<textures-depth-compare-operation,
Depth Compare Operation>> section. See elink:VkCompareOp.
* pname:minLod and pname:maxLod are the values used to clamp the computed
level-of-detail value, as described in the
<<textures-level-of-detail-operation, Level-of-Detail Operation>>
section. pname:maxLod must: be greater than or equal to pname:minLod.
* pname:borderColor is the predefined border color to use, as described
- in the <<texture-texel-replacement, Texel Replacement>>
+ in the <<textures-texel-replacement, Texel Replacement>>
section, and is of type:
+
--
@@ -146,7 +146,7 @@ include::../enums/VkSamplerAddressMode.txt[]

These values control the behavior of sampling with coordinates outside the
range [0,1] for the respective u, v, or w coordinate as defined in the
-<<texture-wrapping-operation, Wrapping Operation>> section.
+<<textures-wrapping-operation, Wrapping Operation>> section.

* ename:VK_SAMPLER_ADDRESS_MODE_REPEAT indicates that the repeat wrap mode
will be used.
@@ -156,8 +156,9 @@ range [0,1] for the respective u, v, or w coordinate as defined in the
edge wrap mode will be used.
* ename:VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER indicates that the clamp
to border wrap mode will be used.
- * ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE indicates that the
- mirror clamp to edge wrap mode will be used.
+ * ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE indicates that
+ the mirror clamp to edge wrap mode will be used. This is only valid
+ if the VK_KHR_mirror_clamp_to_edge extension is enabled.

The maximum number of sampler objects which can: be simultaneously created
on a device is implementation-dependent and specified by the
View 77 doc/specs/vulkan/chapters/sparsemem.txt
@@ -751,25 +751,24 @@ include::../protos/vkGetPhysicalDeviceSparseImageFormatProperties.txt[]
elink:VkSampleCountFlagBits.
* pname:usage is a bitfield describing the intended usage of the image.
* pname:tiling is the tiling arrangement of the data elements in memory.
- * pname:pPropertyCount points to a variable specifying the length of the
- pname:pProperties array, or a variable receiving the expected size of
- the array if pname:pProperties is `NULL`.
- * pname:pProperties is an array of pname:pPropertyCount
- slink:VkSparseImageFormatProperties format property structures in which
- values are returned.
+ * pname:pPropertyCount is a pointer to an integer related to the number of
+ sparse format properties available or queried, as described below.
+ * pname:pProperties is either `NULL` or a pointer to an array of
+ slink:VkSparseImageFormatProperties structures.
+
+If pname:pProperties is `NULL`, then the number of sparse format properties
+available is returned in pname:pPropertyCount. Otherwise,
+pname:pPropertyCount must: point to a variable set by the user to the number
+of elements in the pname:pProperties array, and on return the variable is
+overwritten with the number of structures actually written to
+pname:pProperties. If the value of pname:pPropertyCount is less than the
+number of sparse format properties available, at most pname:pPropertyCount
+structures will be written, and ename:VK_INCOMPLETE will be returned instead
+of ename:VK_SUCCESS to indicate that not all the available values were
+returned.

include::../validity/protos/vkGetPhysicalDeviceSparseImageFormatProperties.txt[]

-If pname:pProperties is `NULL`, then pname:pPropertyCount will be updated
-with the required size of the array pointed by pname:pProperties. If
-pname:pProperties is not `NULL`, then pname:pPropertyCount must: hold the
-size of the array pointed to by pname:pProperties, and is overwritten with
-the number of sname:VkSparseImageFormatProperties structures actually
-written to pname:pProperties. If pname:pPropertyCount is smaller than the
-number of sparse image properties for the given set of parameters,
-ename:VK_INCOMPLETE will be returned instead of ename:VK_SUCCESS to indicate
-that not all the available values were returned.
-
If ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT is not supported for the given
arguments, pname:pPropertyCount will be set to zero upon return, and no data
will be written to pname:pProperties.
@@ -892,33 +891,31 @@ include::../protos/vkGetImageSparseMemoryRequirements.txt[]
* pname:device is the logical device that owns the image.
* pname:image is the sname:VkImage object to get the memory requirements
for.
- * pname:pSparseMemoryRequirementCount points to a variable specifying the
- length of the pname:pSparseMemoryRequirements array, or a variable
- receiving the expected size of the array if
- pname:pSparseMemoryRequirements is `NULL`.
- * pname:pSparseMemoryRequirements is an array of
- pname:pSparseMemoryRequirementCount
- slink:VkSparseImageMemoryRequirements structures to be written by the
- API.
-
-include::../validity/protos/vkGetImageSparseMemoryRequirements.txt[]
-
-If pname:pSparseMemoryRequirements is `NULL`, then
-pname:pSparseMemoryRequirementCount will be updated with the required size
-of the array pointed by pname:pProperties. If
-pname:pSparseMemoryRequirements is not `NULL`, then
-pname:pSparseMemoryRequirementCount must: hold the size of the array pointed
-to by pname:pSparseMemoryRequirements, and is overwritten with the number of
-sname:VkSparseImageMemoryRequirements structures actually written to
-pname:pSparseMemoryRequirements. If pname:pSparseMemoryRequirementCount is
-smaller than the number of sparse memory requirements for the given set of
-parameters, ename:VK_INCOMPLETE will be returned instead of ename:VK_SUCCESS
-to indicate that not all the available values were returned.
+ * pname:pSparseMemoryRequirementCount is a pointer to an integer related
+ to the number of sparse memory requirements available or queried, as
+ described below.
+ * pname:pSparseMemoryRequirements is either `NULL` or a pointer to an
+ array of sname:VkSparseImageMemoryRequirements structures.
+
+If pname:pSparseMemoryRequirements is `NULL`, then the number of sparse
+memory requirements available is returned in
+pname:pSparseMemoryRequirementCount. Otherwise,
+pname:pSparseMemoryRequirementCount must: point to a variable set by the
+user to the number of elements in the pname:pSparseMemoryRequirements array,
+and on return the variable is overwritten with the number of structures
+actually written to pname:pSparseMemoryRequirements. If the value of
+pname:pSparseMemoryRequirementCount is less than the number of sparse memory
+requirements available, at most pname:pSparseMemoryRequirementCount
+structures will be written, and ename:VK_INCOMPLETE will be returned instead
+of ename:VK_SUCCESS to indicate that not all the available values were
+returned.

If the image was not created with ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT
then pname:pSparseMemoryRequirementCount will be set to zero and
pname:pSparseMemoryRequirements will not be written to.

+include::../validity/protos/vkGetImageSparseMemoryRequirements.txt[]
+
[NOTE]
.Note
====
@@ -1375,7 +1372,7 @@ vkGetImageSparseMemoryRequirements(
NULL);

pSparseReqs = (VkSparseImageMemoryRequirements*)
- malloc(reqCount * sizeof(VkSparseImageMemoryRequirements));
+ malloc(sparseRequirementsCount * sizeof(VkSparseImageMemoryRequirements));

vkGetImageSparseMemoryRequirements(
device,
@@ -1467,6 +1464,8 @@ for (uint32_t i = 0; i < sparseRequirementsCount; ++i)
pBind->flags = 0;
}
}
+
+ free(pSparseReqs);
}

const VkSparseImageOpaqueMemoryBindInfo opaqueBindInfo =
View 2 doc/specs/vulkan/chapters/synchronization.txt
@@ -1226,7 +1226,7 @@ are <<synchronization-fences-devicewrites,visible to the host>>.
When submitting batches of command buffers to a queue via
flink:vkQueueSubmit, it is guaranteed that:

- * Host writes to mappable device memory that occured before the call to
+ * Host writes to mappable device memory that occurred before the call to
fname:vkQueueSubmit are visible to the command buffers in that
submission, if the device memory is coherent or if the memory range was
flushed with flink:vkFlushMappedMemoryRanges.
View 2 doc/specs/vulkan/chapters/vertexpostproc.txt
@@ -236,7 +236,7 @@ rasterized (see <<primsrast-lines-basic,Basic Line Segment Rasterization>>
and <<primsrast-polygons-basic,Basic Polygon Rasterization>>), and no
interpolation is performed. The output value latexmath:[${\textbf c}$] is
taken from either latexmath:[${\textbf c}_1$] or latexmath:[${\textbf
-c}_2$], since flatshading has already occured and the two values are
+c}_2$], since flatshading has already occurred and the two values are
identical.


View 8 doc/specs/vulkan/validity/protos/vkCmdBlitImage.txt
@@ -23,13 +23,13 @@ endif::doctype-manpage[]
* The destination region specified by a given element of pname:pRegions must: be a region that is contained within pname:dstImage
* The union of all source regions, and the union of all destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory
* pname:srcImage must: use a format that supports ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT, which is indicated by sname:VkFormatProperties::pname:linearTilingFeatures (for linear tiled images) or sname:VkFormatProperties::pname:optimalTilingFeatures (for optimally tiled images) - as returned by fname:vkGetPhysicalDeviceFormatProperties
-* pname:srcImage must: have been created with pname:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag
+* pname:srcImage must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag
* pname:srcImageLayout must: specify the layout of the subresources of pname:srcImage specified in pname:pRegions at the time this command is executed on a sname:VkDevice
-* pname:srcImageLayout must: be either of VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL
+* pname:srcImageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
* pname:dstImage must: use a format that supports ename:VK_FORMAT_FEATURE_BLIT_DST_BIT, which is indicated by sname:VkFormatProperties::pname:linearTilingFeatures (for linear tiled images) or sname:VkFormatProperties::pname:optimalTilingFeatures (for optimally tiled images) - as returned by fname:vkGetPhysicalDeviceFormatProperties
-* pname:dstImage must: have been created with pname:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
+* pname:dstImage must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* pname:dstImageLayout must: specify the layout of the subresources of pname:dstImage specified in pname:pRegions at the time this command is executed on a sname:VkDevice
-* pname:dstImageLayout must: be either of VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL
+* pname:dstImageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
* The sample count of pname:srcImage and pname:dstImage must: both be equal to ename:VK_SAMPLE_COUNT_1_BIT
* If either of pname:srcImage or pname:dstImage was created with a signed integer elink:VkFormat, the other must: also have been created with a signed integer elink:VkFormat
* If either of pname:srcImage or pname:dstImage was created with an unsigned integer elink:VkFormat, the other must: also have been created with an unsigned integer elink:VkFormat
View 4 doc/specs/vulkan/validity/protos/vkCmdClearColorImage.txt
@@ -17,9 +17,9 @@ endif::doctype-manpage[]
* This command must: only be called outside of a render pass instance
* The value of pname:rangeCount must: be greater than `0`
* Each of pname:commandBuffer and pname:image must: have been created, allocated or retrieved from the same sname:VkDevice
-* pname:image must: have been created with pname:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
+* pname:image must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* pname:imageLayout must: specify the layout of the subresource ranges of pname:image specified in pname:pRanges at the time this command is executed on a sname:VkDevice
-* pname:imageLayout must: be either of VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL
+* pname:imageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
* The image range of any given element of pname:pRanges must: be a subresource range that is contained within pname:image
ifndef::doctype-manpage[]
********************************************************************************
View 4 doc/specs/vulkan/validity/protos/vkCmdClearDepthStencilImage.txt
@@ -17,9 +17,9 @@ endif::doctype-manpage[]
* This command must: only be called outside of a render pass instance
* The value of pname:rangeCount must: be greater than `0`
* Each of pname:commandBuffer and pname:image must: have been created, allocated or retrieved from the same sname:VkDevice
-* pname:image must: have been created with pname:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
+* pname:image must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* pname:imageLayout must: specify the layout of the subresource ranges of pname:image specified in pname:pRanges at the time this command is executed on a sname:VkDevice
-* pname:imageLayout must: be either of VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL
+* pname:imageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
* The image range of any given element of pname:pRanges must: be a subresource range that is contained within pname:image
ifndef::doctype-manpage[]
********************************************************************************
View 4 doc/specs/vulkan/validity/protos/vkCmdCopyBuffer.txt
@@ -19,8 +19,8 @@ endif::doctype-manpage[]
* The sum of the pname:srcOffset and pname:copySize members of a given element of pname:pRegions must: be less than or equal to the size of pname:srcBuffer
* The sum of the pname:dstOffset and pname:copySize members of a given element of pname:pRegions must: be less than or equal to the size of pname:dstBuffer
* The union of the source regions, and the union of the destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory
-* pname:srcBuffer must: have been created with pname:VK_BUFFER_USAGE_TRANSFER_SRC_BIT usage flag
-* pname:dstBuffer must: have been created with pname:VK_BUFFER_USAGE_TRANSFER_DST_BIT usage flag
+* pname:srcBuffer must: have been created with ename:VK_BUFFER_USAGE_TRANSFER_SRC_BIT usage flag
+* pname:dstBuffer must: have been created with ename:VK_BUFFER_USAGE_TRANSFER_DST_BIT usage flag
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]
View 6 doc/specs/vulkan/validity/protos/vkCmdCopyBufferToImage.txt
@@ -20,11 +20,11 @@ endif::doctype-manpage[]
* The buffer region specified by a given element of pname:pRegions must: be a region that is contained within pname:srcBuffer
* The image region specified by a given element of pname:pRegions must: be a region that is contained within pname:dstImage
* The union of all source regions, and the union of all destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory
-* pname:srcBuffer must: have been created with pname:VK_BUFFER_USAGE_TRANSFER_SRC_BIT usage flag
-* pname:dstImage must: have been created with pname:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
+* pname:srcBuffer must: have been created with ename:VK_BUFFER_USAGE_TRANSFER_SRC_BIT usage flag
+* pname:dstImage must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* pname:dstImage must: have a sample count equal to ename:VK_SAMPLE_COUNT_1_BIT
* pname:dstImageLayout must: specify the layout of the subresources of pname:dstImage specified in pname:pRegions at the time this command is executed on a sname:VkDevice
-* pname:dstImageLayout must: be either of VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL
+* pname:dstImageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]
View 8 doc/specs/vulkan/validity/protos/vkCmdCopyImage.txt
@@ -21,12 +21,12 @@ endif::doctype-manpage[]
* The source region specified by a given element of pname:pRegions must: be a region that is contained within pname:srcImage
* The destination region specified by a given element of pname:pRegions must: be a region that is contained within pname:dstImage
* The union of all source regions, and the union of all destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory
-* pname:srcImage must: have been created with pname:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag
+* pname:srcImage must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag
* pname:srcImageLayout must: specify the layout of the subresources of pname:srcImage specified in pname:pRegions at the time this command is executed on a sname:VkDevice
-* pname:srcImageLayout must: be either of VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL
-* pname:dstImage must: have been created with pname:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
+* pname:srcImageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
+* pname:dstImage must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* pname:dstImageLayout must: specify the layout of the subresources of pname:dstImage specified in pname:pRegions at the time this command is executed on a sname:VkDevice
-* pname:dstImageLayout must: be either of VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL
+* pname:dstImageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
* The elink:VkFormat of each of pname:srcImage and pname:dstImage must: be compatible, as defined <<copies-images-format-compatibility, below>>
* The sample count of pname:srcImage and pname:dstImage must: match
ifndef::doctype-manpage[]
View 6 doc/specs/vulkan/validity/protos/vkCmdCopyImageToBuffer.txt
@@ -20,11 +20,11 @@ endif::doctype-manpage[]
* The image region specified by a given element of pname:pRegions must: be a region that is contained within pname:srcImage
* The buffer region specified by a given element of pname:pRegions must: be a region that is contained within pname:dstBuffer
* The union of all source regions, and the union of all destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory
-* pname:srcImage must: have been created with pname:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag
+* pname:srcImage must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag
* pname:srcImage must: have a sample count equal to ename:VK_SAMPLE_COUNT_1_BIT
* pname:srcImageLayout must: specify the layout of the subresources of pname:srcImage specified in pname:pRegions at the time this command is executed on a sname:VkDevice
-* pname:srcImageLayout must: be either of VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL
-* pname:dstBuffer must: have been created with pname:VK_BUFFER_USAGE_TRANSFER_DST_BIT usage flag
+* pname:srcImageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
+* pname:dstBuffer must: have been created with ename:VK_BUFFER_USAGE_TRANSFER_DST_BIT usage flag
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]
View 4 doc/specs/vulkan/validity/protos/vkCmdExecuteCommands.txt
@@ -14,8 +14,8 @@ endif::doctype-manpage[]
* pname:commandBuffer must: be a primary sname:VkCommandBuffer
* The value of pname:commandBufferCount must: be greater than `0`
* Each of pname:commandBuffer and the elements of pname:pCommandBuffers must: have been created, allocated or retrieved from the same sname:VkDevice

pram posted:

epic! for those who have github blocked at work


cant wait for more sweet commits.. fuckin woot

pram posted:

my favorite part was the value added to the vertex index before indexing into the vertex buffer