Bumps [cryptography](https://github.com/pyca/cryptography) from 41.0.6
to 42.0.4.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/pyca/cryptography/blob/main/CHANGELOG.rst">cryptography's
changelog</a>.</em></p>
<blockquote>
<p>42.0.4 - 2024-02-20</p>
<pre><code>
* Fixed a null-pointer-dereference and segfault that could occur when
creating
a PKCS#12 bundle. Credit to **Alexander-Programming** for reporting the
issue. **CVE-2024-26130**
* Fixed ASN.1 encoding for PKCS7/SMIME signed messages. The fields
``SMIMECapabilities``
and ``SignatureAlgorithmIdentifier`` should now be correctly encoded
according to the
definitions in :rfc:`2633` :rfc:`3370`.
<p>.. _v42-0-3:</p>
<p>42.0.3 - 2024-02-15
</code></pre></p>
<ul>
<li>Fixed an initialization issue that caused key loading failures for
some
users.</li>
</ul>
<p>.. _v42-0-2:</p>
<p>42.0.2 - 2024-01-30</p>
<pre><code>
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL
3.2.1.
* Fixed an issue that prevented the use of Python buffer protocol
objects in
``sign`` and ``verify`` methods on asymmetric keys.
* Fixed an issue with incorrect keyword-argument naming with
``EllipticCurvePrivateKey``
:meth:`~cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePrivateKey.exchange`,
``X25519PrivateKey``
:meth:`~cryptography.hazmat.primitives.asymmetric.x25519.X25519PrivateKey.exchange`,
``X448PrivateKey``
:meth:`~cryptography.hazmat.primitives.asymmetric.x448.X448PrivateKey.exchange`,
and ``DHPrivateKey``
:meth:`~cryptography.hazmat.primitives.asymmetric.dh.DHPrivateKey.exchange`.
<p>.. _v42-0-1:</p>
<p>42.0.1 - 2024-01-24
</code></pre></p>
<ul>
<li>Fixed an issue with incorrect keyword-argument naming with
<code>EllipticCurvePrivateKey</code>
:meth:<code>~cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePrivateKey.sign</code>.</li>
<li>Resolved compatibility issue with loading certain RSA public keys in
:func:<code>~cryptography.hazmat.primitives.serialization.load_pem_public_key</code>.</li>
</ul>
<p>.. _v42-0-0:</p>
<p>42.0.0 - 2024-01-22</p>
<pre><code>
</tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="fe18470f7d"><code>fe18470</code></a>
Bump for 42.0.4 release (<a
href="https://redirect.github.com/pyca/cryptography/issues/10445">#10445</a>)</li>
<li><a
href="aaa2dd06ed"><code>aaa2dd0</code></a>
Fix ASN.1 issues in PKCS#7 and S/MIME signing (<a
href="https://redirect.github.com/pyca/cryptography/issues/10373">#10373</a>)
(<a
href="https://redirect.github.com/pyca/cryptography/issues/10442">#10442</a>)</li>
<li><a
href="7a4d012991"><code>7a4d012</code></a>
Fixes <a
href="https://redirect.github.com/pyca/cryptography/issues/10422">#10422</a>
-- don't crash when a PKCS#12 key and cert don't match (<a
href="https://redirect.github.com/pyca/cryptography/issues/10423">#10423</a>)
...</li>
<li><a
href="df314bb182"><code>df314bb</code></a>
backport actions m1 switch to 42.0.x (<a
href="https://redirect.github.com/pyca/cryptography/issues/10415">#10415</a>)</li>
<li><a
href="c49a7a5271"><code>c49a7a5</code></a>
changelog and version bump for 42.0.3 (<a
href="https://redirect.github.com/pyca/cryptography/issues/10396">#10396</a>)</li>
<li><a
href="396bcf64c5"><code>396bcf6</code></a>
fix provider loading take two (<a
href="https://redirect.github.com/pyca/cryptography/issues/10390">#10390</a>)
(<a
href="https://redirect.github.com/pyca/cryptography/issues/10395">#10395</a>)</li>
<li><a
href="0e0e46f5f7"><code>0e0e46f</code></a>
backport: initialize openssl's legacy provider in rust (<a
href="https://redirect.github.com/pyca/cryptography/issues/10323">#10323</a>)
(<a
href="https://redirect.github.com/pyca/cryptography/issues/10333">#10333</a>)</li>
<li><a
href="2202123b50"><code>2202123</code></a>
changelog and version bump 42.0.2 (<a
href="https://redirect.github.com/pyca/cryptography/issues/10268">#10268</a>)</li>
<li><a
href="f7032bdd40"><code>f7032bd</code></a>
bump openssl in CI (<a
href="https://redirect.github.com/pyca/cryptography/issues/10298">#10298</a>)
(<a
href="https://redirect.github.com/pyca/cryptography/issues/10299">#10299</a>)</li>
<li><a
href="002e886f16"><code>002e886</code></a>
Fixes <a
href="https://redirect.github.com/pyca/cryptography/issues/10294">#10294</a>
-- correct accidental change to exchange kwarg (<a
href="https://redirect.github.com/pyca/cryptography/issues/10295">#10295</a>)
(<a
href="https://redirect.github.com/pyca/cryptography/issues/10296">#10296</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/pyca/cryptography/compare/41.0.6...42.0.4">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/microsoft/DirectXShaderCompiler/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Struct lowering is slightly different for push constants, and we didn't
checked if the field was static or not.
In SPIR-V, when a field is const static, we either replace all loads by
a the immediate (when usage is `Struct::field`), or create a global
variable we initialize to the correct value and reference instead. The
field is then ignored from the struct definition, and this variable is
used.
This hasn't changed with this commit, I just made push-buffers use the
same logic.
Fixed#6006
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
The `ComputeSampleTest` is verifying `Sample` and
`CalculateLevelOfDetail` intrinsics calls on a texture in compute, mesh
and amplification shaders. The test is set up in a way that the reported
LOD values should be increasing as the X and Y coordinates increase.
However, since the test results are stored in quad z-order, and it is
perfectly valid for the X-derivative-LOD to decrease when going from
top-right to bottom-left pixel in a quad because in this case the X
coordinate decreases. Therefore, the test needs verify the LOD values
are increasing everywhere except for the bottom-left quad pixel (every
output with `index % 4 == 2`).
Previously, the test coincidentally worked for compute shaders because
it uses thread group of 336 and the 1/336 difference between 0 and pixel
1's X coordinate is not sufficient to change LODs. For mesh, however,
since the limit of a thread group size is 128, the validation is done
using the smaller range of 116, and 1/116 is sufficient to change LOD
for pixel 1.
This PR also fixes a couple of mismatched thread group dimensions in
`VerifySampleResults`.
The shader code for this test is at
[ShaderOpArith.xml](130877392c/tools/clang/unittests/HLSLExec/ShaderOpArith.xml (L454))
line 454.
Fixes#4788Fixes#6181
---------
Co-authored-by: Greg Roth <grroth@microsoft.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
The MSDN spec is not very clear regarding input parameter aliasing, BUT
DXIL & MS agrees (See #3737) using the same semantic annotation twice
should be disallowed.
DXIL currently disallows it for most, and due to a bug, allows some
compute related semantics to be aliased.
SPIR-V did allowed aliasing, but it was a implemented as a hack causing
typing issues if the type changed between the 2 parameters using the
same semantic annotation.
To align more closely with DXIL, and the "spec", we are now disallowing
all semantic attribute reuse for input parameters.
Fixes#3737
Signed-off-by: Nathan Gauër <brioche@google.com>
`castToType` can return null after emitting an error, so
`doShortCircuitedConditionalOperator` should exit when true or false
branches failed to compile, otherwise it will crash inside
`createStore`.
This can be reproduced with in the main branch with a ternary operator
selectin a `SamplerState`, which should only emit an error but crashes
with a SIGSEGV:
https://godbolt.org/z/j9EGGxWTh
`$ dxc -spirv -E PSMain -T ps_6_0 -HV 2021`
```hlsl
SamplerState SamplerA;
SamplerState SamplerB;
Texture2D Tex;
bool WhichSampler;
float4 SampleTex() {
return Tex.Sample(WhichSampler ? SamplerA : SamplerB, (float2)0);
}
float4 PSMain() : SV_Target0 {
return SampleTex();
}
```
The check was done in the DXIL backend, and not in the SPIR-V backend.
This causes the issue to be ignored on the SPIR-V side. Moved the check
earlier to SEMA so a single check works for both backends.
I had to split the existing HLSL check as it doesn't support having 2
run lines (AFAIK).
Fixes#3739
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
The `Load` function's optional `Offset` parameter must be an immediate
value to match the behavior of the DXIL backend. Further, the existing
logic in the SPIR-V backend to evaluate it as a variable offset
generated invalid SPIR-V that violated the
`VUID-StandaloneSpirv-Offset-04663` rule:
> Image operand Offset must only be used with OpImage*Gather
instructions
The logic for processing the argument as a variable value has been
removed and replaced with an error message that matches DXIL's.
Note that `handleOffsetInMethodCall` is left unmodified because it is
also used to process HLSL `.Gather()` calls, which are lowered to
`OpImageGather` SPIR-V instructions and can therefore accept non-const
`Offset`s as image operands.
It would be nice to move this error message earlier in execution and
share between backends, but I found that to be non-trivial to implement.
Since both backends already have all of the logic to identify whether
the function call has an offset argument, at which index, and evaluate
its const-ness, I think this is the most straightforward implementation
at this point.
Fixes#6149
Because the layout rule was not propagated from the initializer object
to the OpCompositeExtract when decomposing a struct in the
InitListHandler, it could result in cases where the result types were
mismatched.
Fixes#5625
Even when a function's return type is void, it is still valid to return
an void expression, and that expression should be evaluated before the
function is terminated to match DXIL behavior.
Although I don't see this explicitly mentioned in HLSL documention, the
cpp reference states (abridged):
> `return expression;`
> Evaluates the expression, terminates the current function and returns
the result of the expression to the caller, after implicit conversion to
the function return type.
> In a function returning void, the return statement with expression can
be used, if the expression type is void.
Fixes#5464
This workflow has been around long enough to stop treating it as the
"experimental" workflow and just update the documentation to use it.
We've gotten numerous issues lately related to problems building, so
this will hopefully help.
Fixes: #5762
Related: #6151
This commit adds a new optional -ftime-trace-granularity option that is
already implemented in llvm-project. This change is a surgical port of
an existing feature from the upstream llvm-project repo into the DXC
codebase.
The following commits in the llvm-project repo were copied and followed
for this change. Clean cherry picks were not possible due to the
differences in repos like change of file locations and other dependant
changes made in the repo.
*** Adds the granularity configuration setting ***
'Time profiler: small fixes and optimizations'
Commit: 26536728591d5fdac373ef535ae122b873f73292
*** Wires up the commandline option -ftime-trace-granularity to the
TraceProfiler code ***
'[Support] Fix -ftime-trace-granularity option'
Commit: 4fdcabf259c4ab94654e6cd5d95d0e0313159c70
Fixes#6372
---------
Signed-off-by: Cooper Partin <coopp@ntdev.microsoft.com>
Co-authored-by: Cooper Partin <coopp@ntdev.microsoft.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
**Fix for**
Fix issue under:
https://github.com/microsoft/DirectXShaderCompiler/issues/2955
For structure type, when `nointerpolation` is decorated on a structure
input, this flag should be broadcast to its members.
PR (https://github.com/microsoft/DirectXShaderCompiler/pull/6018) also
helps to resolve an issue when SPIRV backend generated variable has no
AST type.
**Test**
Please see same case under:
https://github.com/microsoft/DirectXShaderCompiler/pull/6018
Besides, example as below should be invalid as the first parameter of
function `compute` should has only one spirv-type.
If its parameter type declaration has been expanded to an array
implicitly, it should not accept other interpolated inputs as its input
parameter.
```
struct S {
float4 a : COLOR;
};
float compute(float4 a) {
return GetAttributeAtVertex(a, 2)[0];
}
float4 main(nointerpolation S s, float4 b : COLOR2) : SV_TARGET
//float4 main(nointerpolation S s) : SV_TARGET
{
return float4(0, 0, compute(b), compute(s.a));
//return float4(0, 0, 0, compute(s.a));
}
```
I added an error report point in this commit and gets following reports:
```
1.hlsl:12:31: error: Current function could only use noninterpolated variable as input.
return float4(0, 0, compute(b), compute(s.a));
^
fatal error: generated SPIR-V is invalid: OpFunctionCall Argument <id> '37[%param_var_a_0]'s type does not match Function <id> '24[%_ptr_Function_v4float]'s parameter type.
%45 = OpFunctionCall %float %compute %param_var_a_0
note: please file a bug report on https://github.com/Microsoft/DirectXShaderCompiler/issues with source code if possible
```
Any idea to let the error only reported before spirv validator?
**Ref**:
https://github.com/microsoft/DirectXShaderCompiler/issues/2955https://github.com/microsoft/DirectXShaderCompiler/pull/6018
---------
Co-authored-by: Zhou, Shaochi(AMD) <shaozhou@amd.com>
Co-authored-by: Natalie Chouinard <sudonatalie@google.com>
No longer normalizing paths that are baked into `DIFile` (as well as the
debug module file list and PDB source info).
The previous path normalization change introduced a bug in debug info
where instead of generating a normal `DILexicalBlock`, we generated a
`DILexicalBlockFile`. This was because the file paths written into the
`DIFile`'s were normalized, but the file list in `SourceManager` was
left unchanged. `CGDebugInfo::setLocation` checks whether the `DIFile`
path matches the current file, and due to the normalization differences,
assume the file has changes and compensates by generating a new
`DILexicalBlockFile` on the scope stack.
An alternative to this PR would be to change `CGDebugInfo::setLocation`
to normalize the `SourceManager` path before comparing; however, there
may be other unknown code paths that could have similar issues. Another
alternative is to normalize the path list in `SourceManager`; however,
this has other ramifications and require many more drastic changes.
By no longer normalizing the paths written into `DIFile`, we revert to
the behaviour where the paths in `DIFile` come directly from
`SourceManager`, so there is no chance of a mismatch. Furthermore, by
avoiding normalizing any paths that are written to PDBs, we do not bake
any potential normalization bugs into any test content.
ReportHit was limited to only accepting variable references as the hit
attribute in ReportHit calls. This change removes that limitation to
allow arbitrary Expr types.
I've also added a TODO follow up for some existing logic that I've kept
the same but want to further investigate.
Fixes#5709
This change adds NodeRecordType alignment field to RDAT to make it
possible to validate pointer and stride alignment in the runtime.
This includes a change to DXIL metadata to preserve the record alignment
without requiring recovery by looking for GetNodeRecordPtr.
Fixes#6270
Issue #6367 identifies a problem with the auto-dxilver logic based on -T
target option in %dxc part when using FileCheckerTest.cpp.
This change adds a manual %dxilver 1.8 to two tests that run into this
problem, as a workaround.
AllocateRayQuery returns an int, but it's not really an int: it's a
handle to the query. Thus, it's not sensible for the PIX debugging
instrumentation to attempt to write it out to the debug-data-UAV. The
previous code did an explicit check against the type of the value to be
written, but if that value is actually a phi itself, then that check
would fail. So now we recursively run through the phi values looking to
see if any of its antecedents are a phi, and if so, refuse to send its
value to the UAV.
This PR adds execution testing to wave range size attributes, on top of
the already existing WaveSizeTest HLK test.
It implements the necessary coverage of the new wave range size
attribute, as described in the hlsl-specs here:
https://github.com/microsoft/hlsl-specs/blob/main/proposals/0013-wave-size-range.md#execution-testingFixes#6347
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This change exposes the clang 3.7 `-fdiagnostics-format=` flag in DXC with supported values `clang`, `msvc`, `mdvc-fallback`, and `vi`.
This option allows having DXC output diagnostic messages in string formats that are recognized natively by Visual Studio.
Resolves#6160 & #1811, both of which had been closed as not planned.
ShaderCompatInfo identifies compatibility for functions that could be
called from an entry point.
Currently, this checking detects compatibility problems between entry
points and internal function calls that the validator otherwise misses.
This change adds a check for ShaderCompatInfo, recursing into called
functions looking for a source of conflict when not compatible with the
current entry point properties.
Errors are emitted for the entry point and at one source of each type of
conflict that ShaderCompatInfo detects.
A function is considered the source of a conflict when it has the
conflict but none of the functions called from this function have this
conflict.
Removed early exit for ShaderFlags validation when module is a library,
since these flags should be validated for libraries, and running
CollectShaderFlagsForModule fills in the ShaderCompatInfo data we need
for validation.
Also fixed tests for illegal barrier and derivative use, as well as
replacing the ignored MaxOutputRecords with the correct MaxRecords
attribute.
Fixes#6292.
The SPIR-V backend uses `ValidateAttributeIntArg` for the
`vk::ext_builtin_input` and `vk::ext_builtin_output` attrs, as well as
some others. It is convenient for users to be able to pass in an enum
value to this attribute, for example:
```
enum class BuiltIn {
HelperInvocation = 23
};
[[vk::ext_builtin_input(BuiltIn::HelperInvocation)]]
static const bool gl_HelperInvocation;
```
Fixes#6337
This PR fixes several issues in the `ExecutionTest::DerivativesTest`:
- Use 1D quad order only when writing 1D derivative results. 2D results
are expected in standard 2D form.
- Use separate derivatives verification function for SM 6.6 compute,
mesh and amplification shaders. In these cases the quad layout is well
defined, and so are the expected results. There is only one possible
result for `ddx_fine`/`ddy_fine` and two for `ddx_coarse`/`ddy_coarse`.
This is different from pixel shaders where the quad layout can vary
quite a bit, and so do the expected results.
- Change the expected values to match results for texture pixel `(2,2)`
- Adjust mesh shader dispatch dimensions to make sure `X * Y * Z <= 128`
- Use same logic (shared function) to calculate center pixel for
compute, mesh and amplification shaders
- To enable easier debugging in the future, I have added a function that
writes out the derivatives results (under `DERIVATIVES_TEST_DEBUG`
define)
Verified on:
- Latest Microsoft Basic Render Driver that supports shader model 6.8
(CS, MS, AS). Tested on x64 and arm64.
- NVIDIA GeForce RTX 2080 Ti (CS only)
- AMD Radeon RX 6900 XT (CS only)
Fixes#4787
Previously, only `SamplerState` was allowed to be used as the sampler
type with `[[vk::combinedImageSampler]]`, but I don't see any reason
that `SamplerComparisonState` shouldn't also be permitted. Since
`SamplerComparisonState` is a sampler state plus a comparison state,
`SampleCmp` calls are translated to an `OpImageSampleDrefImplicitLod`
(sampling with depth-comparison) in Vulkan SPIR-V, which does accept an
`OpTypeSampledImage` (combined image sampler) as an operand.
Fixes#4696
Fix crash if a RayGen shader contains a `while(true)` loop, caused by
dominator tree construction not ignoring `nullptr` successor AST nodes
which occur in this case.
Also add regression test case.
Fixes#5035.
Co-authored-by: Jannik Silvanus <jasilvanus@users.noreply.github.com>
It turns out that in the prior validator version, if a subobject
required DXR 1.1, the DXR 1.1 flag would be set on each function in RDAT
output, as well as the global flags. It didn't appear this was the case
through a D3DReflect test because that goes through disassembly to
assembly step, where subobjects are lost because they aren't in the llvm
IR. The previous change assumed this was not the case when the
subobjects were removed, but this removal occurs after the RDATWriter
constructor, which does the full RDAT serialization since size if
required right away.
This restores the detection code and hooks it into
DxilModule::ComputeShaderCompatInfo when validator version is in range
[1.5, 1.7]. DXR 1.1 was introduced in 1.5, and we no longer tag every
function as requiring DXR 1.1 based on subobjects in 1.8.
At the moment, there is no way to CHECK the subobject RDAT in D3DReflect
because they get stripped from the module (even reflection and debug
modules) before serialization, and the test path for D3DReflect goes
through a disassemble/re-assemble step between the prior stage and the
D3DReflect stage.
Fixes#6321 (really).
Fix barrier allowed ops and flags by shader kind
New barrier operations lacked validation and for RDAT info: had
incorrect min target and shader stage flags.
- Identify barrier DXIL operations with new `is_barrier` in `hctdb.py`
and generated `OP::IsDxilOpBarrier`.
- Identify when a barrier op requires shader stage with group
(compute-like stage), or when it requires node memory.
- Add new `OptFeatureInfo_RequiresGroup` to identify function only
compatible with a shader stage with a visible group for access to
groupshared memory or use of group sync.
- Translate to original `BarrierMode` when compatible; adds
`BarrierMode::Invalid` to identify invalid cases.
- Account for `DXIL::MemoryTypeFlags::AllMemory` being allowed and
auto-masked by driver.
- Properly set min shader model and compatible shader stage flags.
- Validate barrier for shader stage.
- Added new barriers to counters which were missing.
Adressing parts of: #6256 and #6292Fixes#6266
There was a typo in dxcpdbutils where the normalized file path wasn't
actually being used. This change fixes that and adds thorough testing
for the DxcPdbUtils path normalization. Also fixed another case where
`/dir/my_file` gets normalized to `.\\dir\my_file`.
In validator version 1.7 and below, the RaytracingTier1_1 module flag
was set on every function if any StateObjectConfig subobject had the
AllowStateObjectAdditions flag set. This was incorrect, as the
requirement is validated in the runtime based on the use of the
subobject instead. Subobjects are removed from the module and placed in
RDAT during container serialization, so the requirement would be lost
when recomputing the flags in validation. This didn't break validation
because flag validation was completely disabled for libraries!
This change fixes this problem, and allows DxilValidation to validate
ShaderFlags because they will no longer mismatch due to this issue.
Running CollectShaderFlagsForModule is also necessary for collecting
per-function shader flags which will be used by call graph validation in
a subsequent change, so enabling flag validation unblocks that as well.
Fixes#6321
In EmitGetNodeRecordPtrAndUpdateUsers, the type will be mutated. And the
GEP user of the RecordPtr will be merged at same time. This make things
complex because the GEP index need to be updated since type is mutated.
To make things easier, merge the GepUse after mutate type.
Fixes#6223
DXIL operations should use is_const=True for constant arguments. This
allows for convenience methods to retrieve the constant value, and could
(should, but currently doesn't) result in validation that the argument
is constant.
`BarrierByNodeRecordHandle` SemanticFlags argument must be constant.
`MetadataIdx` for both `createNodeOutputHandle` and
`CreateNodeInputRecordHandle` must be constant.
PIX's code for parsing debug data operates at the module level. When the
same global is referenced by multiple functions in a module, that
variable is referred to by multiple dbg.value/dbg.declare statements,
and those are mapped (by the PIX passes) to multiple fake allocas using
its usual scheme. This code was written before libraries were a thing,
and wasn't expecting this duplication. A little more attention to the
variable's scope fixes the issue.
Also, the changed code's original "return false" broke the whole process
of discovering variables with the results that PIX's shader debugger
locals window was completely empty. Makes more sense to ignore the one
variable and keep going.
The spir-v backend currently treats each bitfield as a separate member
in the spir-v type when processing an initializer list. This commit
changes that so that it matches the behaviour of the DXIL backend.
In particular, if `{bf1, bf2}` is used to initialize a struct with two
bitfield, then `bf1` and bf2` will be merged into a single field when
constructing the struct.
Fixes#5688
Made the debug info type for the `this` argument a reference type.
`DxilRewriteOutputArgDebugInfo` then turns the reference type into a
value type to preserve the value mapping when the alloca that `this`
points to becomes registers.
When SV_CULLPRIMITIVE is the output of a mesh shader, its type is
changed to uint because a Vulkan interface variable cannot be a bool.
However, we do not change the access to the variable to match.
This change will modify stores to the variable to be stores of a uint
instead of a bool.
Fixes#6042
This change switches from instrumentation per instruction to
instrumentation per basic block. Furthermore, not every instruction in a
basic block needs to write debug data to the output UAV- it's enough to
know that the basic block was entered, as long as the calling
application can figure out what instructions were in that block. To
support that knowledge, the pass now emits a text "precis" of each basic
block.
Also, the previous branchless UAV bounds enforcement was replaced with
something similar that emits fewer instructions at the cost of a larger
UAV. This tradeoff is WELL worth it.
Additionally, the debug pass used to add extra blocks in order to
solidify the arguments to phi instructions. This work was unnecessary,
and added a lot of complexity to the resulting instrumented shader. The
debugger application is only interested in the value of the phi itself
and the actual value produced via the actual preceding edge.
Full details are in the comments in the code.
This change reduces driver-side compilation overhead from "overnight" to
2 minutes on a 160k-instruction shader.
This change adds a ground truth path normalization helper:
- All slashes are changed to system native (`\` for windows, `/` for all
others)
- All repeated slashes are removed (except for leading slashes, so
windows UNC paths are not broken)
- All relative paths (including the main file, and ones that begin with
`..`) are prepended with `./` or `.\` if not already
The path normalization is applied in the following places:
- Main file path in dxcompilerobj
- Paths passed into IDxcIncludeHandler
- Paths written into all DI* debug info
- Paths written into dx.content metadata and Pdb SourceInfo
- All paths loaded up by DxcPdbUtils
The reason for this change is to make it easier to tools authors to
implement recompilation (example: PIX edit-and-continue). When the paths
in all the above places match, the files can be matched with a normal
string equal instead of having to path normalization.
dependabot[bot]
Nathan Gauër
Helena Kotas
Natalie Chouinard
Xiang Li
Michael Anttila
Laura Hermanns
Chris B
Cooper Partin
Chow
Adam Yang
Tex Riddell
Jeff Noyle
Joshua Batista
Jonas Meyer
Cassandra Beckley
Jannik Silvanus
Steven Perron