Pretty basic stuff. However it specifically mentions "may not be closed for significant periods of time". I am just wondering what kind of effect this has if the CPU reads the data again soon (CPU->CPU NT writes & reads in the same frame like Ashes of Singularity).
If the data being written is expected to be re-read soon after, is it desirable to skip the cache hierarchy that allows it to be re-read quickly?
Does this mean that BAD THINGS HAPPEN if I have two SMT threads running on the same core and one is doing WC writes and the other is just running normal code (lots of writes & reads). Do my write combine buffers get partially flushed all the time?
If one thread is writing non-combining data to the same 64-byte region as a write-combining buffer, it would appear that this counts as an event that will close an ongoing write-combining buffer. That event does seem to apply to all write-combining buffers in the core.
Per AMD's documentation, there are a number of events that can prompt a flush. It would seem that AMD's implementation tries to be conservative in the face of any ambiguities or long-latency events that could interact with an a WC buffer of uncertain state.
Intel's line-fill buffer method for write combining seems like it could be more aggressive, or it has not chosen to state flush conditions as exhaustively.
There are fewer events that would flush all WC buffers, but it seems like sufficient cache traffic could evict individual lines more frequently.
Since not every Intel core does well with write-combining or actually handles NT stores non-temporally, it may not be consistently worse/better.
Same question for code that has function calls (function parameters written to stack). Do I need to avoid function calls (other writes) while writing WC data? I have always done my WC writes in tight inner loops (no function calls), but I am just wondering whether not doing it is a problem for Ryzen.
I think it comes down to whether there is an event that would prompt other pipeline flushes or if traffic subject to more stringent ordering/visibility rules might clash with WC data or potentially any data co-resident on its cache line. POP or PUSH don't appear on the table.
The document seems like it's missing a lot of sections, relative to the 15h guide.
Also, I think it might be incorrect on the load buffer size and FP scheduler size, compared to earlier Zen presentations.
The data cache seems to be interesting:
The L1 DC is a banked structure. Two loads per cycle can access the DC if they are to different banks. The DC banks that are accessed by a load are determined by address bits 5:2, the size of the load, and the DC way. DC way is determined using the linear-address-based utag/way-predictor (see section below).
Rather than a static 16 bank scheme for determining conflicts, there's a dynamic component in the DC way determination built into the way prediction/microtag array.
There's an undisclosed hash function based on the virtual address access history and dynamic behaviors related to aliasing or hash conflicts.
