Vulkan® 1.2.148 - A Specification (with all registered extensions)

26. Rasterization

Rasterization is the process by which a primitive is converted to a two-dimensional image. Each point of this image contains associated data such as depth, color, or other attributes.

Rasterizing a primitive begins by determining which squares of an integer grid in framebuffer coordinates are occupied by the primitive, and assigning one or more depth values to each such square. This process is described below for points, lines, and polygons.

A grid square, including its (x,y) framebuffer coordinates, z (depth), and associated data added by fragment shaders, is called a fragment. A fragment is located by its upper left corner, which lies on integer grid coordinates.

Rasterization operations also refer to a fragment’s sample locations, which are offset by fractional values from its upper left corner. The rasterization rules for points, lines, and triangles involve testing whether each sample location is inside the primitive. Fragments need not actually be square, and rasterization rules are not affected by the aspect ratio of fragments. Display of non-square grids, however, will cause rasterized points and line segments to appear fatter in one direction than the other.

We assume that fragments are square, since it simplifies antialiasing and texturing. After rasterization, fragments are processed by fragment operations.

Several factors affect rasterization, including the members of VkPipelineRasterizationStateCreateInfo and VkPipelineMultisampleStateCreateInfo.

The VkPipelineRasterizationStateCreateInfo structure is defined as:

// Provided by VK_VERSION_1_0
typedef struct VkPipelineRasterizationStateCreateInfo {
    VkStructureType                            sType;
    const void*                                pNext;
    VkPipelineRasterizationStateCreateFlags    flags;
    VkBool32                                   depthClampEnable;
    VkBool32                                   rasterizerDiscardEnable;
    VkPolygonMode                              polygonMode;
    VkCullModeFlags                            cullMode;
    VkFrontFace                                frontFace;
    VkBool32                                   depthBiasEnable;
    float                                      depthBiasConstantFactor;
    float                                      depthBiasClamp;
    float                                      depthBiasSlopeFactor;
    float                                      lineWidth;
} VkPipelineRasterizationStateCreateInfo;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
flags is reserved for future use.
depthClampEnable controls whether to clamp the fragment’s depth values as described in Depth Test. If the pipeline is not created with VkPipelineRasterizationDepthClipStateCreateInfoEXT present then enabling depth clamp will also disable clipping primitives to the z planes of the frustrum as described in Primitive Clipping. Otherwise depth clipping is controlled by the state set in VkPipelineRasterizationDepthClipStateCreateInfoEXT.
rasterizerDiscardEnable controls whether primitives are discarded immediately before the rasterization stage.
polygonMode is the triangle rendering mode. See VkPolygonMode.
cullMode is the triangle facing direction used for primitive culling. See VkCullModeFlagBits.
frontFace is a VkFrontFace value specifying the front-facing triangle orientation to be used for culling.
depthBiasEnable controls whether to bias fragment depth values.
depthBiasConstantFactor is a scalar factor controlling the constant depth value added to each fragment.
depthBiasClamp is the maximum (or minimum) depth bias of a fragment.
depthBiasSlopeFactor is a scalar factor applied to a fragment’s slope in depth bias calculations.
lineWidth is the width of rasterized line segments.

The application can also add a VkPipelineRasterizationStateRasterizationOrderAMD structure to the pNext chain of a VkPipelineRasterizationStateCreateInfo structure. This structure enables selecting the rasterization order to use when rendering with the corresponding graphics pipeline as described in Rasterization Order.

Valid Usage

If the depth clamping feature is not enabled, depthClampEnable must be VK_FALSE
If the non-solid fill modes feature is not enabled, polygonMode must be VK_POLYGON_MODE_FILL or VK_POLYGON_MODE_FILL_RECTANGLE_NV
If the VK_NV_fill_rectangle extension is not enabled, polygonMode must not be VK_POLYGON_MODE_FILL_RECTANGLE_NV

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_CREATE_INFO
Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid instance of VkPipelineRasterizationConservativeStateCreateInfoEXT, VkPipelineRasterizationDepthClipStateCreateInfoEXT, VkPipelineRasterizationLineStateCreateInfoEXT, VkPipelineRasterizationStateRasterizationOrderAMD, or VkPipelineRasterizationStateStreamCreateInfoEXT
The sType value of each struct in the pNext chain must be unique
flags must be 0
polygonMode must be a valid VkPolygonMode value
cullMode must be a valid combination of VkCullModeFlagBits values
frontFace must be a valid VkFrontFace value

// Provided by VK_VERSION_1_0
typedef VkFlags VkPipelineRasterizationStateCreateFlags;

VkPipelineRasterizationStateCreateFlags is a bitmask type for setting a mask, but is currently reserved for future use.

If the pNext chain of VkPipelineRasterizationStateCreateInfo includes a VkPipelineRasterizationDepthClipStateCreateInfoEXT structure, then that structure controls whether depth clipping is enabled or disabled.

The VkPipelineRasterizationDepthClipStateCreateInfoEXT structure is defined as:

// Provided by VK_EXT_depth_clip_enable
typedef struct VkPipelineRasterizationDepthClipStateCreateInfoEXT {
    VkStructureType                                        sType;
    const void*                                            pNext;
    VkPipelineRasterizationDepthClipStateCreateFlagsEXT    flags;
    VkBool32                                               depthClipEnable;
} VkPipelineRasterizationDepthClipStateCreateInfoEXT;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
flags is reserved for future use.
depthClipEnable controls whether depth clipping is enabled as described in Primitive Clipping.

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT
flags must be 0

// Provided by VK_EXT_depth_clip_enable
typedef VkFlags VkPipelineRasterizationDepthClipStateCreateFlagsEXT;

VkPipelineRasterizationDepthClipStateCreateFlagsEXT is a bitmask type for setting a mask, but is currently reserved for future use.

The VkPipelineMultisampleStateCreateInfo structure is defined as:

// Provided by VK_VERSION_1_0
typedef struct VkPipelineMultisampleStateCreateInfo {
    VkStructureType                          sType;
    const void*                              pNext;
    VkPipelineMultisampleStateCreateFlags    flags;
    VkSampleCountFlagBits                    rasterizationSamples;
    VkBool32                                 sampleShadingEnable;
    float                                    minSampleShading;
    const VkSampleMask*                      pSampleMask;
    VkBool32                                 alphaToCoverageEnable;
    VkBool32                                 alphaToOneEnable;
} VkPipelineMultisampleStateCreateInfo;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
flags is reserved for future use.
rasterizationSamples is a VkSampleCountFlagBits specifying the number of samples used in rasterization.
sampleShadingEnable can be used to enable Sample Shading.
minSampleShading specifies a minimum fraction of sample shading if sampleShadingEnable is set to VK_TRUE.
pSampleMask is an array of VkSampleMask values used in the sample mask test.
alphaToCoverageEnable controls whether a temporary coverage value is generated based on the alpha component of the fragment’s first color output as specified in the Multisample Coverage section.
alphaToOneEnable controls whether the alpha component of the fragment’s first color output is replaced with one as described in Multisample Coverage.

Each bit in the sample mask is associated with a unique sample index as defined for the coverage mask. Each bit b for mask word w in the sample mask corresponds to sample index i, where i = 32 × w + b. pSampleMask has a length equal to ⌈ rasterizationSamples / 32 ⌉ words.

If pSampleMask is NULL, it is treated as if the mask has all bits set to 1.

Valid Usage

If the sample rate shading feature is not enabled, sampleShadingEnable must be VK_FALSE
If the alpha to one feature is not enabled, alphaToOneEnable must be VK_FALSE
minSampleShading must be in the range [0,1]
If the VK_NV_framebuffer_mixed_samples extension is enabled, and if the subpass has any color attachments and rasterizationSamples is greater than the number of color samples, then sampleShadingEnable must be VK_FALSE

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid instance of VkPipelineCoverageModulationStateCreateInfoNV, VkPipelineCoverageReductionStateCreateInfoNV, VkPipelineCoverageToColorStateCreateInfoNV, or VkPipelineSampleLocationsStateCreateInfoEXT
The sType value of each struct in the pNext chain must be unique
flags must be 0
rasterizationSamples must be a valid VkSampleCountFlagBits value
If pSampleMask is not NULL, pSampleMask must be a valid pointer to an array of $⌈ \frac{r a s t e r i z a t i o n S a m p l e s}{3 2} ⌉$ VkSampleMask values

// Provided by VK_VERSION_1_0
typedef VkFlags VkPipelineMultisampleStateCreateFlags;

VkPipelineMultisampleStateCreateFlags is a bitmask type for setting a mask, but is currently reserved for future use.

The elements of the sample mask array are of type VkSampleMask, each representing 32 bits of coverage information:

// Provided by VK_VERSION_1_0
typedef uint32_t VkSampleMask;

Rasterization only generates fragments which cover one or more pixels inside the framebuffer. Pixels outside the framebuffer are never considered covered in the fragment. Fragments which would be produced by application of any of the primitive rasterization rules described below but which lie outside the framebuffer are not produced, nor are they processed by any later stage of the pipeline, including any of the fragment operations.

Surviving fragments are processed by fragment shaders. Fragment shaders determine associated data for fragments, and can also modify or replace their assigned depth values.

When the VK_AMD_mixed_attachment_samples and VK_NV_framebuffer_mixed_samples extensions are not enabled, if the subpass for which this pipeline is being created uses color and/or depth/stencil attachments, then rasterizationSamples must be the same as the sample count for those subpass attachments.

When the VK_AMD_mixed_attachment_samples extension is enabled, if the subpass for which this pipeline is being created uses color and/or depth/stencil attachments, then rasterizationSamples must be the same as the maximum of the sample counts of those subpass attachments.

When the VK_NV_framebuffer_mixed_samples extension is enabled, rasterizationSamples must match the sample count of the depth/stencil attachment if present, otherwise must be greater than or equal to the sample count of the color attachments, if present.

If the VK_NV_coverage_reduction_mode extension is enabled, the coverage reduction mode specified by VkPipelineCoverageReductionStateCreateInfoNV::coverageReductionMode, the rasterizationSamples member of pMultisampleState and the sample counts for the color and depth/stencil attachments (if present) must be a valid combination returned by vkGetPhysicalDeviceSupportedFramebufferMixedSamplesCombinationsNV

If the subpass for which this pipeline is being created does not use color or depth/stencil attachments, rasterizationSamples must follow the rules for a zero-attachment subpass.

26.1. Discarding Primitives Before Rasterization

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.

