Vulkan^® 1.3.264 - A Specification (with all registered extensions)

Primitives are discarded before rasterization if the rasterizerDiscardEnable member of VkPipelineRasterizationStateCreateInfo is enabled. When enabled, primitives are discarded after they are processed by the last active shader stage in the pipeline before rasterization.

By default vertex data output from the last pre-rasterization shader stage are directed to vertex stream zero. Geometry shaders can emit primitives to multiple independent vertex streams. Each vertex emitted by the geometry shader is directed at one of the vertex streams. As vertices are received on each vertex stream, they are arranged into primitives of the type specified by the geometry shader output primitive type. The shading language instructions OpEndPrimitive and OpEndStreamPrimitive can be used to end the primitive being assembled on a given vertex stream and start a new empty primitive of the same type. An implementation supports up to VkPhysicalDeviceTransformFeedbackPropertiesEXT::maxTransformFeedbackStreams streams, which is at least 1. The individual streams are numbered 0 through maxTransformFeedbackStreams minus 1. There is no requirement on the order of the streams to which vertices are emitted, and the number of vertices emitted to each vertex stream can be completely independent, subject only to the VkPhysicalDeviceTransformFeedbackPropertiesEXT::maxTransformFeedbackStreamDataSize and VkPhysicalDeviceTransformFeedbackPropertiesEXT::maxTransformFeedbackBufferDataSize limits. The primitives output from all vertex streams are passed to the transform feedback stage to be captured to transform feedback buffers in the manner specified by the last pre-rasterization shader stage shader’s XfbBuffer, XfbStride, and Offsets decorations on the output interface variables in the graphics pipeline. To use a vertex stream other than zero, or to use multiple streams, the GeometryStreams capability must be specified.

By default, the primitives output from vertex stream zero are rasterized. If the implementation supports the VkPhysicalDeviceTransformFeedbackPropertiesEXT::transformFeedbackRasterizationStreamSelect property it is possible to rasterize a vertex stream other than zero.

By default, geometry shaders that emit vertices to multiple vertex streams are limited to using only the OutputPoints output primitive type. If the implementation supports the VkPhysicalDeviceTransformFeedbackPropertiesEXT::transformFeedbackStreamsLinesTriangles property it is possible to emit OutputLineStrip or OutputTriangleStrip in addition to OutputPoints.

Within a subpass of a render pass instance, for a given (x,y,layer,sample) sample location, the following operations are guaranteed to execute in rasterization order, for each separate primitive that includes that sample location:

Execution of these operations for each primitive in a subpass occurs in an order determined by the application.

Multisampling is a mechanism to antialias all Vulkan primitives: points, lines, and polygons. The technique is to sample all primitives multiple times at each pixel. Each sample in each framebuffer attachment has storage for a color, depth, and/or stencil value, such that per-fragment operations apply to each sample independently. The color sample values can be later resolved to a single color (see Resolving Multisample Images and the Render Pass chapter for more details on how to resolve multisample images to non-multisample images).

Vulkan defines rasterization rules for single-sample modes in a way that is equivalent to a multisample mode with a single sample in the center of each fragment.

Each fragment includes a coverage mask with a single bit for each sample in the fragment, and a number of depth values and associated data for each sample.

It is understood that each pixel has rasterizationSamples locations associated with it. These locations are exact positions, rather than regions or areas, and each is referred to as a sample point. The sample points associated with a pixel must be located inside or on the boundary of the unit square that is considered to bound the pixel. Furthermore, the relative locations of sample points may be identical for each pixel in the framebuffer, or they may differ.

If the render pass has a fragment density map attachment, each fragment only has rasterizationSamples locations associated with it regardless of how many pixels are covered in the fragment area. Fragment sample locations are defined as if the fragment had an area of (1,1) and its sample points must be located within these bounds. Their actual location in the framebuffer is calculated by scaling the sample location by the fragment area. Attachments with storage for multiple samples per pixel are located at the pixel sample locations. Otherwise, the fragment’s sample locations are generally used for evaluation of associated data and fragment operations.

If the current pipeline includes a fragment shader with one or more variables in its interface decorated with Sample and Input, the data associated with those variables will be assigned independently for each sample. The values for each sample must be evaluated at the location of the sample. The data associated with any other variables not decorated with Sample and Input need not be evaluated independently for each sample.

A coverage mask is generated for each fragment, based on which samples within that fragment are determined to be within the area of the primitive that generated the fragment.

Single pixel fragments and multi-pixel fragments defined by a fragment density map have one set of samples. Multi-pixel fragments defined by a shading rate image have one set of samples per pixel. Multi-pixel fragments defined by setting the fragment shading rate have one set of samples per pixel. Each set of samples has a number of samples determined by VkPipelineMultisampleStateCreateInfo::rasterizationSamples. Each sample in a set is assigned a unique sample index i in the range [0, rasterizationSamples).

