{"id":3789,"date":"2021-04-20T09:49:48","date_gmt":"2021-04-20T16:49:48","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/directx\/?p=3789"},"modified":"2021-04-21T03:25:22","modified_gmt":"2021-04-21T10:25:22","slug":"hlsl-shader-model-6-6","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/directx\/hlsl-shader-model-6-6\/","title":{"rendered":"Announcing HLSL Shader Model 6.6"},"content":{"rendered":"
<\/div>\n
After months of development and refinement in collaboration with hardware vendors and software developers, we are pleased to announce the availability of Shader Model 6.6! Shader Model 6.6 empowers shader authors with new tools for greater flexibility to make existing shaders faster<\/span><\/div>\n

and more versatile as well as to devise all new techniques.<\/span><\/p>\n

To give Shader Model 6.6 a try, developers will need a few tools. To compile shaders using Shader Model 6.6, you need the latest DirectX Shader Compiler release<\/a>. To run those compiled shaders, you’ll need the DirectX 12 Agility SDK<\/a> and the corresponding graphics driver<\/a>.<\/p>\n

New Atomic Operations<\/strong><\/span><\/h2>\n
Shader Model 6.6 introduces 64-bit integer and limited bitwise floating-point atomic operations by overloading the Interlocked*\u00a0functions and methods used on group shared memory, raw buffer, and typed (RWBuffer\/RWTexture)\u00a0resources.<\/div>\n

 <\/p>\n

See the Shader Model 6.6 Atomic Operations specification<\/a> for more details.<\/div>\n

 <\/p>\n

Dynamic Resources<\/strong><\/span><\/h2>\n
Shader Model 6.6 introduces the ability to create resources from descriptors by directly indexing into the CBV_SRV_UAV (resource view) heap or the Sampler heap. No root signature descriptor table mapping is required for this resource creation method, but new global root signature flags are used to indicate the use of each heap from the shader.<\/div>\n

 <\/p>\n

A short example:<\/div>\n
<\/div>\n
<\/div>\n
Texture2D<float4> myTexture = ResourceDescriptorHeap[texIdx];\r\n<\/code>float4\u00a0result\u00a0=\u00a0myTexture.Sample(SamplerDescriptorHeap[sampIdx],\u00a0coord);<\/code><\/pre>\n
 <\/p>\n
See the Dynamic Resources<\/span>\u00a0<\/span>specification<\/a> for more details.<\/div>\n
 <\/p>\n
Helper Lane Detection<\/strong><\/span><\/h2>\n
IsHelperLane() is a new intrinsic introduced in Shader Model 6.6 that returns true if the current lane is a helper lane.\u00a0\u00a0Helper lanes are nonvisible pixels that are executed only to provide quad neighbor information to gradient operations. They can arise by being discarded or by sharing a quad with rendered pixels, but not contributing to any primitive. In a pixel shader, IsHelperLane() returns false for all visible pixels. In all other shader stages, it returns false for all lanes since they have no helper lanes.<\/div>\n
 <\/p>\n
IsHelperLane() is supported in previous shader models via emulation.<\/div>\n
 <\/p>\n
When using wave intrinsics in pixel shaders, you can end up with undefined results for certain values in helper lanes because helper lanes do not participate.\u00a0 This can lead to problems like undefined screen-space derivatives or unintentional infinite loops (hangs) when depending on results from wave intrinsics.\u00a0 In the past, we attempted to guard against this problem by disallowing potentially problematic operations from being dependent on the result of wave intrinsics. However, this could be too strict, or even miss some dependencies. This guard has been changed into a warning, but leaves the shader author without an explicit way to write safe code in that area of interaction. IsHelperLane provides a way for the shader to explicitly vary behavior on helper lanes to guard against potential problems. For instance, by explicitly excluding helper lanes from entering a loop which depends on a wave intrinsic for its exit condition.<\/div>\n
 <\/p>\n
Compute Derivatives<\/strong><\/span><\/h2>\n
Shader Model 6.6 introduces support for quad-based derivative operations to compute and optionally mesh and amplification shaders.\u00a0\u00a0We define how threads are mapped to 2×2 quads in these stages and specifically which operations are newly available.<\/div>\n
 <\/p>\n
See the Derivative Operations in Compute, Mesh and Amplification Shaders specification<\/a> for more details.<\/div>\n
 <\/p>\n
Pack and Unpack Intrinsics<\/strong><\/span><\/h2>\n
A new set of intrinsics are being added to HLSL for processing of packed 8-bit data such as colors. New packed datatype are also added to HLSL’s front end to symbolize a vector of packed 8-bit values.<\/div>\n
 <\/p>\n
See the Shader Model 6.6 Pack\/Unpack Intrinsics specification<\/a> for more details.<\/div>\n
 <\/p>\n
WaveSize<\/strong><\/span><\/h2>\n
Shader Model 6.6 introduces a new option that allows the shader author to specify a wave size that the compute shader is compatible with. Such shaders will only be run with the specified wave size.<\/div>\n
 <\/p>\n
See the Wave Size specification<\/a> for more details.<\/div>\n
 <\/p>\n
Raytracing Payload Access Qualifiers<\/strong><\/span><\/h2>\n
Shader models 6.6 adds payload access qualifiers (PAQs) to the ray payload structure. PAQs are annotations which describe the read and write semantics of a payload field, that is, which shader stages read or write a given field. The added semantic information can help implementations reduce register pressure and can avoid spilling of payload state to memory. This incentivizes the use of the narrowest-possible qualifiers for each payload field.<\/div>\n
 <\/p>\n
See the new Payload Access Qualifiers section<\/a> of the raytracing specification for more details.<\/div>\n","protected":false},"excerpt":{"rendered":"
After months of development and refinement in collaboration with hardware vendors and software developers, we are pleased to announce the availability of Shader Model 6.6! Shader Model 6.6 empowers shader authors with new tools for greater flexibility to make existing shaders faster and more versatile as well as to devise all new techniques. To give […]<\/p>\n","protected":false},"author":45155,"featured_media":12651,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3789","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-directx"],"acf":[],"blog_post_summary":"
After months of development and refinement in collaboration with hardware vendors and software developers, we are pleased to announce the availability of Shader Model 6.6! Shader Model 6.6 empowers shader authors with new tools for greater flexibility to make existing shaders faster and more versatile as well as to devise all new techniques. To give […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/posts\/3789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/users\/45155"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/comments?post=3789"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/posts\/3789\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/media\/12651"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/media?parent=3789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/categories?post=3789"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/tags?post=3789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}