DXMT: initialize async compile ready flags

[moreaki]

Summary

Initialize DXMT asynchronous shader and pipeline compile ready_ flags to false.

The affected compile tasks publish a std::atomic_bool ready_ that callers use before consuming shader or pipeline state. A newly-created task should always begin as not-ready and only become ready when the worker has populated the result.

Validation

• git diff --check
• Cherry-picked on top of DXMT: add LLVM build compatibility fixes #748 and built with kmk VBoxDxMt on macOS/Arm using LLVM 15.0.7.

Closes #755.

Signed-off-by: Roberto Nibali rnibali@gmail.com

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: moreaki
• rnibali@gmail.com (@moreaki)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[moreaki]

DXMT v0.80 audit update:

Updating the vendored DXMT tree to v0.80 would not address this. DXMT v0.80 and current DXMT main still declare these async compile std::atomic_bool ready_ members without constructor initialization in the shader/pipeline task objects.

I opened the equivalent upstream DXMT issue and PR:

• Uninitialized async compile ready flags 3Shain/dxmt#186
• fix(d3d11): initialize async compile ready flags 3Shain/dxmt#187

[moreaki]

Re-audit update:

I withdrew the upstream DXMT issue/PR I had opened for this (3Shain/dxmt#186 / 3Shain/dxmt#187). DXMT upstream declares cpp_std=c++20, and under that build mode default-constructed std::atomic_bool is initialized to false. So this is not a well-supported upstream DXMT defect as submitted.

For VirtualBox, this PR should be evaluated only if the vendored/kBuild integration actually compiles this DXMT snapshot under older atomic initialization semantics or if there is a concrete VirtualBox-local crash/repro. It should not be presented as a current upstream DXMT fix.