Each sample in a fragment is also assigned a unique coverage index j in the range [0, n × rasterizationSamples), where n is the number of sets in the fragment. If the fragment contains a single set of samples, the coverage index is always equal to the sample index. If a shading rate image is used and a fragment covers multiple pixels, the coverage index is determined as defined by VkPipelineViewportCoarseSampleOrderStateCreateInfoNV or vkCmdSetCoarseSampleOrderNV.

If the fragment shading rate is set, the coverage index j is determined as a function of the pixel index p, the sample index i, and the number of rasterization samples r as:

where the pixel index p is determined as a function of the pixel’s framebuffer location (x,y) and the fragment size (f_w,f_h):

The table below illustrates the pixel index for multi-pixel fragments:

The coverage mask includes B bits packed into W words, defined as:

Bit b in coverage mask word w is 1 if the sample with coverage index j = 32×w + b is covered, and 0 otherwise.

If the standardSampleLocations member of VkPhysicalDeviceLimits is VK_TRUE, then the sample counts VK_SAMPLE_COUNT_1_BIT, VK_SAMPLE_COUNT_2_BIT, VK_SAMPLE_COUNT_4_BIT, VK_SAMPLE_COUNT_8_BIT, and VK_SAMPLE_COUNT_16_BIT have sample locations as listed in the following table, with the ith entry in the table corresponding to sample index i. VK_SAMPLE_COUNT_32_BIT and VK_SAMPLE_COUNT_64_BIT do not have standard sample locations. Locations are defined relative to an origin in the upper left corner of the fragment.

Color images created with multiple samples per pixel use a compression technique where there are two arrays of data associated with each pixel. The first array contains one element per sample where each element stores an index to the second array defining the fragment mask of the pixel. The second array contains one element per color fragment and each element stores a unique color value in the format of the image. With this compression technique it is not always necessary to actually use unique storage locations for each color sample: when multiple samples share the same color value the fragment mask may have two samples referring to the same color fragment. The number of color fragments is determined by the samples member of the VkImageCreateInfo structure used to create the image. The VK_AMD_shader_fragment_mask device extension provides shader instructions enabling the application to get direct access to the fragment mask and the individual color fragment values.

The features advertised by VkPhysicalDeviceFragmentShadingRateFeaturesKHR allow an application to control the shading rate of a given fragment shader invocation.

The fragment shading rate strongly interacts with Multisampling, and the set of available rates for an implementation may be restricted by sample rate.

Fragment shading rates can be set at three points, with the three rates combined to determine the final shading rate.

The shadingRateImage feature allows pipelines to use a shading rate image to control the fragment area and the minimum number of fragment shader invocations launched for each fragment. When the shading rate image is enabled, the rasterizer determines a base shading rate for each region of the framebuffer covered by a primitive by fetching a value from the shading rate image and translating it to a shading rate using a per-viewport shading rate palette. This base shading rate is then adjusted to derive a final shading rate. The final shading rate specifies the fragment area and fragment shader invocation count to use for fragments generated in the region.

When the shading rate image is enabled in the current pipeline, rasterizing a primitive covering the pixel with coordinates (x,y) will fetch a shading rate index value from the shading rate image bound by vkCmdBindShadingRateImageNV. If the shading rate image view has a type of VK_IMAGE_VIEW_TYPE_2D, the lookup will use texel coordinates (u,v) where $u=\lfloor \frac{x}{twidth}\rfloor$, $v=\lfloor \frac{y}{theight}\rfloor$, and $twidth$ and $theight$ are the width and height of the implementation-dependent shading rate texel size. If the shading rate image view has a type of VK_IMAGE_VIEW_TYPE_2D_ARRAY, the lookup will use texel coordinates (u,v) to extract a texel from the layer l, where l is the layer of the framebuffer being rendered to. If l is greater than or equal to the number of layers in the image view, layer zero will be used.

If the bound shading rate image view is not VK_NULL_HANDLE and contains a texel with coordinates (u,v) in layer l (if applicable), the single unsigned integer component for that texel will be used as the shading rate index. If the (u,v) coordinate is outside the extents of the subresource used by the shading rate image view, or if the image view is VK_NULL_HANDLE, the shading rate index is zero. If the shading rate image view has multiple mipmap levels, the base level identified by VkImageSubresourceRange::baseMipLevel will be used.

A shading rate index is mapped to a base shading rate using a lookup table called the shading rate image palette. There is a separate palette for each viewport. The number of entries in each palette is given by the implementation-dependent shading rate image palette size.

