{"id":9582,"date":"2024-05-28T10:00:00","date_gmt":"2024-05-28T17:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/directx\/?p=9582"},"modified":"2024-05-28T11:17:02","modified_gmt":"2024-05-28T18:17:02","slug":"dxc-1-8-2405-available","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/directx\/dxc-1-8-2405-available\/","title":{"rendered":"DXC 1.8.2405 Available Now, Including HLSL 202x"},"content":{"rendered":"<p>The HLSL team is excited to announce DXC 1.8.2405 which is a packed release! In addition to a healthy assortment of bug fixes and quality of life improvements, this release features two things we\u2019re really excited about. First this is the first DXC release to contain Windows binaries built with Clang alongside the binaries built with MSVC, and it includes the first feature planned for the next HLSL language version, which is ready for user testing. We will dig into a lot more details later in this post, but two quick <strong>TL;DRs<\/strong> are:<\/p>\n<ul>\n<li>Using the Clang to build DXC binaries showed a modest performance improvement for compiling shaders. These binaries should work as drop-in replacements instead of the MSVC-built ones and might give you a cheap win to speed up compile times.<\/li>\n<li>To prepare your HLSL codebase for the new language features you can add these arguments to your shader compiler options <span style=\"font-family: 'courier new', courier, monospace;\">-HV 202x -Wconversion -Wdouble-promotion -Whlsl-legacy-literal<\/span>. These options will enable the new language behavior and emit warnings for type conversions which could indicate important changes in behavior or precision.<\/li>\n<\/ul>\n<p>As with all HLSL language versions, once our new language version is feature complete, stabilized, and has a proper name, we will make this the default language version in DXC (it already is for Clang). We don\u2019t have a timeline for that yet, but likely sometime in 2025 or 2026.<\/p>\n<p>Note for our Xbox developers: the new language feature will be coming soon to a GDK near you, so keep reading.<\/p>\n<h2>Clang-built DXC<\/h2>\n<p>The DXC 1.8.2405 release is the first release that we\u2019re shipping Windows binaries built with Clang alongside the existing binaries built with MSVC. We\u2019ve included these binaries in addition to the MSVC binaries so that users can try them with minimal risk and revert back to the MSVC binaries if they encounter problems specific to the Clang-built binaries (although we don\u2019t anticipate any).<\/p>\n<p>You might be asking yourself: why should you care what compiler we built DXC with? Or what even is this Clang thing?<\/p>\n<p>Clang is the LLVM compiler for C-like languages. DXC is a fork of an older version of LLVM &amp; Clang.<\/p>\n<p>This matters because different compilers optimize different patterns in code more effectively. LLVM\u2019s optimizer has always been pretty good at optimizing LLVM\u2019s codebase, which seems both silly to say and obvious once you think about it. For this reason, LLVM\u2019s optimizer is pretty good at optimizing DXC\u2019s code, which inherits most of its code and design from LLVM &amp; Clang.<a href=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/DXCisLLVM.png\"><img decoding=\"async\" class=\"size-medium wp-image-9591 aligncenter\" src=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/DXCisLLVM-300x292.png\" alt=\"Image DXCisLLVM\" width=\"300\" height=\"292\" srcset=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/DXCisLLVM-300x292.png 300w, https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/DXCisLLVM-24x24.png 24w, https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/DXCisLLVM-48x48.png 48w, https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/DXCisLLVM.png 720w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/a><\/p>\n<p>We spent some time this year looking for easy wins to speed up compile time for users of DXC and building our binaries with Clang seemed like a good candidate.<\/p>\n<p>In practice we tested compile time against a proprietary suite of real-world shaders and saw promising results. Comparing compile times with Clang-built DXC against MSVC-built DXC we saw on average around 10% reduction in compile time with the Clang-built DXC, and as much as 20-30% in some cases.<\/p>\n<p>This probably makes you wonder why we\u2019re still shipping the MSVC-built binaries. In 88% of our tests Clang-built DXC compiled shaders as quickly or faster than MSVC-built DXC (with some small margin of test error). In about 4.5% of cases the Clang-built binaries were significantly slower than the DXC-built ones (10-25%). In the remaining 7.5% the slowdown was less than 10%, but still measurable.<\/p>\n<p>As we continue to look for ways to speed up compile time for shaders we\u2019re really interested for your feedback. Particularly we\u2019d like to know if the Clang-built DXC helps or hurts your shader compile time, and if you encounter any unexpected difficulties in using the Clang-built binaries. Please try the Clang-built DXC binaries in your project and let us know how it goes!<\/p>\n<h2>Evolving HLSL<\/h2>\n<p>As many of you are probably aware, DXC is based on LLVM &amp; Clang from version 3.7, which is getting older by the second. Because of how HLSL &amp; DXIL support were introduced to the forked LLVM code we don\u2019t have a reasonable path to update to a newer version of LLVM, and we\u2019re stuck with an aging and degrading codebase. To address this, we\u2019ve been working on a new initiative to implement HLSL support in Clang.<\/p>\n<p>One of the challenges we\u2019re facing with this effort is that HLSL has no formal specification\u00a0 (yet!). For programming languages, a formal specification (like the ISO C and C++ specifications) details the language grammar, and semantic rules that describe program behavior. Not having a specification for HLSL makes it extremely challenging to implement a new HLSL compiler with the same behavior as the existing one. Any developer who has been writing HLSL for a while may recognize the problems porting code between FXC and DXC. Because of the continued lack of formal specification, a similar set of problems may occur with the transition from DXC to Clang.<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ThreeCompilers.png\"><img decoding=\"async\" class=\"size-medium wp-image-9593 aligncenter\" src=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ThreeCompilers-300x197.png\" alt=\"Image ThreeCompilers\" width=\"300\" height=\"197\" srcset=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ThreeCompilers-300x197.png 300w, https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ThreeCompilers-1024x672.png 1024w, https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ThreeCompilers-768x504.png 768w, https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ThreeCompilers.png 1080w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/a><\/p>\n<p>To help limit this impact we\u2019re doing two things:<\/p>\n<ul>\n<li>We\u2019re writing a language specification for <a href=\"https:\/\/microsoft.github.io\/hlsl-specs\/specs\/hlsl.pdf\">HLSL<\/a>.<\/li>\n<li>We\u2019re <a href=\"https:\/\/github.com\/microsoft\/hlsl-specs\/blob\/main\/proposals\/0020-hlsl-202x-202y.md\">defining HLSL 202x<\/a> as a common language mode between DXC and Clang<\/li>\n<\/ul>\n<p>HLSL 202x is the working name for the next iteration of the HLSL programming language. HLSL 202x is planned as a narrowly scoped set of language changes to focus on making HLSL more consistent and regular. Our goal with HLSL 202x is to bridge the gap between DXC and Clang\u2019s HLSL support.<\/p>\n<p>We still don\u2019t expect that DXC and Clang will match 100% even under HLSL 202x, but we\u2019re trying to <a href=\"https:\/\/clang.llvm.org\/docs\/HLSL\/ExpectedDifferences.html\">catalog differences<\/a> and keep them to a minimum. Even beyond the expected differences, compilers are software made by mere mortals, so they have bugs too. Clang is no exception (even if we wish it would be). By allowing users to phase the changes into their codebases we hope to minimize the disruptions this transition will cause.<\/p>\n<p>Clang will support only HLSL 202x initially and will have full support for 202x and later versions of HLSL. Some earlier versions of HLSL may be implemented in the future if there is user demand and resourcing allow, however some HLSL features from DXC and FXC we never plan to implement or match in Clang, so earlier language versions will always behave differently in Clang from DXC.<\/p>\n<div>\n<div>\n<p>We\u2019re planning and developing <a href=\"https:\/\/github.com\/microsoft\/hlsl-specs\/blob\/main\/proposals\/0020-hlsl-202x-202y.md\">HLSL 202x and its successor HLSL 202y<\/a> in parallel. We don\u2019t yet have anything to share about HLSL 202y, but we\u2019re planning it as a feature packed release to bring a bunch of powerful new language features to HLSL only in Clang. This may include features like constant expressions (C++ <span style=\"font-family: 'courier new', courier, monospace;\">constexpr<\/span>), variable declaration type inference (C++ <span style=\"font-family: 'courier new', courier, monospace;\">auto<\/span>), variadic templates, lambdas, and more!<\/p>\n<h2>Conforming Literals<\/h2>\n<p>The DXC 1.8.2405 release includes the new HLSL 202x Conforming Literals feature. You can enable HLSL 202x in your codebase by adding the <span style=\"font-family: 'courier new', courier, monospace;\">-HV 202x<\/span> flag to your compiler arguments.<\/p>\n<p>The technical proposal for the feature is available in the <a href=\"https:\/\/github.com\/microsoft\/hlsl-specs\/blob\/main\/proposals\/0017-conforming-literals.md\">hlsl-specs repository on GitHub<\/a>. That document contains a lot of information including links to the PRs with the precise wording for the draft language specification.<\/p>\n<h3><span style=\"font-size: 24pt; text-align: var(--bs-body-text-align);\">Literal Types<\/span><\/h3>\n<\/div>\n<div>To fully understand this new feature, you need to understand a bit about the older <span style=\"font-family: 'courier new', courier, monospace;\">literal<\/span> types in HLSL. HLSL literal types are a special internal data type in HLSL. As such you cannot write the type name <span style=\"font-family: 'courier new', courier, monospace;\">literal int<\/span> or <span style=\"font-family: 'courier new', courier, monospace;\">literal float<\/span> which prevents declaring variables, parameters, functions or anything else in the language with that type. Even though you can\u2019t write the type name, you\u2019ve probably seen error messages mention <span style=\"font-family: 'courier new', courier, monospace;\">literal int<\/span> or <span style=\"font-family: 'courier new', courier, monospace;\">literal float<\/span>. The literal types are the type of <em>un-suffixed<\/em> literal integer and floating-point values (e.g. <span style=\"font-family: 'courier new', courier, monospace;\">1<\/span>, <span style=\"font-family: 'courier new', courier, monospace;\">42<\/span>, <span style=\"font-family: 'courier new', courier, monospace;\">0.5<\/span>, <span style=\"font-family: 'courier new', courier, monospace;\">3.1415<\/span>). Literal values with a suffix, have always been typed to match the suffix (e.g. <span style=\"font-family: 'courier new', courier, monospace;\">1u<\/span> is a <span style=\"font-family: 'courier new', courier, monospace;\">uint<\/span>, <span style=\"font-family: 'courier new', courier, monospace;\">0.5f<\/span> is a <span style=\"font-family: 'courier new', courier, monospace;\">float<\/span>).\nThe literal types are treated as unsized data types, and the compiler tries to keep them at the highest level of precision. In the case of floating-point values this means constant expressions on literal types are generally evaluated as double-precision, even if the result is lowered to a 32 or 16-bit value. For integers, literals are treated as 64-bit signed integers. In both cases literal types are the lowest ranked data type in conversions. Meaning when used in expressions with data of non-literal types, the literals will convert to the non-literal type without emitting a conversion warning.<\/p>\n<h3><span style=\"font-size: 24pt;\">If it ain\u2019t broke\u2026<\/span><\/h3>\n<p>All this sounds cool right? So why are we changing it?\nThere are a couple reasons why we are changing this behavior. First is that it isn\u2019t strictly compatible with C++ templates (which we added in HLSL 2021), nor is it compatible with other C++ features that infer types (like <span style=\"font-family: 'courier new', courier, monospace;\">auto<\/span>). For example, if you have the expression <span style=\"font-family: 'courier new', courier, monospace;\">auto v = 1.0;<\/span>, what is the type of <span style=\"font-family: 'courier new', courier, monospace;\">v<\/span>? With literal types we actually don&#8217;t know.<a href=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ConformingLiterals.png\"><img decoding=\"async\" class=\"size-medium wp-image-9587 aligncenter\" src=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ConformingLiterals-219x300.png\" alt=\"Image ConformingLiterals\" width=\"219\" height=\"300\" srcset=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ConformingLiterals-219x300.png 219w, https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/ConformingLiterals.png 667w\" sizes=\"(max-width: 219px) 100vw, 219px\" \/><\/a>\nThis incompatibility with type deduction has been causing subtle bugs in shaders forever, but they\u2019re exacerbated by the introduction of templates to HLSL 2021 (see related issues <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/3973\">#3973<\/a>, <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/5493\">#5493<\/a>, &amp; <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/6147\">#6147<\/a>).<\/p>\n<p>The second big motivation for this change is that the existing behavior is <em>really<\/em> complicated and not well understood, specified, or documented. That means that we\u2019re unlikely to be able to make Clang match DXC\u2019s behavior even if we tried. Standardizing on a simpler behavior meets our goal of reducing hurdles for users transitioning code between DXC and Clang.\nIf you\u2019re still not fully convinced, the literal behavior has been tangentially related to a host of other issues in DXC. Here are a few more related issues: <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/4683\">#4683<\/a>, <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/5961\">#5961<\/a>, <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/6410\">#6410<\/a>, <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/6565\">#6565<\/a>, and <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/6566\">#6566<\/a>.<\/p>\n<p>Because of all these issues and more, we decided to do something different, simpler, and more like C\/C++ and other shading languages.<\/p>\n<h3><span style=\"font-size: 24pt;\">HLSL 202x Literals<\/span><\/h3>\n<p>In HLSL 202x, un-suffixed integer literals behave exactly like C\/C++. Base-10 un-suffixed literals are <span style=\"font-family: 'courier new', courier, monospace;\">int<\/span> unless the value is too large to be represented in which case they are <span style=\"font-family: 'courier new', courier, monospace;\">int64_t<\/span>. Un-suffixed hexadecimal and octal literals are signed unless their most significant bit is set in which case they are unsigned, and they will be 32-bit if the specified value fits, otherwise they will extend to 64-bits.\nHLSL 202x continues to support the suffixes <span style=\"font-family: 'courier new', courier, monospace;\">u<\/span>, <span style=\"font-family: 'courier new', courier, monospace;\">l<\/span>, <span style=\"font-family: 'courier new', courier, monospace;\">ll<\/span> for integer literals. The suffix <span style=\"font-family: 'courier new', courier, monospace;\">u<\/span> marks a type as <span style=\"font-family: 'courier new', courier, monospace;\">uint<\/span>. The suffix <span style=\"font-family: 'courier new', courier, monospace;\">l<\/span> or <span style=\"font-family: 'courier new', courier, monospace;\">ll<\/span> mark it as <span style=\"font-family: 'courier new', courier, monospace;\">int64_t<\/span>, and when paired with the <span style=\"font-family: 'courier new', courier, monospace;\">u<\/span> suffix the type becomes <span style=\"font-family: 'courier new', courier, monospace;\">uint64_t<\/span>.<\/p>\n<p>There is no suffix to specify integer types smaller than <span style=\"font-family: 'courier new', courier, monospace;\">int<\/span> in C or HLSL. When explicit sizing is desired for smaller types a cast is the recommended approach (e.g., <span style=\"font-family: 'courier new', courier, monospace;\">(int16_t)4<\/span>).<\/p>\n<p>Un-suffixed floating-point literals are of type <span style=\"font-family: 'courier new', courier, monospace;\">float<\/span>. This is different from C\/C++ where they would be <span style=\"font-family: 'courier new', courier, monospace;\">double<\/span>. This is the same behavior as other common shading languages and more closely aligns to HLSL as implemented by FXC. This divergence was chosen in part because it closely aligns with FXC and other shading languages, but also because it seemed like the right approach since <span style=\"font-family: 'courier new', courier, monospace;\">double<\/span>\u00a0values often have significant performance impact on GPU code and require an optional feature bit in DirectX.<\/p>\n<p>HLSL 202x continues to support the suffixes <span style=\"font-family: 'courier new', courier, monospace;\">h<\/span>, <span style=\"font-family: 'courier new', courier, monospace;\">f<\/span> and <span style=\"font-family: 'courier new', courier, monospace;\">l<\/span> for floating-point literals. The <span style=\"font-family: 'courier new', courier, monospace;\">h<\/span> suffix marks the type as <span style=\"font-family: 'courier new', courier, monospace;\">half<\/span> (which may be 16 or 32-bit based on <span style=\"font-family: 'courier new', courier, monospace;\">-enable-16bit-types<\/span>), the <span style=\"font-family: 'courier new', courier, monospace;\">f<\/span> suffix marks the type as <span style=\"font-family: 'courier new', courier, monospace;\">float<\/span>, and the <span style=\"font-family: 'courier new', courier, monospace;\">l<\/span> suffix marks the type as <span style=\"font-family: 'courier new', courier, monospace;\">double<\/span>.\nThere is no suffix to specify <span style=\"font-family: 'courier new', courier, monospace;\">min16float<\/span>. When using a literal in an expression with <span style=\"font-family: 'courier new', courier, monospace;\">min16float<\/span>\u00a0values you need to be mindful to use explicit casts where appropriate.<\/p>\n<h3><span style=\"font-size: 24pt;\">Estimating Impact: Integer Signedness<\/span><\/h3>\n<p>The changes in this language feature impact the fundamental types of HLSL, and how types are implicitly resolved. As a result, this change can cause behavior changes.<\/p>\n<p>To estimate the impact of this change we created a modified build of DXC that enabled this feature in all HLSL language modes. We then ran that build through our proprietary internal test suite and had our partners at Google who maintain DXC\u2019s SPIR-V support do the same. Google reported no issues in their SPIR-V test suite. We encountered a few, which I\u2019ll discuss.\nOur internal test suite is comprised of captured frames from shipping games and demo content.\u00a0 Our test suite is large enough to be useful, but not extensive enough to be fully representative of all use cases.<\/p>\n<p>Most of the shaders in our test suite had no visible difference in the final frame rendering. Many of the shaders compiled to bit-for-bit identical byte code with this change.<\/p>\n<p>All the cases where significant rendering differences appeared were caused by changes in integer literal handling. Specifically, DXC always treats integer literals as signed integers, and the C\/C++ rules treat hexadecimal literals as unsigned if the most significant bit is set. This produces significantly different results for bit shifts. To illustrate this difference, consider the following code:<\/p>\n<pre class=\"prettyprint language-c\"><code class=\"language-c\">export int Fn(int inInt) {\r\n  return (inInt &amp; 0xffff0000) &gt;&gt; 16);\r\n}<\/code><\/pre>\n<p>Following HLSL 2021 rules, <span style=\"font-family: 'courier new', courier, monospace;\">0xffff0000<\/span> is a signed integer. This means that all operations in this code are arithmetic. The result of the <span style=\"font-family: 'courier new', courier, monospace;\">&amp;<\/span> operation produces a signed integer. If the most significant bit of that integer is <span style=\"font-family: 'courier new', courier, monospace;\">1<\/span> the shift will fill the new high order bits with <span style=\"font-family: 'courier new', courier, monospace;\">1<\/span>.<\/p>\n<p>Following HLSL 202x rules, consistent with C\/C+, <span style=\"font-family: 'courier new', courier, monospace;\">0xffff0000<\/span> is an unsigned integer. This results in <span style=\"font-family: 'courier new', courier, monospace;\">inInt<\/span> being promoted to an unsigned integer, the <span style=\"font-family: 'courier new', courier, monospace;\">&amp;<\/span> operation produces an unsigned result, and the shift is a logical shift filling the top bits with <span style=\"font-family: 'courier new', courier, monospace;\">0<\/span>\u00a0regardless of the value. This also matches the effective behavior in FXC because hexadecimal literals are unsigned.\nTo help users identify cases in their code where this may cause issues we\u2019ve added a new disabled-by-default warning to warn on literal values that will change signed-ness under the new language rules. You can enable this warning on your shaders by passing the <span style=\"font-family: 'courier new', courier, monospace;\">-Whlsl-legacy-literal<\/span>\u00a0flag.\nThis new warning works the same under HLSL 202x and earlier versions, and it notifies the user of all cases where a literal integer changes signed-ness based on the language version.<\/p>\n<h3><span style=\"font-size: 24pt;\">Estimating Impact: Floating-point Precision<\/span><\/h3>\n<p>Our team has also speculated but not observed two other situations related to floating point literals that may cause problems in your codebases.<\/p>\n<p>One issue is that legacy literals in DXC compute constant evaluated math at a higher precision than under the new rules. This may cause rounding errors due to intermediate values being computed at lower precisions in HLSL 202x. To identify these cases, the <span style=\"font-family: 'courier new', courier, monospace;\">-Wconversion<\/span>\u00a0warnings are your best tool. They report any implicit conversion that results in a loss in precision.<\/p>\n<p>The other issue we believe is possible is where math intended to be 16-bit math is implicitly promoted to 32-bit math. This likely won\u2019t cause correctness problems but could cause runtime performance regressions for shaders that rely on <span style=\"font-family: 'courier new', courier, monospace;\">min16float<\/span> or <span style=\"font-family: 'courier new', courier, monospace;\">half<\/span> data types. To identify these cases, we\u2019ve back-ported the (poorly named) Clang warning <span style=\"font-family: 'courier new', courier, monospace;\">-Wdouble-promotion<\/span>\u00a0which reports any implicit floating-point promotions (conversions that don\u2019t lose precision).<\/p>\n<p>These warnings will behave differently under HLSL 202x and earlier versions. In HLSL 2021 and earlier literal types are excluded from all conversion warnings (promotion or truncation) because of their unsized nature. For this reason, in HLSL 2021 and earlier these warnings will only trigger on conversions of non-literal types. For HLSL 202x, the warnings will trigger for all conversions. It may be useful to run code through DXC with the warnings enabled for HLSL 2021 then run it again with 202x and compare the output. Regardless of which language version you are building your shaders with, being warning-clean for <span style=\"font-family: 'courier new', courier, monospace;\">-Wconversion<\/span> and <span style=\"font-family: 'courier new', courier, monospace;\">-Wdouble-promotion<\/span>\u00a0is recommended to avoid unintended behavior and performance pitfalls.<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/FixMyWarnings.png\"><img decoding=\"async\" class=\"size-medium wp-image-9588 aligncenter\" src=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/FixMyWarnings-238x300.png\" alt=\"Image FixMyWarnings\" width=\"238\" height=\"300\" srcset=\"https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/FixMyWarnings-238x300.png 238w, https:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2024\/05\/FixMyWarnings.png 544w\" sizes=\"(max-width: 238px) 100vw, 238px\" \/><\/a><\/p>\n<h2>Call to Action<\/h2>\n<p>This is the point in the post where I ask (or beg) you to try this feature and our new Clang-built DXC binaries in your shader codebases and give us feedback. We\u2019ve done a lot of work to estimate the impact that these changes will have on existing HLSL, but we aren\u2019t omniscient so the only way we\u2019ll know how this impacts your codebase is if you try it and tell us how it goes.<\/p>\n<p>If you encounter a bug in the DXC implementation, please file an issue against <a href=\"https:\/\/github.com\/microsoft\/DirectXShaderCompiler\/issues\/new\/choose\">DXC on GitHub<\/a>.<\/p>\n<p>If you have other feedback about the language change positive or negative, we\u2019d love to hear it. We collected public feedback on <a href=\"https:\/\/github.com\/microsoft\/hlsl-specs\/issues\/211\">this GitHub issue<\/a>, and we\u2019ll continue to track and respond to feedback even though the issue is closed.<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>The HLSL team is excited to announce DXC 1.8.2405 which is a packed release! In addition to a healthy assortment of bug fixes and quality of life improvements, this release features two things we\u2019re really excited about. First this is the first DXC release to contain Windows binaries built with Clang alongside the binaries built [&hellip;]<\/p>\n","protected":false},"author":78222,"featured_media":9589,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1203],"tags":[],"class_list":["post-9582","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hlsl"],"acf":[],"blog_post_summary":"<p>The HLSL team is excited to announce DXC 1.8.2405 which is a packed release! In addition to a healthy assortment of bug fixes and quality of life improvements, this release features two things we\u2019re really excited about. First this is the first DXC release to contain Windows binaries built with Clang alongside the binaries built [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/posts\/9582","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\/78222"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/comments?post=9582"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/posts\/9582\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/media\/9589"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/media?parent=9582"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/categories?post=9582"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/tags?post=9582"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}