26.2. Controlling the Vertex Stream Used for Rasterization

By default vertex data output from the last vertex processing 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 vertex processing 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.

The vertex stream used for rasterization is specified by adding a VkPipelineRasterizationStateStreamCreateInfoEXT structure to the pNext chain of a VkPipelineRasterizationStateCreateInfo structure.

The VkPipelineRasterizationStateStreamCreateInfoEXT structure is defined as:

// Provided by VK_EXT_transform_feedback
typedef struct VkPipelineRasterizationStateStreamCreateInfoEXT {
    VkStructureType                                     sType;
    const void*                                         pNext;
    VkPipelineRasterizationStateStreamCreateFlagsEXT    flags;
    uint32_t                                            rasterizationStream;
} VkPipelineRasterizationStateStreamCreateInfoEXT;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
flags is reserved for future use.
rasterizationStream is the vertex stream selected for rasterization.

If this structure is not present, rasterizationStream is assumed to be zero.

Valid Usage

VkPhysicalDeviceTransformFeedbackFeaturesEXT::geometryStreams must be enabled
rasterizationStream must be less than VkPhysicalDeviceTransformFeedbackPropertiesEXT::maxTransformFeedbackStreams
rasterizationStream must be zero if VkPhysicalDeviceTransformFeedbackPropertiesEXT::transformFeedbackRasterizationStreamSelect is VK_FALSE

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_STREAM_CREATE_INFO_EXT
flags must be 0

// Provided by VK_EXT_transform_feedback
typedef VkFlags VkPipelineRasterizationStateStreamCreateFlagsEXT;

VkPipelineRasterizationStateStreamCreateFlagsEXT is a bitmask type for setting a mask, but is currently reserved for future use.

26.3. Rasterization Order

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:

Fragment operations, in the order defined
Blending, logic operations, and color writes

Each operation is atomically executed for each primitive and sample location.

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

The rasterization order to use for a graphics pipeline is specified by adding a VkPipelineRasterizationStateRasterizationOrderAMD structure to the pNext chain of a VkPipelineRasterizationStateCreateInfo structure.

The VkPipelineRasterizationStateRasterizationOrderAMD structure is defined as:

// Provided by VK_AMD_rasterization_order
typedef struct VkPipelineRasterizationStateRasterizationOrderAMD {
    VkStructureType            sType;
    const void*                pNext;
    VkRasterizationOrderAMD    rasterizationOrder;
} VkPipelineRasterizationStateRasterizationOrderAMD;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
rasterizationOrder is a VkRasterizationOrderAMD value specifying the primitive rasterization order to use.

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD
rasterizationOrder must be a valid VkRasterizationOrderAMD value

If the VK_AMD_rasterization_order device extension is not enabled or the application does not request a particular rasterization order through specifying a VkPipelineRasterizationStateRasterizationOrderAMD structure then the rasterization order used by the graphics pipeline defaults to VK_RASTERIZATION_ORDER_STRICT_AMD.

Possible values of VkPipelineRasterizationStateRasterizationOrderAMD::rasterizationOrder, specifying the primitive rasterization order, are:

// Provided by VK_AMD_rasterization_order
typedef enum VkRasterizationOrderAMD {
    VK_RASTERIZATION_ORDER_STRICT_AMD = 0,
    VK_RASTERIZATION_ORDER_RELAXED_AMD = 1,
} VkRasterizationOrderAMD;

VK_RASTERIZATION_ORDER_STRICT_AMD specifies that operations for each primitive in a subpass must occur in primitive order.
VK_RASTERIZATION_ORDER_RELAXED_AMD specifies that operations for each primitive in a subpass may not occur in primitive order.

26.4. Multisampling

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. An implementation may choose to assign the same associated data to more than one sample. The location for evaluating such associated data may be anywhere within the fragment area including the fragment’s center location (x_f,y_f) or any of the sample locations. When rasterizationSamples is VK_SAMPLE_COUNT_1_BIT, the fragment’s center location must be used. The different associated data values need not all be evaluated at the same location.

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. 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.

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

: B = n × rasterizationSamples
: W = ⌈B/32⌉

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.

Table 33. Standard sample locations
`VK_SAMPLE_COUNT_1_BIT`	`VK_SAMPLE_COUNT_2_BIT`	`VK_SAMPLE_COUNT_4_BIT`	`VK_SAMPLE_COUNT_8_BIT`	`VK_SAMPLE_COUNT_16_BIT`
(0.5,0.5)	(0.75,0.75) (0.25,0.25)	(0.375, 0.125) (0.875, 0.375) (0.125, 0.625) (0.625, 0.875)	(0.5625, 0.3125) (0.4375, 0.6875) (0.8125, 0.5625) (0.3125, 0.1875) (0.1875, 0.8125) (0.0625, 0.4375) (0.6875, 0.9375) (0.9375, 0.0625)	(0.5625, 0.5625) (0.4375, 0.3125) (0.3125, 0.625) (0.75, 0.4375) (0.1875, 0.375) (0.625, 0.8125) (0.8125, 0.6875) (0.6875, 0.1875) (0.375, 0.875) (0.5, 0.0625) (0.25, 0.125) (0.125, 0.75) (0.0, 0.5) (0.9375, 0.25) (0.875, 0.9375) (0.0625, 0.0)

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.

Figure 16. Fragment Mask

26.5. Custom Sample Locations

Applications can also control the sample locations used for rasterization.

If the pNext chain of the VkPipelineMultisampleStateCreateInfo structure specified at pipeline creation time includes a VkPipelineSampleLocationsStateCreateInfoEXT structure, then that structure controls the sample locations used when rasterizing primitives with the pipeline.

The VkPipelineSampleLocationsStateCreateInfoEXT structure is defined as:

// Provided by VK_EXT_sample_locations
typedef struct VkPipelineSampleLocationsStateCreateInfoEXT {
    VkStructureType             sType;
    const void*                 pNext;
    VkBool32                    sampleLocationsEnable;
    VkSampleLocationsInfoEXT    sampleLocationsInfo;
} VkPipelineSampleLocationsStateCreateInfoEXT;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
sampleLocationsEnable controls whether custom sample locations are used. If sampleLocationsEnable is VK_FALSE, the default sample locations are used and the values specified in sampleLocationsInfo are ignored.
sampleLocationsInfo is the sample locations to use during rasterization if sampleLocationsEnable is VK_TRUE and the graphics pipeline is not created with VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT.

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT
sampleLocationsInfo must be a valid VkSampleLocationsInfoEXT structure

The VkSampleLocationsInfoEXT structure is defined as:

// Provided by VK_EXT_sample_locations
typedef struct VkSampleLocationsInfoEXT {
    VkStructureType               sType;
    const void*                   pNext;
    VkSampleCountFlagBits         sampleLocationsPerPixel;
    VkExtent2D                    sampleLocationGridSize;
    uint32_t                      sampleLocationsCount;
    const VkSampleLocationEXT*    pSampleLocations;
} VkSampleLocationsInfoEXT;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
sampleLocationsPerPixel is a VkSampleCountFlagBits specifying the number of sample locations per pixel.
sampleLocationGridSize is the size of the sample location grid to select custom sample locations for.
sampleLocationsCount is the number of sample locations in pSampleLocations.
pSampleLocations is a pointer to an array of sampleLocationsCount VkSampleLocationEXT structures.

This structure can be used either to specify the sample locations to be used for rendering or to specify the set of sample locations an image subresource has been last rendered with for the purposes of layout transitions of depth/stencil images created with VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT.

The sample locations in pSampleLocations specify sampleLocationsPerPixel number of sample locations for each pixel in the grid of the size specified in sampleLocationGridSize. The sample location for sample i at the pixel grid location (x,y) is taken from pSampleLocations[(x + y × sampleLocationGridSize.width) × sampleLocationsPerPixel + i].

If the render pass has a fragment density map, the implementation will choose the sample locations for the fragment and the contents of pSampleLocations may be ignored.

Valid Usage

sampleLocationsPerPixel must be a bit value that is set in VkPhysicalDeviceSampleLocationsPropertiesEXT::sampleLocationSampleCounts
sampleLocationsCount must equal sampleLocationsPerPixel × sampleLocationGridSize.width × sampleLocationGridSize.height

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT
If sampleLocationsPerPixel is not 0, sampleLocationsPerPixel must be a valid VkSampleCountFlagBits value
If sampleLocationsCount is not 0, pSampleLocations must be a valid pointer to an array of sampleLocationsCount VkSampleLocationEXT structures

The VkSampleLocationEXT structure is defined as:

// Provided by VK_EXT_sample_locations
typedef struct VkSampleLocationEXT {
    float    x;
    float    y;
} VkSampleLocationEXT;

x is the horizontal coordinate of the sample’s location.
y is the vertical coordinate of the sample’s location.

The domain space of the sample location coordinates has an upper-left origin within the pixel in framebuffer space.

The values specified in a VkSampleLocationEXT structure are always clamped to the implementation-dependent sample location coordinate range [sampleLocationCoordinateRange[0],sampleLocationCoordinateRange[1]] that can be queried by adding a VkPhysicalDeviceSampleLocationsPropertiesEXT structure to the pNext chain of VkPhysicalDeviceProperties2.

The custom sample locations used for rasterization when VkPipelineSampleLocationsStateCreateInfoEXT::sampleLocationsEnable is VK_TRUE are specified by the VkPipelineSampleLocationsStateCreateInfoEXT::sampleLocationsInfo property of the bound graphics pipeline, if the pipeline was not created with VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT enabled.

Otherwise, the sample locations used for rasterization are set by calling vkCmdSetSampleLocationsEXT:

// Provided by VK_EXT_sample_locations
void vkCmdSetSampleLocationsEXT(
    VkCommandBuffer                             commandBuffer,
    const VkSampleLocationsInfoEXT*             pSampleLocationsInfo);

commandBuffer is the command buffer into which the command will be recorded.
pSampleLocationsInfo is the sample locations state to set.

Valid Usage

The sampleLocationsPerPixel member of pSampleLocationsInfo must equal the rasterizationSamples member of the VkPipelineMultisampleStateCreateInfo structure the bound graphics pipeline has been created with
If VkPhysicalDeviceSampleLocationsPropertiesEXT::variableSampleLocations is VK_FALSE then the current render pass must have been begun by specifying a VkRenderPassSampleLocationsBeginInfoEXT structure whose pPostSubpassSampleLocations member contains an element with a subpassIndex matching the current subpass index and the sampleLocationsInfo member of that element must match the sample locations state pointed to by pSampleLocationsInfo

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
pSampleLocationsInfo must be a valid pointer to a valid VkSampleLocationsInfoEXT structure
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