To determine the base shading rate image, a shading rate index i is mapped to array element i in the array pShadingRatePaletteEntries for the palette corresponding to the viewport used for the fragment. If i is greater than or equal to the palette size shadingRatePaletteEntryCount, the base shading rate is undefined.

When the shading rate image is disabled, a shading rate of VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_PIXEL_NV will be used as the base shading rate.

Once a base shading rate has been established, it is adjusted to produce a final shading rate. First, if the base shading rate uses multiple pixels for each fragment, the implementation may reduce the fragment area to ensure that the total number of coverage samples for all pixels in a fragment does not exceed an implementation-dependent maximum.

If sample shading is active in the current pipeline and would result in processing n (n > 1) unique samples per fragment when the shading rate image is disabled, the shading rate is adjusted in an implementation-dependent manner to increase the number of fragment shader invocations spawned by the primitive. If the shading rate indicates fs pixels per fragment and fs is greater than n, the fragment area is adjusted so each fragment has approximately $\frac{fs}{n}$ pixels. Otherwise, if the shading rate indicates ipf invocations per fragment, the fragment area will be adjusted to a single pixel with approximately $\frac{ipf\times n}{fs}$ invocations per fragment.

If sample shading occurs due to the use of a fragment shader input variable decorated with SampleId or SamplePosition, the shading rate is ignored. Each fragment will have a single pixel and will spawn up to rasterizationSamples fragment shader invocations, as when using sample shading without a shading rate image.

Finally, if the shading rate specifies multiple fragment shader invocations per fragment, the total number of invocations in the shading rate is clamped to be no larger than rasterizationSamples.

When the final shading rate for a primitive covering pixel (x,y) has a fragment area of $fw\times fh$, the fragment for that pixel will cover all pixels with coordinates (x',y') that satisfy the equations:

This combined fragment is considered to have multiple coverage samples; the total number of samples in this fragment is given by $samples=fw\times fh\times rs$ where rs indicates the value of VkPipelineMultisampleStateCreateInfo::rasterizationSamples specified at pipeline creation time. The set of coverage samples in the fragment is the union of the per-pixel coverage samples in each of the fragment’s pixels The location and order of coverage samples within each pixel in the combined fragment are assigned as described in Multisampling and Custom Sample Locations. Each coverage sample in the set of pixels belonging to the combined fragment is assigned a unique coverage index in the range [0,samples-1]. If the shadingRateCoarseSampleOrder feature is supported, the order of coverage samples can be specified for each combination of fragment area and coverage sample count. If this feature is not supported, the sample order is implementation-dependent.

When using a coarse sample order of VK_COARSE_SAMPLE_ORDER_TYPE_PIXEL_MAJOR_NV for a fragment with an upper-left corner of $(fx,fy)$ with a width of $fw\times fh$ and $fsc$ samples per pixel, coverage index $cs$ of the fragment will be assigned to sample index $fs$ of pixel $(px,py)$ as follows:

When using a coarse sample order of VK_COARSE_SAMPLE_ORDER_TYPE_SAMPLE_MAJOR_NV, coverage index $cs$ will be assigned as follows:

If the final shading rate for a primitive covering pixel (x,y) results in n invocations per pixel (n > 1), n separate fragment shader invocations will be generated for the fragment. Each coverage sample in the fragment will be assigned to one of the n fragment shader invocations in an implementation-dependent manner. The outputs from the fragment output interface of each shader invocation will be broadcast to all of the framebuffer samples associated with the invocation. If none of the coverage samples associated with a fragment shader invocation is covered by a primitive, the implementation may discard the fragment shader invocation for those samples.

If the final shading rate for a primitive covering pixel (x,y) results in a fragment containing multiple pixels, a single set of fragment shader invocations will be generated for all pixels in the combined fragment. Outputs from the fragment output interface will be broadcast to all covered framebuffer samples belonging to the fragment. If the fragment shader executes code discarding the fragment, none of the samples of the fragment will be updated.

Sample shading can be used to specify a minimum number of unique samples to process for each fragment. If sample shading is enabled, an implementation must invoke the fragment shader at least max(⌈ VkPipelineMultisampleStateCreateInfo::minSampleShading × VkPipelineMultisampleStateCreateInfo::rasterizationSamples ⌉, 1) times per fragment. If VkPipelineMultisampleStateCreateInfo::sampleShadingEnable is set to VK_TRUE, sample shading is enabled.

If a fragment shader entry point statically uses an input variable decorated with a BuiltIn of SampleId or SamplePosition, sample shading is enabled and a value of 1.0 is used instead of minSampleShading. If a fragment shader entry point statically uses an input variable decorated with Sample, sample shading may be enabled and a value of 1.0 will be used instead of minSampleShading if it is. If the VK_AMD_mixed_attachment_samples extension is enabled and the subpass uses color attachments, the samples value used to create each color attachment is used instead of rasterizationSamples.

