Fix issues for dx12(2)

[zongdu-arm]

1. Fixed a crash where the OpenExistingHeapFromFileMapping and OpenExistingHeapFromAddress1 methods were missing.
2. Fixed an issue where the SetPrivateDataInterface method was missing during trimming.
3. Fixed a reference count error in the private data interface, causing a replay crash when releasing resource objects.
4. Fixed an issue with ID3D10Blob trimmed capture: the ID3D10Blob creation command released it in tracking state, not written to the trimmed file.
5. Fixed the heap flags with D3D12_HEAP_FLAG_ALLOW_WRITE_WATCH using UseWriteWatch.
6. Updated the clang-format code.

Track in #2843

[zongdu-arm]

@fabian-lunarg , @davidd-lunarg, @locke-lunarg
Could you review this PR?

[locke-lunarg]

Here create a new blob and write this blob. This new blob should be used for CreateRootSignature, but StandardCreateWrite(wrapper); seems to still write the original blob. I feel it should write the new blob for it. Or do both GetBufferPointer() are the same because they have the same blob_value?

[locke-lunarg]

Plus, in Encode_ID3D12Device_CreateRootSignature, it writes all ID3D10Blob data by encoder->EncodeVoidArray(pBlobWithRootSignature, blobLengthInBytes);. It seems to be not necessary to create ID3D10Blob again. Why does it write D3D12SerializeVersionedRootSignature, ID3D10Blob_GetBufferSize, ID3D10Blob_GetBufferPointer? Or is it just for recording the complete process, not for correctly executing the program?

[zongdu-arm]

Here create a new blob and write this blob. This new blob should be used for CreateRootSignature, but StandardCreateWrite(wrapper); seems to still write the original blob. I feel it should write the new blob for it. Or do both GetBufferPointer() are the same because they have the same blob_value?

I believe the blob data is the same at runtime and does not need to be updated.

[zongdu-arm]

Plus, in Encode_ID3D12Device_CreateRootSignature, it writes all ID3D10Blob data by encoder->EncodeVoidArray(pBlobWithRootSignature, blobLengthInBytes);. It seems to be not necessary to create ID3D10Blob again. Why does it write D3D12SerializeVersionedRootSignature, ID3D10Blob_GetBufferSize, ID3D10Blob_GetBufferPointer? Or is it just for recording the complete process, not for correctly executing the program?

I'm not sure if the captured blob data on replaying different GPU is the same. However, I haven't adapted the replay code yet.

[locke-lunarg]

Replay works fine on different GPUs, so this looks good.

My question is: since the capture already writes all the ID3D10Blob data, omitting the creation calls shouldn't hurt. Why do we explicitly record D3D12SerializeVersionedRootSignature, ID3D10Blob_GetBufferSize, and ID3D10Blob_GetBufferPointer?

Does it affect replay correctness, or is it to record the full process to help users identify which ID3D10Blob is being used? I’m happy to keep it for completeness, just want to understand the intent. Thanks!

[locke-lunarg]

The error in continuous-integration/jenkins/pr-merge is

35>C:\j\workspace\gfxr-pipelines_gfxr_PR-2811\gfxreconstruct\framework\decode\dx12_replay_consumer_base.cpp(2463,78): error C2220: the following warning is treated as an error [C:\j\workspace\gfxr-pipelines_gfxr_PR-2811\gfxreconstruct\build32\framework\decode\gfxrecon_decode.vcxproj]
35>C:\j\workspace\gfxr-pipelines_gfxr_PR-2811\gfxreconstruct\framework\decode\dx12_replay_consumer_base.cpp(2463,78): warning C4293: '>>': shift count negative or too big, undefined behavior [C:\j\workspace\gfxr-pipelines_gfxr_PR-2811\gfxreconstruct\build32\framework\decode\gfxrecon_decode.vcxproj]

HANDLE handle = CreateFileMapping(INVALID_HANDLE_VALUE,
                                  nullptr,
                                  PAGE_READWRITE,
                      >>>>>>>>    static_cast<DWORD>(info.RegionSize >> 32),
                                  static_cast<DWORD>(info.RegionSize & 0xFFFFFFFF),
                                  TEXT("OpenExistingHeapFromFileMapping"));