Refactoring of the D3D12 back-end

[slomp]

Here's an overview of the changes:

• removed header bloat (<wrl/client.h>)
• reworked context id assigning
• reworked clock calibration code
• reworked error reporting
• reworked TracyD3D12 macros
• ensure timestamps are collected when context is destroyed

[wolfpld]

@adepke can you take a look at this?

[slomp]

(converting to a draft for now, since I realize I need to do some cleanup)

[slomp]

@nosferalatu Please have a look at as well!

[slomp]

@adepke and @nosferalatu : Ok, I think it's ready for review.

[adepke]

Seems pretty solid, the inclusion of tabs to space conversion makes the diff unreadable so I'm just going off a skim. @slomp what's the rationale behind dropping D3D12NewFrame() and using the sporadic Collect() instead? A goal here is feature parity with the vulkan backend, which used the new frame concept when I originally designed this (may have changed)

[slomp]

the inclusion of tabs to space conversion makes the diff unreadable

I was thinking the same... I'm going to rework the branch and separate the tab-spaces from the rest.

what's the rationale behind dropping D3D12NewFrame() and using the sporadic Collect() instead?

Well, Collect() needs to be called periodically anyway (some time after each NewFrame() call). The rationale is that in many applications, there may be no such thing as a "frame" (compute-only workloads, or headless rendering). By letting the timestamp pool be circular, there's no need for NewFrame() to "reset" the query slots.

A goal here is feature parity with the vulkan backend, which used the new frame concept

Yup, I'll be refactoring the Vulkan back-end too, but that one requires more substantial refactoring overall (it's not thread-safe which prevents it from being used to record command buffers in parallel). I'm almost finished with a Metal back-end, and will be revisiting the Vulkan back-end after that.

[slomp]

@adepke Adding to my reply above: it looks like the Vulkan back-end no longer has a NewFrame() interface.

[adepke]

@slomp Seems reasonable, I like it. Let me know when there's a branch without spaces and I'll take a look when I have some time

[slomp]

@adepke I decided to split the PR into two parts: general refactoring (this one) and NewFrame() elimination (coming up).

It should be much easier to follow this PR now that the tabs-to-spaces changes have been merged.
If you have some time, it might be a good idea to check the changes commit-by-commit; I tried to segregate changes based on context.

[adepke]

@slomp just confirming you've tested this on your end successfully? Also the only thing I'm a little concerned about is the busy wait in the dtor but I'm guessing that's fine. If so lgtm

[slomp]

@adepke Yup, that's just a short-lived "catch-up" when the context is destroyed (prior to that, it was possible to lose profiling events upon context shutdown). The only thing that could cause it to go on for a longer time is if the user is still posting zone events while the context is being destroyed, but that would be a bug on the user.