GPU: D3D12: remove NewFrame() API + drop unresolved queries when under pressure

[slomp]

This PR removes the need for calling NewFrame() periodically.
(it also addresses and fixes #1294)

Some applications may run "headless" or may use the GPU for compute-only purposes, and do not have the concept of a frame boundary. Timestamp queries are now produced and collected in circular fashion.

In addition, the code is now resilient to situations where timestamp queries are reserved/dispensed, but the enclosing command list is never submitted to the GPU for execution. Such cases will flag warning messages and will "stall" progress, forcing "unresolvable" timestamps queries to be dropped. This also tricky covers corner cases where timestamp query ids are dispensed in one order, but the command lists are sent to the GPU queue in opposing order, or when an operation takes unusually long to complete with respect to everything else.

As such, queue signals are no longer required, nor useful: even with Signal/Wait, there are no guarantees that once the queue sets the signal value, all queries up to that value have indeed completed, since queries could be sent/executed out of the order. in which they were generated, or may not have been submitted to the queue yet (or ever).

---

The only scenario where ambiguity can still happen is as follows:

1. a command buffer (CB1) is recorded, but not yet executed
2. time goes by, and several command buffers are subsequently recorded and executed
3. Collect() ends up giving up on CB1's "reserved" queries
4. CB1 is finally sent to the queue and executed
5. but around the same instant, another command buffer is recorded, claiming query ids that clash with CB1
6. the GPU will resolve the CB1 timestamps, and write to the timestamp heap
7. Collect() is not going to be able to disambiguate the timestamp

While technically possible, it is quite a contrived case. There does not seem to be a proper solution for the case above without some amount of costly query tracking along with some CPU-GPU synchronization on top of it. The current implementation is also prone to the same "bad-timing" problem anyway.

[Lectem]

If the only writes done to m_previousCheckpoint are done behind the collect lock, you can make this a relaxed load

[Lectem]

explicit load, be it seq_cst or relaxed I'd rather see the fact it's an atomic op

[Lectem]

explicit memory ordering for the load please

[Lectem]

Please use m_previousCheckpoint.load(acquire) if you need to see latest value and rely on the fact timestamp is now free

[Lectem]

Do you want the latest value here, or the latest one you saw from the while loop?
Otherwise explicit memory ordering for the load please.

[slomp]

Latest value, because the loop could have been exited due to the timeout condition being reached.

[Lectem]

Please use m_previousCheckpoint.load(acquire) if you need to see latest value and rely on the fact timestamp is now free

[slomp]

@Lectem I addressed most of your remarks.

For the atomic memory ordering, I relaxed the two "hottest" paths: NextQueryId() (which gets called concurrently by multiple-threads), and RetireTicket() (which only gets called by whichever thread managed to acquire the lock to run Collect(), but the atomic store is called repeatedly therein).

I could relax a bit the other paths (Drain() and Wait()) but they are only ever called during "panic" situations, which should never or very rarely happen in a well-behaved program. If they do happen, I'd say the client has much bigger fish to fry other than worrying about the impact of strong atomics in cache synchronization. And if we were to relax, we'd need acq_rel semantics, which is not too far apart in terms of overhead from the clean/default sec_cst ordering semantics.

[Lectem]

Could we use a constant here and in CreateD3D12Context ?