26.6. Shading Rate Image

The shading rate image 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 specifyies the fragment area and fragment shader invocation count to use for fragments generated in the region.

If the pNext chain of VkPipelineViewportStateCreateInfo includes a VkPipelineViewportShadingRateImageStateCreateInfoNV structure, then that structure includes parameters that control the shading rate.

The VkPipelineViewportShadingRateImageStateCreateInfoNV structure is defined as:

// Provided by VK_NV_shading_rate_image
typedef struct VkPipelineViewportShadingRateImageStateCreateInfoNV {
    VkStructureType                  sType;
    const void*                      pNext;
    VkBool32                         shadingRateImageEnable;
    uint32_t                         viewportCount;
    const VkShadingRatePaletteNV*    pShadingRatePalettes;
} VkPipelineViewportShadingRateImageStateCreateInfoNV;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
shadingRateImageEnable specifies whether shading rate image and palettes are used during rasterization.
viewportCount specifies the number of per-viewport palettes used to translate values stored in shading rate images.
pShadingRatePalettes is a pointer to an array of VkShadingRatePaletteNV structures defining the palette for each viewport. If the shading rate palette state is dynamic, this member is ignored.

If this structure is not present, shadingRateImageEnable is considered to be VK_FALSE, and the shading rate image and palettes are not used.

Valid Usage

If the multiple viewports feature is not enabled, viewportCount must be 0 or 1
viewportCount must be less than or equal to VkPhysicalDeviceLimits::maxViewports
If shadingRateImageEnable is VK_TRUE, viewportCount must be equal to the viewportCount member of VkPipelineViewportStateCreateInfo

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SHADING_RATE_IMAGE_STATE_CREATE_INFO_NV
viewportCount must be greater than 0

When shading rate image usage is enabled in the bound pipeline, the pipeline uses a shading rate image specified by the command:

// Provided by VK_NV_shading_rate_image
void vkCmdBindShadingRateImageNV(
    VkCommandBuffer                             commandBuffer,
    VkImageView                                 imageView,
    VkImageLayout                               imageLayout);

commandBuffer is the command buffer into which the command will be recorded.
imageView is an image view handle specifying the shading rate image. imageView may be set to VK_NULL_HANDLE, which is equivalent to specifying a view of an image filled with zero values.
imageLayout is the layout that the image subresources accessible from imageView will be in when the shading rate image is accessed.

Valid Usage

The shading rate image feature must be enabled
If imageView is not VK_NULL_HANDLE, it must be a valid VkImageView handle of type VK_IMAGE_VIEW_TYPE_2D or VK_IMAGE_VIEW_TYPE_2D_ARRAY
If imageView is not VK_NULL_HANDLE, it must have a format of VK_FORMAT_R8_UINT
If imageView is not VK_NULL_HANDLE, it must have been created with a usage value including VK_IMAGE_USAGE_SHADING_RATE_IMAGE_BIT_NV
If imageView is not VK_NULL_HANDLE, imageLayout must match the actual VkImageLayout of each subresource accessible from imageView at the time the subresource is accessed
If imageView is not VK_NULL_HANDLE, imageLayout must be VK_IMAGE_LAYOUT_SHADING_RATE_OPTIMAL_NV or VK_IMAGE_LAYOUT_GENERAL

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
If imageView is not VK_NULL_HANDLE, imageView must be a valid VkImageView handle
imageLayout must be a valid VkImageLayout value
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations
Both of commandBuffer, and imageView that are valid handles of non-ignored parameters must have been created, allocated, or retrieved from the same VkDevice

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

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 = ⌊ \frac{x}{t w i d t h} ⌋$ , $v = ⌊ \frac{y}{t h e i g h t} ⌋$ , and $t w i d t h$ and $t h e i g h t$ 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.

If a pipeline state object is created with VK_DYNAMIC_STATE_VIEWPORT_SHADING_RATE_PALETTE_NV enabled, the per-viewport shading rate image palettes are set by the command:

// Provided by VK_NV_shading_rate_image
void vkCmdSetViewportShadingRatePaletteNV(
    VkCommandBuffer                             commandBuffer,
    uint32_t                                    firstViewport,
    uint32_t                                    viewportCount,
    const VkShadingRatePaletteNV*               pShadingRatePalettes);

commandBuffer is the command buffer into which the command will be recorded.
firstViewport is the index of the first viewport whose shading rate palette is updated by the command.
viewportCount is the number of viewports whose shading rate palettes are updated by the command.
pShadingRatePalettes is a pointer to an array of VkShadingRatePaletteNV structures defining the palette for each viewport.

Valid Usage

The shading rate image feature must be enabled
firstViewport must be less than VkPhysicalDeviceLimits::maxViewports
The sum of firstViewport and viewportCount must be between 1 and VkPhysicalDeviceLimits::maxViewports, inclusive
If the multiple viewports feature is not enabled, firstViewport must be 0
If the multiple viewports feature is not enabled, viewportCount must be 1

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
pShadingRatePalettes must be a valid pointer to an array of viewportCount valid VkShadingRatePaletteNV structures
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations
viewportCount must be greater than 0

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

The VkShadingRatePaletteNV structure specifies to contents of a single shading rate image palette and is defined as:

// Provided by VK_NV_shading_rate_image
typedef struct VkShadingRatePaletteNV {
    uint32_t                              shadingRatePaletteEntryCount;
    const VkShadingRatePaletteEntryNV*    pShadingRatePaletteEntries;
} VkShadingRatePaletteNV;

shadingRatePaletteEntryCount specifies the number of entries in the shading rate image palette.
pShadingRatePaletteEntries is a pointer to an array of VkShadingRatePaletteEntryNV enums defining the shading rate for each palette entry.

Valid Usage

shadingRatePaletteEntryCount must be between 1 and VkPhysicalDeviceShadingRateImagePropertiesNV::shadingRatePaletteSize, inclusive

Valid Usage (Implicit)

pShadingRatePaletteEntries must be a valid pointer to an array of shadingRatePaletteEntryCount valid VkShadingRatePaletteEntryNV values
shadingRatePaletteEntryCount must be greater than 0

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.

The supported shading rate image palette entries are defined by VkShadingRatePaletteEntryNV:

// Provided by VK_NV_shading_rate_image
typedef enum VkShadingRatePaletteEntryNV {
    VK_SHADING_RATE_PALETTE_ENTRY_NO_INVOCATIONS_NV = 0,
    VK_SHADING_RATE_PALETTE_ENTRY_16_INVOCATIONS_PER_PIXEL_NV = 1,
    VK_SHADING_RATE_PALETTE_ENTRY_8_INVOCATIONS_PER_PIXEL_NV = 2,
    VK_SHADING_RATE_PALETTE_ENTRY_4_INVOCATIONS_PER_PIXEL_NV = 3,
    VK_SHADING_RATE_PALETTE_ENTRY_2_INVOCATIONS_PER_PIXEL_NV = 4,
    VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_PIXEL_NV = 5,
    VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_2X1_PIXELS_NV = 6,
    VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_1X2_PIXELS_NV = 7,
    VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_2X2_PIXELS_NV = 8,
    VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_4X2_PIXELS_NV = 9,
    VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_2X4_PIXELS_NV = 10,
    VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_4X4_PIXELS_NV = 11,
} VkShadingRatePaletteEntryNV;

The following table indicates the width and height (in pixels) of each fragment generated using the indicated shading rate, as well as the maximum number of fragment shader invocations launched for each fragment. When processing regions of a primitive that have a shading rate of VK_SHADING_RATE_PALETTE_ENTRY_NO_INVOCATIONS_NV, no fragments will be generated in that region.

