No, but a product by one company isn't a standard by any stretch of the imagination before some accepted organization makes it such.
I wasn't talking whether it's good or bad. It all comes down to engineering trade offs.
Ah yes, "double" FP32.
It shines whenever there are lots of read-modify-write operations, such as particle blending, it simply destroys everything in 3D Mark Fire Strike for example.
"Fast" has two attributes - latency and bandwidth. CPUs are extremely latency-sensitive and in fact use caches more for latency reduction than for bandwidth amplification (although maybe AVX has been rebalancing that equation somewhat). GPUs on the other hand are bandwidth machines and can shrug off latency to a large degree (except for some specific latency-sensitive operations as @OlegSH pointed out). And so they use caches primarily for bandwidth enhancement. You cannot buy latency, but you can always buy more bandwidth, which makes the tradeoff for cache on GPUs a different ballgame than for CPUs. Navi 2x certainly made some bold choices in that tradeoff space, but the benefits aren't as slam-dunk as, for example, the hilariously awesome Zen L3$.
Yep, there are all kinds of prefetching and speculation hardware in Zen that helps getting all the necessary data in advance in the large L3 to decrease latency rather than make it worse.
Which leads into the following question -- does the RDNA2 L3 include any hooks for programmer-controlled data pinning, or is it purely transparent? FWIW I find cache data pinning a little awkward because it breaks abstraction. Scratchpads are a different beast because they are meant to be explicitly managed, but caches are supposed to be programmer-transparent.
Well, data pinning is likely a requirement for good perf with producer-consumer pipelines in compute or machine larning. The graphics pipeline is itself a producer-consumer pipeline and all the data goes thru L2 at least, but I don't know how data residency is controlled there, certainly this is not exposed in APIs.
Ugh should we tell him?
If you have something useful to contribute maybe it’s better to do it directly instead of trying to create a grandiose mystique about yourself first.
That's the best part.
Linux driver had indicated that each entry in the GPU page table can be individually marked as LLC No Alloc. RDNA 2 ISA documentation indicated that image resource (texture) descriptors use 2 bits to specify LLC allocation policy, which apparently supports either a resource-wide override value, or using the LLC No Alloc setting in the page table entry.
In the PCGamer interview, Scott Herkelman said that devs are looking into further optimizations to be made around Infinity Cache, and that they're getting (I think he said) "very interesting results".
You can optimize for cache size by managing your dataset - making it fit into the cache size. If that wasn't clear to the usual and predictable suspects.