If there are fewer fragment invocations than covered samples, implementations may include those samples in fragment shader invocations in any manner as long as covered samples are all shaded at least once, and each invocation that is not a helper invocation covers at least one sample.

When the fragmentShaderBarycentric feature is enabled, the PerVertexKHR interpolation decoration can be used with fragment shader inputs to indicate that the decorated inputs do not have associated data in the fragment. Such inputs can only be accessed in a fragment shader using an array index whose value (0, 1, or 2) identifies one of the vertices of the primitive that produced the fragment. Reads of per-vertex values for missing vertices, such as the third vertex of a line primitive, will return values from the valid vertex with the highest index. This means that the per-vertex values of indices 1 and 2 for point primitives will be equal to those of index 0, and the per-vertex values of index 2 for line primitives will be equal to those of index 1.

When tessellation, geometry shading, and mesh shading are not active, fragment shader inputs decorated with PerVertexKHR will take values from one of the vertices of the primitive that produced the fragment, identified by the extra index provided in SPIR-V code accessing the input. If the n vertices passed to a draw call are numbered 0 through n-1, and the point, line, and triangle primitives produced by the draw call are numbered with consecutive integers beginning with zero, the following table indicates the original vertex numbers used when the provoking vertex mode is VK_PROVOKING_VERTEX_MODE_FIRST_VERTEX_EXT for index values of 0, 1, and 2. If an input decorated with PerVertexKHR is accessed with any other vertex index value, or is accessed while rasterizing a polygon when the VkPipelineRasterizationStateCreateInfo::polygonMode property of the currently active pipeline is not VK_POLYGON_MODE_FILL, an undefined value is returned.

When the provoking vertex mode is VK_PROVOKING_VERTEX_MODE_LAST_VERTEX_EXT, the original vertex numbers used are the same as above except as indicated in the table below.

When geometry or mesh shading is active, primitives processed by fragment shaders are assembled from the vertices emitted by the geometry or mesh shader. In this case, the vertices used for fragment shader inputs decorated with PerVertexKHR are derived by treating the primitives produced by the shader as though they were specified by a draw call and consulting the table above.

When using tessellation without geometry shading, the tessellator produces primitives in an implementation-dependent manner. While there is no defined vertex ordering for inputs decorated with PerVertexKHR, the vertex ordering used in this case will be consistent with the ordering used to derive the values of inputs decorated with BaryCoordKHR or BaryCoordNoPerspKHR.

Fragment shader inputs decorated with BaryCoordKHR or BaryCoordNoPerspKHR hold three-component vectors with barycentric weights that indicate the location of the fragment relative to the screen-space locations of vertices of its primitive. For point primitives, such variables are always assigned the value (1,0,0). For line primitives, the built-ins are obtained by interpolating an attribute whose values for the vertices numbered 0 and 1 are (1,0,0) and (0,1,0), respectively. For polygon primitives, the built-ins are obtained by interpolating an attribute whose values for the vertices numbered 0, 1, and 2 are (1,0,0), (0,1,0), and (0,0,1), respectively. For BaryCoordKHR, the values are obtained using perspective interpolation. For BaryCoordNoPerspKHR, the values are obtained using linear interpolation. The values of BaryCoordKHR and BaryCoordNoPerspKHR are undefined while rasterizing a polygon when the VkPipelineRasterizationStateCreateInfo::polygonMode property of the currently active pipeline is not VK_POLYGON_MODE_FILL.

A point is drawn by generating a set of fragments in the shape of a square centered around the vertex of the point. Each vertex has an associated point size controlling the width/height of that square. The point size is taken from the (potentially clipped) shader built-in PointSize written by:

and clamped to the implementation-dependent point size range [pointSizeRange[0],pointSizeRange[1]]. The value written to PointSize must be greater than zero.

Not all point sizes need be supported, but the size 1.0 must be supported. The range of supported sizes and the size of evenly-spaced gradations within that range are implementation-dependent. The range and gradations are obtained from the pointSizeRange and pointSizeGranularity members of VkPhysicalDeviceLimits. If, for instance, the size range is from 0.1 to 2.0 and the gradation size is 0.1, then the sizes 0.1, 0.2, …​, 1.9, 2.0 are supported. Additional point sizes may also be supported. There is no requirement that these sizes be equally spaced. If an unsupported size is requested, the nearest supported size is used instead.

Further, if the render pass has a fragment density map attachment, point size may be rounded by the implementation to a multiple of the fragment’s width or height.