Shading Rate	Width	Height	Invocations
`VK_SHADING_RATE_PALETTE_ENTRY_NO_INVOCATIONS_NV`	0	0	0
`VK_SHADING_RATE_PALETTE_ENTRY_16_INVOCATIONS_PER_PIXEL_NV`	1	1	16
`VK_SHADING_RATE_PALETTE_ENTRY_8_INVOCATIONS_PER_PIXEL_NV`	1	1	8
`VK_SHADING_RATE_PALETTE_ENTRY_4_INVOCATIONS_PER_PIXEL_NV`	1	1	4
`VK_SHADING_RATE_PALETTE_ENTRY_2_INVOCATIONS_PER_PIXEL_NV`	1	1	2
`VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_PIXEL_NV`	1	1	1
`VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_2X1_PIXELS_NV`	2	1	1
`VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_1X2_PIXELS_NV`	1	2	1
`VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_2X2_PIXELS_NV`	2	2	1
`VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_4X2_PIXELS_NV`	4	2	1
`VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_2X4_PIXELS_NV`	2	4	1
`VK_SHADING_RATE_PALETTE_ENTRY_1_INVOCATION_PER_4X4_PIXELS_NV`	4	4	1

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{f s}{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{i p f \times n}{f s}$ 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 totalSamples 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 the value of totalSamples used for sample shading.

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

⌊ \frac{x}{f w} ⌋ = ⌊ \frac{x ^{'}}{f w} ⌋

⌊ \frac{y}{f h} ⌋ = ⌊ \frac{y ^{'}}{f h} ⌋

This combined fragment is considered to have multiple coverage samples; the total number of samples in this fragment is given by $s a m p l e s = f w \times f h \times r s$ 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.

If the pNext chain of VkPipelineViewportStateCreateInfo includes a VkPipelineViewportCoarseSampleOrderStateCreateInfoNV structure, then that structure includes parameters that control the order of coverage samples in fragments larger than one pixel.

The VkPipelineViewportCoarseSampleOrderStateCreateInfoNV structure is defined as:

// Provided by VK_NV_shading_rate_image
typedef struct VkPipelineViewportCoarseSampleOrderStateCreateInfoNV {
    VkStructureType                       sType;
    const void*                           pNext;
    VkCoarseSampleOrderTypeNV             sampleOrderType;
    uint32_t                              customSampleOrderCount;
    const VkCoarseSampleOrderCustomNV*    pCustomSampleOrders;
} VkPipelineViewportCoarseSampleOrderStateCreateInfoNV;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
sampleOrderType specifies the mechanism used to order coverage samples in fragments larger than one pixel.
customSampleOrderCount specifies the number of custom sample orderings to use when ordering coverage samples.
pCustomSampleOrders is a pointer to an array of customSampleOrderCount VkCoarseSampleOrderCustomNV structures, each of which specifies the coverage sample order for a single combination of fragment area and coverage sample count.

If this structure is not present, sampleOrderType is considered to be VK_COARSE_SAMPLE_ORDER_TYPE_DEFAULT_NV.

If sampleOrderType is VK_COARSE_SAMPLE_ORDER_TYPE_CUSTOM_NV, the coverage sample order used for any combination of fragment area and coverage sample count not enumerated in pCustomSampleOrders will be identical to that used for VK_COARSE_SAMPLE_ORDER_TYPE_DEFAULT_NV.

If the pipeline was created with VK_DYNAMIC_STATE_VIEWPORT_COARSE_SAMPLE_ORDER_NV, the contents of this structure (if present) are ignored, and the coverage sample order is instead specified by vkCmdSetCoarseSampleOrderNV.

Valid Usage

If sampleOrderType is not VK_COARSE_SAMPLE_ORDER_TYPE_CUSTOM_NV, customSamplerOrderCount must be 0
The array pCustomSampleOrders must not contain two structures with matching values for both the shadingRate and sampleCount members

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_COARSE_SAMPLE_ORDER_STATE_CREATE_INFO_NV
sampleOrderType must be a valid VkCoarseSampleOrderTypeNV value
If customSampleOrderCount is not 0, pCustomSampleOrders must be a valid pointer to an array of customSampleOrderCount valid VkCoarseSampleOrderCustomNV structures

The type VkCoarseSampleOrderTypeNV specifies the technique used to order coverage samples in fragments larger than one pixel, and is defined as:

// Provided by VK_NV_shading_rate_image
typedef enum VkCoarseSampleOrderTypeNV {
    VK_COARSE_SAMPLE_ORDER_TYPE_DEFAULT_NV = 0,
    VK_COARSE_SAMPLE_ORDER_TYPE_CUSTOM_NV = 1,
    VK_COARSE_SAMPLE_ORDER_TYPE_PIXEL_MAJOR_NV = 2,
    VK_COARSE_SAMPLE_ORDER_TYPE_SAMPLE_MAJOR_NV = 3,
} VkCoarseSampleOrderTypeNV;

VK_COARSE_SAMPLE_ORDER_TYPE_DEFAULT_NV specifies that coverage samples will be ordered in an implementation-dependent manner.
VK_COARSE_SAMPLE_ORDER_TYPE_CUSTOM_NV specifies that coverage samples will be ordered according to the array of custom orderings provided in either the pCustomSampleOrders member of VkPipelineViewportCoarseSampleOrderStateCreateInfoNV or the pCustomSampleOrders member of vkCmdSetCoarseSampleOrderNV.
VK_COARSE_SAMPLE_ORDER_TYPE_PIXEL_MAJOR_NV specifies that coverage samples will be ordered sequentially, sorted first by pixel coordinate (in row-major order) and then by sample index.
VK_COARSE_SAMPLE_ORDER_TYPE_SAMPLE_MAJOR_NV specifies that coverage samples will be ordered sequentially, sorted first by sample index and then by pixel coordinate (in row-major order).

When using a coarse sample order of VK_COARSE_SAMPLE_ORDER_TYPE_PIXEL_MAJOR_NV for a fragment with an upper-left corner of $(f x, f y)$ with a width of $f w \times f h$ and $f s c$ samples per pixel, coverage index $c s$ of the fragment will be assigned to sample index $f s$ of pixel $(p x, p y)$ as follows:

p x = p y = f s = f x + (⌊ \frac{c s}{f s c} ⌋ % f w) f y + ⌊ \frac{c s}{f s c \times f w} ⌋ c s % f s c

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

p x = p y = f s = f x + c s % f w (f y + ⌊ \frac{c s}{f w} ⌋ % f h) ⌊ \frac{c s}{f w \times f h} ⌋

The VkCoarseSampleOrderCustomNV structure is used with a coverage sample ordering type of VK_COARSE_SAMPLE_ORDER_TYPE_CUSTOM_NV to specify the order of coverage samples for one combination of fragment width, fragment height, and coverage sample count. The structure is defined as:

// Provided by VK_NV_shading_rate_image
typedef struct VkCoarseSampleOrderCustomNV {
    VkShadingRatePaletteEntryNV        shadingRate;
    uint32_t                           sampleCount;
    uint32_t                           sampleLocationCount;
    const VkCoarseSampleLocationNV*    pSampleLocations;
} VkCoarseSampleOrderCustomNV;

shadingRate is a shading rate palette entry that identifies the fragment width and height for the combination of fragment area and per-pixel coverage sample count to control.
sampleCount identifies the per-pixel coverage sample count for the combination of fragment area and coverage sample count to control.
sampleLocationCount specifies the number of sample locations in the custom ordering.
pSampleLocations is a pointer to an array of VkCoarseSampleOrderCustomNV structures specifying the location of each sample in the custom ordering.

When using a custom sample ordering, element j in pSampleLocations specifies a specific pixel location and sample index that corresponds to coverage index j in the multi-pixel fragment.

Valid Usage

shadingRate must be a shading rate that generates fragments with more than one pixel
sampleCount must correspond to a sample count enumerated in VkSampleCountFlags whose corresponding bit is set in VkPhysicalDeviceLimits::framebufferNoAttachmentsSampleCounts
sampleLocationCount must be equal to the product of sampleCount, the fragment width for shadingRate, and the fragment height for shadingRate
sampleLocationCount must be less than or equal to the value of VkPhysicalDeviceShadingRateImagePropertiesNV::shadingRateMaxCoarseSamples
The array pSampleLocations must contain exactly one entry for every combination of valid values for pixelX, pixelY, and sample in the structure VkCoarseSampleOrderCustomNV

Valid Usage (Implicit)

shadingRate must be a valid VkShadingRatePaletteEntryNV value
pSampleLocations must be a valid pointer to an array of sampleLocationCount VkCoarseSampleLocationNV structures
sampleLocationCount must be greater than 0

The VkCoarseSampleLocationNV structure identifies a specific pixel and sample index for one of the coverage samples in a fragment that is larger than one pixel. This structure is defined as:

// Provided by VK_NV_shading_rate_image
typedef struct VkCoarseSampleLocationNV {
    uint32_t    pixelX;
    uint32_t    pixelY;
    uint32_t    sample;
} VkCoarseSampleLocationNV;

pixelX is added to the x coordinate of the upper-leftmost pixel of each fragment to identify the pixel containing the coverage sample.
pixelY is added to the y coordinate of the upper-leftmost pixel of each fragment to identify the pixel containing the coverage sample.
sample is the number of the coverage sample in the pixel identified by pixelX and pixelY.

Valid Usage

pixelX must be less than the width (in pixels) of the fragment
pixelY must be less than the height (in pixels) of the fragment
sample must be less than the number of coverage samples in each pixel belonging to the fragment

If a pipeline state object is created with VK_DYNAMIC_STATE_VIEWPORT_COARSE_SAMPLE_ORDER_NV enabled, the order of coverage samples in fragments larger than one pixel is set by the command:

// Provided by VK_NV_shading_rate_image
void vkCmdSetCoarseSampleOrderNV(
    VkCommandBuffer                             commandBuffer,
    VkCoarseSampleOrderTypeNV                   sampleOrderType,
    uint32_t                                    customSampleOrderCount,
    const VkCoarseSampleOrderCustomNV*          pCustomSampleOrders);

commandBuffer is the command buffer into which the command will be recorded.
sampleOrderType specifies the mechanism used to order coverage samples in fragments larger than one pixel.
customSampleOrderCount specifies the number of custom sample orderings to use when ordering coverage samples.
pCustomSampleOrders is a pointer to an array of VkCoarseSampleOrderCustomNV structures, each of which specifies the coverage sample order for a single combination of fragment area and coverage sample count.

Valid Usage

If sampleOrderType is not VK_COARSE_SAMPLE_ORDER_TYPE_CUSTOM_NV, customSamplerOrderCount must be 0
The array pCustomSampleOrders must not contain two structures with matching values for both the shadingRate and sampleCount members

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
sampleOrderType must be a valid VkCoarseSampleOrderTypeNV value
If customSampleOrderCount is not 0, pCustomSampleOrders must be a valid pointer to an array of customSampleOrderCount valid VkCoarseSampleOrderCustomNV structures
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

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.

26.7. Sample Shading

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 provide a minimum of max(⌈ minSampleShadingFactor × totalSamples ⌉, 1) unique associated data for each fragment, where minSampleShadingFactor is the minimum fraction of sample shading. If the VK_AMD_mixed_attachment_samples extension is enabled and the subpass uses color attachments, totalSamples is the number of samples of the color attachments. Otherwise, totalSamples is the value of VkPipelineMultisampleStateCreateInfo::rasterizationSamples specified at pipeline creation time. These are associated with the samples in an implementation-dependent manner. When minSampleShadingFactor is 1.0, a separate set of associated data are evaluated for each sample, and each set of values is evaluated at the sample location.

Sample shading is enabled for a graphics pipeline:

If the interface of the fragment shader entry point of the graphics pipeline includes an input variable decorated with SampleId or SamplePosition. In this case minSampleShadingFactor takes the value 1.0.
Else if the sampleShadingEnable member of the VkPipelineMultisampleStateCreateInfo structure specified when creating the graphics pipeline is set to VK_TRUE. In this case minSampleShadingFactor takes the value of VkPipelineMultisampleStateCreateInfo::minSampleShading.

Otherwise, sample shading is considered disabled.

26.8. Barycentric Interpolation

When the fragmentShaderBarycentric feature is enabled, the PerVertexNV 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.

When tessellation, geometry shading, and mesh shading are not active, fragment shader inputs decorated with PerVertexNV 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 for index values of 0, 1, and 2. If an input decorated with PerVertexNV is accessed with any other vertex index value, an undefined value is returned.

Primitive Topology Vertex 0 Vertex 1 Vertex 2

Primitive Topology	Vertex 0	Vertex 1	Vertex 2
`VK_PRIMITIVE_TOPOLOGY_POINT_LIST`	i	-	-
`VK_PRIMITIVE_TOPOLOGY_LINE_LIST`	2i	2i+1	-
`VK_PRIMITIVE_TOPOLOGY_LINE_STRIP`	i	i+1	-
`VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST`	3i	3i+1	3i+2
`VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP` (even)	i	i+1	i+2
`VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP` (odd)	i	i+2	i+1
`VK_PRIMITIVE_TOPOLOGY_TRIANGLE_FAN`	i+1	i+2	0
`VK_PRIMITIVE_TOPOLOGY_LINE_LIST_WITH_ADJACENCY`	4i+1	4i+2	-
`VK_PRIMITIVE_TOPOLOGY_LINE_STRIP_WITH_ADJACENCY`	i+1	i+2	-
`VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST_WITH_ADJACENCY`	6i	6i+2	6i+4
`VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP_WITH_ADJACENCY` (even)	2i	2i+2	2i+4
`VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP_WITH_ADJACENCY` (odd)	2i	2i+4	2i+2

VK_PRIMITIVE_TOPOLOGY_POINT_LIST

VK_PRIMITIVE_TOPOLOGY_LINE_LIST

2i+1

VK_PRIMITIVE_TOPOLOGY_LINE_STRIP

i+1

VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST

3i+1

3i+2

VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP (even)

i+1

i+2

VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP (odd)

i+2

i+1

VK_PRIMITIVE_TOPOLOGY_TRIANGLE_FAN

i+1

i+2

VK_PRIMITIVE_TOPOLOGY_LINE_LIST_WITH_ADJACENCY

4i+1

4i+2

VK_PRIMITIVE_TOPOLOGY_LINE_STRIP_WITH_ADJACENCY

i+1

i+2

VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST_WITH_ADJACENCY

6i+2

6i+4

VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP_WITH_ADJACENCY (even)

2i+2

2i+4

VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP_WITH_ADJACENCY (odd)

2i+4

2i+2

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 PerVertexNV 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 PerVertexNV, the vertex ordering used in this case will be consistent with the ordering used to derive the values of inputs decorated with BaryCoordNV or BaryCoordNoPerspNV.

Fragment shader inputs decorated with BaryCoordNV or BaryCoordNoPerspNV 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 BaryCoordNV, the values are obtained using perspective interpolation. For BaryCoordNoPerspNV, the values are obtained using linear interpolation.

26.9. Points

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 that controls the width/height of that square. The point size is taken from the (potentially clipped) shader built-in PointSize written by:

the geometry shader, if active;
the tessellation evaluation shader, if active and no geometry shader is active;
the vertex shader, otherwise

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 size 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.

26.9.1. Basic Point Rasterization

Point rasterization produces a fragment for each fragment area group of framebuffer pixels with one or more sample points that intersect a region centered at the point’s (x_f,y_f). This region is a square with side equal to the current point size. Coverage bits that correspond to sample points that intersect the region are 1, other coverage bits are 0. All fragments produced in rasterizing a point are assigned the same associated data, which are those of the vertex corresponding to the point. However, the fragment shader built-in PointCoord contains point sprite texture coordinates. The s and t point sprite texture coordinates vary from zero to one across the point horizontally left-to-right and top-to-bottom, respectively. The following formulas are used to evaluate s and t:

s = \frac{1}{2} + \frac{( x _{p} - x _{f} )}{size}

t = \frac{1}{2} + \frac{( y _{p} - y _{f} )}{size}

where size is the point’s size; (x_p,y_p) is the location at which the point sprite coordinates are evaluated - this may be the framebuffer coordinates of the fragment center, or the location of a sample; and (x_f,y_f) is the exact, unrounded framebuffer coordinate of the vertex for the point.

26.10. Line Segments

Line segment rasterization options are controlled by the VkPipelineRasterizationLineStateCreateInfoEXT structure.

The VkPipelineRasterizationLineStateCreateInfoEXT structure is defined as:

// Provided by VK_EXT_line_rasterization
typedef struct VkPipelineRasterizationLineStateCreateInfoEXT {
    VkStructureType               sType;
    const void*                   pNext;
    VkLineRasterizationModeEXT    lineRasterizationMode;
    VkBool32                      stippledLineEnable;
    uint32_t                      lineStippleFactor;
    uint16_t                      lineStipplePattern;
} VkPipelineRasterizationLineStateCreateInfoEXT;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
lineRasterizationMode is a VkLineRasterizationModeEXT value selecting the style of line rasterization.
stippledLineEnable enables stippled line rasterization.
lineStippleFactor is the repeat factor used in stippled line rasterization.
lineStipplePattern is the bit pattern used in stippled line rasterization.

Valid Usage

If lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT, then the rectangularLines feature must be enabled
If lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, then the bresenhamLines feature must be enabled
If lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then the smoothLines feature must be enabled
If stippledLineEnable is VK_TRUE and lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT, then the stippledRectangularLines feature must be enabled
If stippledLineEnable is VK_TRUE and lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, then the stippledBresenhamLines feature must be enabled
If stippledLineEnable is VK_TRUE and lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then the stippledSmoothLines feature must be enabled
If stippledLineEnable is VK_TRUE and lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT, then the stippledRectangularLines feature must be enabled and VkPhysicalDeviceLimits::strictLines must be VK_TRUE

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_LINE_STATE_CREATE_INFO_EXT
lineRasterizationMode must be a valid VkLineRasterizationModeEXT value

Possible values of VkPipelineRasterizationLineStateCreateInfoEXT::lineRasterizationMode are:

// Provided by VK_EXT_line_rasterization
typedef enum VkLineRasterizationModeEXT {
    VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT = 0,
    VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT = 1,
    VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT = 2,
    VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT = 3,
} VkLineRasterizationModeEXT;

VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT is equivalent to VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT if VkPhysicalDeviceLimits::strictLines is VK_TRUE, otherwise lines are drawn as non-strictLines parallelograms. Both of these modes are defined in Basic Line Segment Rasterization.
VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT specifies lines drawn as if they were rectangles extruded from the line
VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT specifies lines drawn by determining which pixel diamonds the line intersects and exits, as defined in Bresenham Line Segment Rasterization.
VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT specifies lines drawn if they were rectangles extruded from the line, with alpha falloff, as defined in Smooth Lines.

Each line segment has an associated width. The line width is specified by the VkPipelineRasterizationStateCreateInfo::lineWidth property of the currently active pipeline, if the pipeline was not created with VK_DYNAMIC_STATE_LINE_WIDTH enabled.

Otherwise, the line width is set by calling vkCmdSetLineWidth:

// Provided by VK_VERSION_1_0
void vkCmdSetLineWidth(
    VkCommandBuffer                             commandBuffer,
    float                                       lineWidth);

commandBuffer is the command buffer into which the command will be recorded.
lineWidth is the width of rasterized line segments.

Valid Usage

If the wide lines feature is not enabled, lineWidth must be 1.0

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

Not all line widths need be supported for line segment rasterization, but width 1.0 antialiased segments must be provided. The range and gradations are obtained from the lineWidthRange and lineWidthGranularity 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 size 0.1, 0.2, …, 1.9, 2.0 are supported. Additional line widths may also be supported. There is no requirement that these widths be equally spaced. If an unsupported width is requested, the nearest supported width is used instead.

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

26.10.1. Basic Line Segment Rasterization

If the lineRasterizationMode member of VkPipelineRasterizationLineStateCreateInfoEXT is VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT, rasterized line segments produce fragments which intersect a rectangle centered on the line segment. Two of the edges are parallel to the specified line segment; each is at a distance of one-half the current width from that segment in directions perpendicular to the direction of the line. The other two edges pass through the line endpoints and are perpendicular to the direction of the specified line segment. Coverage bits that correspond to sample points that intersect the rectangle are 1, other coverage bits are 0.

Next we specify how the data associated with each rasterized fragment are obtained. Let p_r = (x_d, y_d) be the framebuffer coordinates at which associated data are evaluated. This may be the center of a fragment or the location of a sample within the fragment. When rasterizationSamples is VK_SAMPLE_COUNT_1_BIT, the fragment center must be used. Let p_a = (x_a, y_a) and p_b = (x_b,y_b) be initial and final endpoints of the line segment, respectively. Set

t = \frac{( p _{r} - p _{a} ) \cdot ( p _{b} - p _{a} )}{∥ p _{b} - p _{a} ∥ ^{2}}

(Note that t = 0 at p_a and t = 1 at p_b. Also note that this calculation projects the vector from p_a to p_r onto the line, and thus computes the normalized distance of the fragment along the line.)

The value of an associated datum f for the fragment, whether it be a shader output or the clip w coordinate, must be determined using perspective interpolation:

f = \frac{( 1 - t ) f _{a} / w _{a} + t f _{b} / w _{b}}{( 1 - t ) / w _{a} + t / w _{b}}

where f_a and f_b are the data associated with the starting and ending endpoints of the segment, respectively; w_a and w_b are the clip w coordinates of the starting and ending endpoints of the segments, respectively.

Depth values for lines must be determined using linear interpolation:

: z = (1 - t) z_a + t z_b

where z_a and z_b are the depth values of the starting and ending endpoints of the segment, respectively.

The NoPerspective and Flat interpolation decorations can be used with fragment shader inputs to declare how they are interpolated. When neither decoration is applied, perspective interpolation is performed as described above. When the NoPerspective decoration is used, linear interpolation is performed in the same fashion as for depth values, as described above. When the Flat decoration is used, no interpolation is performed, and outputs are taken from the corresponding input value of the provoking vertex corresponding to that primitive.

When the fragmentShaderBarycentric feature is enabled, the PerVertexNV interpolation decoration can also be used with fragment shader inputs which indicate that the decorated inputs are not interpolated and can only be accessed using an extra array dimension, where the extra index identifies one of the vertices of the primitive that produced the fragment.

The above description documents the preferred method of line rasterization, and must be used when the implementation advertises the strictLines limit in VkPhysicalDeviceLimits as VK_TRUE.

When strictLines is VK_FALSE, the edges of the lines are generated as a parallelogram surrounding the original line. The major axis is chosen by noting the axis in which there is the greatest distance between the line start and end points. If the difference is equal in both directions then the X axis is chosen as the major axis. Edges 2 and 3 are aligned to the minor axis and are centered on the endpoints of the line as in Non strict lines, and each is lineWidth long. Edges 0 and 1 are parallel to the line and connect the endpoints of edges 2 and 3. Coverage bits that correspond to sample points that intersect the parallelogram are 1, other coverage bits are 0.

Samples that fall exactly on the edge of the parallelogram follow the polygon rasterization rules.

Interpolation occurs as if the parallelogram was decomposed into two triangles where each pair of vertices at each end of the line has identical attributes.

Figure 17. Non strict lines

Only when strictLines is VK_FALSE implementations may deviate from the non-strict line algorithm described above in the following ways:

Implementations may instead interpolate each fragment according to the formula in Basic Line Segment Rasterization using the original line segment endpoints.
Rasterization of non-antialiased non-strict line segments may be performed using the rules defined in Bresenham Line Segment Rasterization.

26.10.2. Bresenham Line Segment Rasterization

If lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, then the following rules replace the line rasterization rules defined in Basic Line Segment Rasterization.

Non-strict lines may also follow these rasterization rules for non-antialiased lines.

Line segment rasterization begins by characterizing the segment as either x-major or y-major. x-major line segments have slope in the closed interval [-1,1]; all other line segments are y-major (slope is determined by the segment’s endpoints). We specify rasterization only for x-major segments except in cases where the modifications for y-major segments are not self-evident.

Ideally, Vulkan uses a diamond-exit rule to determine those fragments that are produced by rasterizing a line segment. For each fragment f with center at framebuffer coordinates x_f and y_f, define a diamond-shaped region that is the intersection of four half planes:

R_{f} = {(x, y) ∣ ∣ x - x_{f} ∣ + ∣ y - y_{f} ∣ < \frac{1}{2}}

Essentially, a line segment starting at p_a and ending at p_b produces those fragments f for which the segment intersects R_f, except if p_b is contained in R_f.

Figure 18. Visualization of Bresenham’s algorithm

To avoid difficulties when an endpoint lies on a boundary of R_f we (in principle) perturb the supplied endpoints by a tiny amount. Let p_a and p_b have framebuffer coordinates (x_a, y_a) and (x_b, y_b), respectively. Obtain the perturbed endpoints p_a' given by (x_a, y_a) - (ε, ε²) and p_b' given by (x_b, y_b) - (ε, ε²). Rasterizing the line segment starting at p_a and ending at p_b produces those fragments f for which the segment starting at p_a' and ending on p_b' intersects R_f, except if p_b' is contained in R_f. ε is chosen to be so small that rasterizing the line segment produces the same fragments when δ is substituted for ε for any 0 < δ ≤ ε.

When p_a and p_b lie on fragment centers, this characterization of fragments reduces to Bresenham’s algorithm with one modification: lines produced in this description are "half-open," meaning that the final fragment (corresponding to p_b) is not drawn. This means that when rasterizing a series of connected line segments, shared endpoints will be produced only once rather than twice (as would occur with Bresenham’s algorithm).

Implementations may use other line segment rasterization algorithms, subject to the following rules:

The coordinates of a fragment produced by the algorithm must not deviate by more than one unit in either x or y framebuffer coordinates from a corresponding fragment produced by the diamond-exit rule.
The total number of fragments produced by the algorithm must not differ from that produced by the diamond-exit rule by no more than one.
For an x-major line, two fragments that lie in the same framebuffer-coordinate column must not be produced (for a y-major line, two fragments that lie in the same framebuffer-coordinate row must not be produced).
If two line segments share a common endpoint, and both segments are either x-major (both left-to-right or both right-to-left) or y-major (both bottom-to-top or both top-to-bottom), then rasterizing both segments must not produce duplicate fragments. Fragments also must not be omitted so as to interrupt continuity of the connected segments.

The actual width w of Bresenham lines is determined by rounding the line width to the nearest integer, clamping it to the implementation-dependent lineWidthRange (with both values rounded to the nearest integer), then clamping it to be no less than 1.

Bresenham line segments of width other than one are rasterized by offsetting them in the minor direction (for an x-major line, the minor direction is y, and for a y-major line, the minor direction is x) and producing a row or column of fragments in the minor direction. If the line segment has endpoints given by (x₀, y₀) and (x₁, y₁) in framebuffer coordinates, the segment with endpoints $(x_{0}, y_{0} - \frac{w - 1}{2})$ and $(x_{1}, y_{1} - \frac{w - 1}{2})$ is rasterized, but instead of a single fragment, a column of fragments of height w (a row of fragments of length w for a y-major segment) is produced at each x (y for y-major) location. The lowest fragment of this column is the fragment that would be produced by rasterizing the segment of width 1 with the modified coordinates.

The preferred method of attribute interpolation for a wide line is to generate the same attribute values for all fragments in the row or column described above, as if the adjusted line were used for interpolation and those values replicated to the other fragments, except for FragCoord which is interpolated as usual. Implementations may instead interpolate each fragment according to the formula in Basic Line Segment Rasterization, using the original line segment endpoints.

When Bresenham lines are being rasterized, sample locations may all be treated as being at the pixel center (this may affect attribute and depth interpolation).

Note

The sample locations described above are not used for determining coverage, they are only used for things like attribute interpolation. The rasterization rules that determine coverage are defined in terms of whether the line intersects pixels, as opposed to the point sampling rules used for other primitive types. So these rules are independent of the sample locations. One consequence of this is that Bresenham lines cover the same pixels regardless of the number of rasterization samples, and cover all samples in those pixels (unless masked out or killed).

26.10.3. Line Stipple

If the stippledLineEnable member of VkPipelineRasterizationLineStateCreateInfoEXT is VK_TRUE, then lines are rasterized with a line stipple determined by lineStippleFactor and lineStipplePattern. lineStipplePattern is an unsigned 16-bit integer that determines which fragments are to be drawn or discarded when the line is rasterized. lineStippleFactor is a count that is used to modify the effective line stipple by causing each bit in lineStipplePattern to be used lineStippleFactor times.

Line stippling discards certain fragments that are produced by rasterization. The masking is achieved using three parameters: the 16-bit line stipple pattern p, the line stipple factor r, and an integer stipple counter s. Let

b = ⌊ \frac{s}{r} ⌋ m o d 16

Then a fragment is produced if the b’th bit of p is 1, and discarded otherwise. The bits of p are numbered with 0 being the least significant and 15 being the most significant.

The initial value of s is zero. For VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT lines, s is incremented after production of each fragment of a line segment (fragments are produced in order, beginning at the starting point and working towards the ending point). For VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT and VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT lines, the rectangular region is subdivided into adjacent unit-length rectangles, and s is incremented once for each rectangle. Rectangles with a value of s such that the b’th bit of p is zero are discarded. If the last rectangle in a line segment is shorter than unit-length, then the remainder may carry over to the next line segment in the line strip using the same value of s (this is the preferred behavior, for the stipple pattern to appear more consistent through the strip).

s is reset to 0 at the start of each strip (for line strips), and before every line segment in a group of independent segments.

If the line segment has been clipped, then the value of s at the beginning of the line segment is implementation-dependent.

The line stipple factor and pattern are specified by the VkPipelineRasterizationLineStateCreateInfoEXT::lineStippleFactor and VkPipelineRasterizationLineStateCreateInfoEXT::lineStipplePattern members of the currently active pipeline, if the pipeline was not created with VK_DYNAMIC_STATE_LINE_STIPPLE_EXT enabled.

Otherwise, the line stipple factor and pattern are set by calling vkCmdSetLineStippleEXT:

// Provided by VK_EXT_line_rasterization
void vkCmdSetLineStippleEXT(
    VkCommandBuffer                             commandBuffer,
    uint32_t                                    lineStippleFactor,
    uint16_t                                    lineStipplePattern);

commandBuffer is the command buffer into which the command will be recorded.
lineStippleFactor is the repeat factor used in stippled line rasterization.
lineStipplePattern is the bit pattern used in stippled line rasterization.

Valid Usage

lineStippleFactor must be in the range [1,256]

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

26.10.4. Smooth Lines

If the lineRasterizationMode member of VkPipelineRasterizationLineStateCreateInfoEXT is VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then lines are considered to be rectangles using the same geometry as for VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT lines. The rules for determining which pixels are covered are implementation-dependent, and may include nearby pixels where no sample locations are covered or where the rectangle doesn’t intersect the pixel at all. For each pixel that is considered covered, the fragment computes a coverage value that approximates the area of the intersection of the rectangle with the pixel square, and this coverage value is multiplied into the color location 0’s alpha value after fragment shading, as described in Multisample Coverage.

Note

The details of the rasterization rules and area calculation are left intentionally vague, to allow implementations to generate coverage and values that are aesthetically pleasing.

26.11. Polygons

A polygon results from the decomposition of a triangle strip, triangle fan or a series of independent triangles. Like points and line segments, polygon rasterization is controlled by several variables in the VkPipelineRasterizationStateCreateInfo structure.

26.11.1. Basic Polygon Rasterization

The first step of polygon rasterization is to determine whether the triangle is back-facing or front-facing. This determination is made based on the sign of the (clipped or unclipped) polygon’s area computed in framebuffer coordinates. One way to compute this area is:

a = - \frac{1}{2} i = 0 \sum n - 1 x_{f}^{i} y_{f}^{i \oplus 1} - x_{f}^{i \oplus 1} y_{f}^{i}

where $x_{f}^{i}$ and $y_{f}^{i}$ are the x and y framebuffer coordinates of the ith vertex of the n-vertex polygon (vertices are numbered starting at zero for the purposes of this computation) and i ⊕ 1 is (i + 1) mod n.

The interpretation of the sign of a is determined by the VkPipelineRasterizationStateCreateInfo::frontFace property of the currently active pipeline. Possible values are:

// Provided by VK_VERSION_1_0
typedef enum VkFrontFace {
    VK_FRONT_FACE_COUNTER_CLOCKWISE = 0,
    VK_FRONT_FACE_CLOCKWISE = 1,
} VkFrontFace;

VK_FRONT_FACE_COUNTER_CLOCKWISE specifies that a triangle with positive area is considered front-facing.
VK_FRONT_FACE_CLOCKWISE specifies that a triangle with negative area is considered front-facing.

Any triangle which is not front-facing is back-facing, including zero-area triangles.

If the bound graphics pipeline state was created with the VK_DYNAMIC_STATE_FRONT_FACE_EXT dynamic state enabled then the front face property is set dynamically by calling:

// Provided by VK_EXT_extended_dynamic_state
void vkCmdSetFrontFaceEXT(
    VkCommandBuffer                             commandBuffer,
    VkFrontFace                                 frontFace);

commandBuffer is the command buffer into which the command will be recorded.
frontFace specifies the front face property to use for drawing.

Valid Usage

The extendedDynamicState feature must be enabled

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
frontFace must be a valid VkFrontFace value
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

Once the orientation of triangles is determined, they are culled according to the VkPipelineRasterizationStateCreateInfo::cullMode property of the currently active pipeline. Possible values are:

// Provided by VK_VERSION_1_0
typedef enum VkCullModeFlagBits {
    VK_CULL_MODE_NONE = 0,
    VK_CULL_MODE_FRONT_BIT = 0x00000001,
    VK_CULL_MODE_BACK_BIT = 0x00000002,
    VK_CULL_MODE_FRONT_AND_BACK = 0x00000003,
} VkCullModeFlagBits;

VK_CULL_MODE_NONE specifies that no triangles are discarded
VK_CULL_MODE_FRONT_BIT specifies that front-facing triangles are discarded
VK_CULL_MODE_BACK_BIT specifies that back-facing triangles are discarded
VK_CULL_MODE_FRONT_AND_BACK specifies that all triangles are discarded.

Following culling, fragments are produced for any triangles which have not been discarded.

// Provided by VK_VERSION_1_0
typedef VkFlags VkCullModeFlags;

VkCullModeFlags is a bitmask type for setting a mask of zero or more VkCullModeFlagBits.

If the bound graphics pipeline state was created with the VK_DYNAMIC_STATE_CULL_MODE_EXT dynamic state enabled then the cull mode is set dynamically by calling:

// Provided by VK_EXT_extended_dynamic_state
void vkCmdSetCullModeEXT(
    VkCommandBuffer                             commandBuffer,
    VkCullModeFlags                             cullMode);

commandBuffer is the command buffer into which the command will be recorded.
cullMode specifies the cull mode property to use for drawing.

Valid Usage

The extendedDynamicState feature must be enabled

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
cullMode must be a valid combination of VkCullModeFlagBits values
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

The rule for determining which fragments are produced by polygon rasterization is called point sampling. The two-dimensional projection obtained by taking the x and y framebuffer coordinates of the polygon’s vertices is formed. Fragments are produced for any fragment area groups of pixels for which any sample points lie inside of this polygon. Coverage bits that correspond to sample points that satisfy the point sampling criteria are 1, other coverage bits are 0. Special treatment is given to a sample whose sample location lies on a polygon edge. In such a case, if two polygons lie on either side of a common edge (with identical endpoints) on which a sample point lies, then exactly one of the polygons must result in a covered sample for that fragment during rasterization. As for the data associated with each fragment produced by rasterizing a polygon, we begin by specifying how these values are produced for fragments in a triangle.

Barycentric coordinates are a set of three numbers, a, b, and c, each in the range [0,1], with a + b + c = 1. These coordinates uniquely specify any point p within the triangle or on the triangle’s boundary as

: p = a p_a + b p_b + c p_c

where p_a, p_b, and p_c are the vertices of the triangle. a, b, and c are determined by:

a = \frac{A ( p p _{b} p _{c} )}{A ( p _{a} p _{b} p _{c} )}, b = \frac{A ( p p _{a} p _{c} )}{A ( p _{a} p _{b} p _{c} )}, c = \frac{A ( p p _{a} p _{b} )}{A ( p _{a} p _{b} p _{c} )},

where A(lmn) denotes the area in framebuffer coordinates of the triangle with vertices l, m, and n.

Denote an associated datum at p_a, p_b, or p_c as f_a, f_b, or f_c, respectively.

The value of an associated datum f for a fragment produced by rasterizing a triangle, whether it be a shader output or the clip w coordinate, must be determined using perspective interpolation:

\frac{f = a f _{a} / w _{a} + b f _{b} / w _{b} + c f _{c} / w _{c}}{a / w _{a} + b / w _{b} + c / w _{c}}

where w_a, w_b, and w_c are the clip w coordinates of p_a, p_b, and p_c, respectively. a, b, and c are the barycentric coordinates of the location at which the data are produced - this must be the location of the fragment center or the location of a sample. When rasterizationSamples is VK_SAMPLE_COUNT_1_BIT, the fragment center must be used.

Depth values for triangles must be determined using linear interpolation:

: z = a z_a + b z_b + c z_c

where z_a, z_b, and z_c are the depth values of p_a, p_b, and p_c, respectively.

When the VK_AMD_shader_explicit_vertex_parameter device extension is enabled the CustomInterpAMD interpolation decoration can also be used with fragment shader inputs which indicate that the decorated inputs can only be accessed by the extended instruction InterpolateAtVertexAMD and allows accessing the value of the inputs for individual vertices of the primitive.

For a polygon with more than three edges, such as are produced by clipping a triangle, a convex combination of the values of the datum at the polygon’s vertices must be used to obtain the value assigned to each fragment produced by the rasterization algorithm. That is, it must be the case that at every fragment

f = i = 1 \sum n a_{i} f_{i}

where n is the number of vertices in the polygon and f_i is the value of f at vertex i. For each i, 0 ≤ a_i ≤ 1 and $\sum_{i = 1}^{n} a_{i} = 1$ . The values of a_i may differ from fragment to fragment, but at vertex i, a_i = 1 and a_j = 0 for j ≠ i.

Note

One algorithm that achieves the required behavior is to triangulate a polygon (without adding any vertices) and then treat each triangle individually as already discussed. A scan-line rasterizer that linearly interpolates data along each edge and then linearly interpolates data across each horizontal span from edge to edge also satisfies the restrictions (in this case, the numerator and denominator of equation [triangle_perspective_interpolation] are iterated independently and a division performed for each fragment).

26.11.2. Polygon Mode

Possible values of the VkPipelineRasterizationStateCreateInfo::polygonMode property of the currently active pipeline, specifying the method of rasterization for polygons, are:

// Provided by VK_VERSION_1_0
typedef enum VkPolygonMode {
    VK_POLYGON_MODE_FILL = 0,
    VK_POLYGON_MODE_LINE = 1,
    VK_POLYGON_MODE_POINT = 2,
  // Provided by VK_NV_fill_rectangle
    VK_POLYGON_MODE_FILL_RECTANGLE_NV = 1000153000,
} VkPolygonMode;

VK_POLYGON_MODE_POINT specifies that polygon vertices are drawn as points.
VK_POLYGON_MODE_LINE specifies that polygon edges are drawn as line segments.
VK_POLYGON_MODE_FILL specifies that polygons are rendered using the polygon rasterization rules in this section.
VK_POLYGON_MODE_FILL_RECTANGLE_NV specifies that polygons are rendered using polygon rasterization rules, modified to consider a sample within the primitive if the sample location is inside the axis-aligned bounding box of the triangle after projection. Note that the barycentric weights used in attribute interpolation can extend outside the range [0,1] when these primitives are shaded. Special treatment is given to a sample position on the boundary edge of the bounding box. In such a case, if two rectangles lie on either side of a common edge (with identical endpoints) on which a sample position lies, then exactly one of the triangles must produce a fragment that covers that sample during rasterization.

Polygons rendered in VK_POLYGON_MODE_FILL_RECTANGLE_NV mode may be clipped by the frustum or by user clip planes. If clipping is applied, the triangle is culled rather than clipped.

Area calculation and facingness are determined for VK_POLYGON_MODE_FILL_RECTANGLE_NV mode using the triangle’s vertices.

These modes affect only the final rasterization of polygons: in particular, a polygon’s vertices are shaded and the polygon is clipped and possibly culled before these modes are applied.

26.11.3. Depth Bias

The depth values of all fragments generated by the rasterization of a polygon can be offset by a single value that is computed for that polygon. This behavior is controlled by the depthBiasEnable, depthBiasConstantFactor, depthBiasClamp, and depthBiasSlopeFactor members of VkPipelineRasterizationStateCreateInfo, or by the corresponding parameters to the vkCmdSetDepthBias command if depth bias state is dynamic.

// Provided by VK_VERSION_1_0
void vkCmdSetDepthBias(
    VkCommandBuffer                             commandBuffer,
    float                                       depthBiasConstantFactor,
    float                                       depthBiasClamp,
    float                                       depthBiasSlopeFactor);

commandBuffer is the command buffer into which the command will be recorded.
depthBiasConstantFactor is a scalar factor controlling the constant depth value added to each fragment.
depthBiasClamp is the maximum (or minimum) depth bias of a fragment.
depthBiasSlopeFactor is a scalar factor applied to a fragment’s slope in depth bias calculations.

If depthBiasEnable is VK_FALSE, no depth bias is applied and the fragment’s depth values are unchanged.

depthBiasSlopeFactor scales the maximum depth slope of the polygon, and depthBiasConstantFactor scales an implementation-dependent constant that relates to the usable resolution of the depth buffer. The resulting values are summed to produce the depth bias value which is then clamped to a minimum or maximum value specified by depthBiasClamp. depthBiasSlopeFactor, depthBiasConstantFactor, and depthBiasClamp can each be positive, negative, or zero.

The maximum depth slope m of a triangle is

m = (\frac{\partial z _{f}}{\partial x _{f}})^{2} + (\frac{\partial z _{f}}{\partial y _{f}})^{2}

where (x_f, y_f, z_f) is a point on the triangle. m may be approximated as

m = max (∣ ∣ ∣ ∣ ∣ \frac{\partial z _{f}}{\partial x _{f}} ∣ ∣ ∣ ∣ ∣, ∣ ∣ ∣ ∣ ∣ \frac{\partial z _{f}}{\partial y _{f}} ∣ ∣ ∣ ∣ ∣) .

The minimum resolvable difference r is an implementation-dependent parameter that depends on the depth buffer representation. It is the smallest difference in framebuffer coordinate z values that is guaranteed to remain distinct throughout polygon rasterization and in the depth buffer. All pairs of fragments generated by the rasterization of two polygons with otherwise identical vertices, but z_f values that differ by r, will have distinct depth values.

For fixed-point depth buffer representations, r is constant throughout the range of the entire depth buffer. For floating-point depth buffers, there is no single minimum resolvable difference. In this case, the minimum resolvable difference for a given polygon is dependent on the maximum exponent, e, in the range of z values spanned by the primitive. If n is the number of bits in the floating-point mantissa, the minimum resolvable difference, r, for the given primitive is defined as

: r = 2^e-n

If a triangle is rasterized using the VK_POLYGON_MODE_FILL_RECTANGLE_NV polygon mode, then this minimum resolvable difference may not be resolvable for samples outside of the triangle, where the depth is extrapolated.

If no depth buffer is present, r is undefined.

The bias value o for a polygon is

o where = d b c l a m p (m \times d e p t h B i a s S l o p e F a c t o r + r \times d e p t h B i a s C o n s t a n t F a c t o r) d b c l a m p (x) = ⎩ ⎪ ⎪ ⎨ ⎪ ⎪ ⎧ x min (x, d e p t h B i a s C l a m p) max (x, d e p t h B i a s C l a m p) d e p t h B i a s C l a m p = 0 or NaN d e p t h B i a s C l a m p > 0 d e p t h B i a s C l a m p < 0

m is computed as described above. If the depth buffer uses a fixed-point representation, m is a function of depth values in the range [0,1], and o is applied to depth values in the same range.

For fixed-point depth buffers, fragment depth values are always limited to the range [0,1] by clamping after depth bias addition is performed. Unless the VK_EXT_depth_range_unrestricted extension is enabled, fragment depth values are clamped even when the depth buffer uses a floating-point representation.

Valid Usage

If the depth bias clamping feature is not enabled, depthBiasClamp must be 0.0

Valid Usage (Implicit)

commandBuffer must be a valid VkCommandBuffer handle
commandBuffer must be in the recording state
The VkCommandPool that commandBuffer was allocated from must support graphics operations

Host Synchronization

Host access to commandBuffer must be externally synchronized
Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

Command Buffer Levels	Render Pass Scope	Supported Queue Types	Pipeline Type
Primary Secondary	Both	Graphics

Command Buffer Levels

Render Pass Scope

Supported Queue Types

Pipeline Type

Primary
Secondary

Both

Graphics

26.11.4. Conservative Rasterization

Polygon rasterization can be made conservative by setting conservativeRasterizationMode to VK_CONSERVATIVE_RASTERIZATION_MODE_OVERESTIMATE_EXT or VK_CONSERVATIVE_RASTERIZATION_MODE_UNDERESTIMATE_EXT in VkPipelineRasterizationConservativeStateCreateInfoEXT. The VkPipelineRasterizationConservativeStateCreateInfoEXT state is set by adding this structure to the pNext chain of a VkPipelineRasterizationStateCreateInfo structure when creating the graphics pipeline. Enabling these modes also affects line and point rasterization if the implementation sets VkPhysicalDeviceConservativeRasterizationPropertiesEXT::conservativePointAndLineRasterization to VK_TRUE.

VkPipelineRasterizationConservativeStateCreateInfoEXT is defined as:

// Provided by VK_EXT_conservative_rasterization
typedef struct VkPipelineRasterizationConservativeStateCreateInfoEXT {
    VkStructureType                                           sType;
    const void*                                               pNext;
    VkPipelineRasterizationConservativeStateCreateFlagsEXT    flags;
    VkConservativeRasterizationModeEXT                        conservativeRasterizationMode;
    float                                                     extraPrimitiveOverestimationSize;
} VkPipelineRasterizationConservativeStateCreateInfoEXT;

sType is the type of this structure.
pNext is NULL or a pointer to a structure extending this structure.
flags is reserved for future use.
conservativeRasterizationMode is the conservative rasterization mode to use.
extraPrimitiveOverestimationSize is the extra size in pixels to increase the generating primitive during conservative rasterization at each of its edges in X and Y equally in screen space beyond the base overestimation specified in VkPhysicalDeviceConservativeRasterizationPropertiesEXT::primitiveOverestimationSize.

Valid Usage

extraPrimitiveOverestimationSize must be in the range of 0.0 to VkPhysicalDeviceConservativeRasterizationPropertiesEXT::maxExtraPrimitiveOverestimationSize inclusive

Valid Usage (Implicit)

sType must be VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_CONSERVATIVE_STATE_CREATE_INFO_EXT
flags must be 0
conservativeRasterizationMode must be a valid VkConservativeRasterizationModeEXT value

// Provided by VK_EXT_conservative_rasterization
typedef VkFlags VkPipelineRasterizationConservativeStateCreateFlagsEXT;

VkPipelineRasterizationConservativeStateCreateFlagsEXT is a bitmask type for setting a mask, but is currently reserved for future use.

Possible values of VkPipelineRasterizationConservativeStateCreateInfoEXT::conservativeRasterizationMode, specifying the conservative rasterization mode are:

// Provided by VK_EXT_conservative_rasterization
typedef enum VkConservativeRasterizationModeEXT {
    VK_CONSERVATIVE_RASTERIZATION_MODE_DISABLED_EXT = 0,
    VK_CONSERVATIVE_RASTERIZATION_MODE_OVERESTIMATE_EXT = 1,
    VK_CONSERVATIVE_RASTERIZATION_MODE_UNDERESTIMATE_EXT = 2,
} VkConservativeRasterizationModeEXT;

VK_CONSERVATIVE_RASTERIZATION_MODE_DISABLED_EXT specifies that conservative rasterization is disabled and rasterization proceeds as normal.
VK_CONSERVATIVE_RASTERIZATION_MODE_OVERESTIMATE_EXT specifies that conservative rasterization is enabled in overestimation mode.
VK_CONSERVATIVE_RASTERIZATION_MODE_UNDERESTIMATE_EXT specifies that conservative rasterization is enabled in underestimation mode.

When overestimate conservative rasterization is enabled, rather than evaluating coverage at individual sample locations, a determination is made of whether any portion of the pixel (including its edges and corners) is covered by the primitive. If any portion of the pixel is covered, then all bits of the coverage mask for the fragment corresponding to that pixel are enabled. If the render pass has a fragment density map attachment and any bit of the coverage mask for the fragment is enabled, then all bits of the coverage mask for the fragment are enabled.

If the implementation supports VkPhysicalDeviceConservativeRasterizationPropertiesEXT::conservativeRasterizationPostDepthCoverage and the PostDepthCoverage execution mode is specified the SampleMask built-in input variable will reflect the coverage after the early per-fragment depth and stencil tests are applied.

For the purposes of evaluating which pixels are covered by the primitive, implementations can increase the size of the primitive by up to VkPhysicalDeviceConservativeRasterizationPropertiesEXT::primitiveOverestimationSize pixels at each of the primitive edges. This may increase the number of fragments generated by this primitive and represents an overestimation of the pixel coverage.

This overestimation size can be increased further by setting the extraPrimitiveOverestimationSize value above 0.0 in steps of VkPhysicalDeviceConservativeRasterizationPropertiesEXT::extraPrimitiveOverestimationSizeGranularity up to and including VkPhysicalDeviceConservativeRasterizationPropertiesEXT::extraPrimitiveOverestimationSize. This will: further increase the number of fragments generated by this primitive.

The actual precision of the overestimation size used for conservative rasterization may vary between implementations and produce results that only approximate the primitiveOverestimationSize and extraPrimitiveOverestimationSizeGranularity properties. Implementations may especially vary these approximations when the render pass has a fragment density map and the fragment area covers multiple pixels.

For triangles if VK_CONSERVATIVE_RASTERIZATION_MODE_OVERESTIMATE_EXT is enabled, fragments will be generated if the primitive area covers any portion of any pixel inside the fragment area, including their edges or corners. The tie-breaking rule described in Basic Polygon Rasterization does not apply during conservative rasterization and coverage is set for all fragments generated from shared edges of polygons. Degenerate triangles that evaluate to zero area after rasterization, even for pixels containing a vertex or edge of the zero-area polygon, will be culled if VkPhysicalDeviceConservativeRasterizationPropertiesEXT::degenerateTrianglesRasterized is VK_FALSE or will generate fragments if degenerateTrianglesRasterized is VK_TRUE. The fragment input values for these degenerate triangles take their attribute and depth values from the provoking vertex. Degenerate triangles are considered backfacing and the application can enable backface culling if desired. Triangles that are zero area before rasterization may be culled regardless.

For lines if VK_CONSERVATIVE_RASTERIZATION_MODE_OVERESTIMATE_EXT is enabled, and the implementation sets VkPhysicalDeviceConservativeRasterizationPropertiesEXT::conservativePointAndLineRasterization to VK_TRUE, fragments will be generated if the line covers any portion of any pixel inside the fragment area, including their edges or corners. Degenerate lines that evaluate to zero length after rasterization will be culled if VkPhysicalDeviceConservativeRasterizationPropertiesEXT::degenerateLinesRasterized is VK_FALSE or will generate fragments if degenerateLinesRasterized is VK_TRUE. The fragments input values for these degenerate lines take their attribute and depth values from the provoking vertex. Lines that are zero length before rasterization may be culled regardless.

For points if VK_CONSERVATIVE_RASTERIZATION_MODE_OVERESTIMATE_EXT is enabled, and the implementation sets VkPhysicalDeviceConservativeRasterizationPropertiesEXT::conservativePointAndLineRasterization to VK_TRUE, fragments will be generated if the point square covers any portion of any pixel inside the fragment area, including their edges or corners.

When underestimate conservative rasterization is enabled, rather than evaluating coverage at individual sample locations, a determination is made of whether all of the pixel (including its edges and corners) is covered by the primitive. If the entire pixel is covered, then a fragment is generated with all bits of its coverage mask corresponding to the pixel enabled, otherwise the pixel is not considered covered even if some portion of the pixel is covered. The fragment is discarded if no pixels inside the fragment area are considered covered. If the render pass has a fragment density map attachment and any pixel inside the fragment area is not considered covered, then the fragment is discarded even if some pixels are considered covered.

For triangles, if VK_CONSERVATIVE_RASTERIZATION_MODE_UNDERESTIMATE_EXT is enabled, fragments will only be generated if any pixel inside the fragment area is fully covered by the generating primitive, including its edges and corners.

For lines, if VK_CONSERVATIVE_RASTERIZATION_MODE_UNDERESTIMATE_EXT is enabled, fragments will be generated if any pixel inside the fragment area, including its edges and corners, are entirely covered by the line.

For points, if VK_CONSERVATIVE_RASTERIZATION_MODE_UNDERESTIMATE_EXT is enabled, fragments will only be generated if the point square covers the entirety of any pixel square inside the fragment area, including its edges or corners.

If the render pass has a fragment density map and VK_CONSERVATIVE_RASTERIZATION_MODE_UNDERESTIMATE_EXT is enabled, fragments will only be generated if the entirety of all pixels inside the fragment area are covered by the generating primitive, line, or point.

For both overestimate and underestimate conservative rasterization modes a fragment has all of its pixel squares fully covered by the generating primitive must set FullyCoveredEXT to VK_TRUE if the implementation enables the VkPhysicalDeviceConservativeRasterizationPropertiesEXT::fullyCoveredFragmentShaderInputVariable feature.

When the use of a shading rate image results in fragments covering multiple pixels, coverage for conservative rasterization is still evaluated on a per-pixel basis and may result in fragments with partial coverage. For fragment shader inputs decorated with FullyCoveredEXT, a fragment is considered fully covered if and only if all pixels in the fragment are fully covered by the generating primitive.