Yeah for comparison, but no need to concern yourself with AMD's CGN, because it is not the future of AMD.
Going back to the original claim, it was that transparent multi-GPU was stopped solely by the lack of unified memory, and that--given what we know now--there's nothing technically blocking this.
My response was that unified memory wasn't the only obstacle, and what we currently know has architectural edges that remain a problem.
And.. if they designed their new architecture so that (lets say) that the L2 can be unified with as many GPU/cores as connected (Or at some other hierarchy), where is the problem you describe..?
If the answer to the "what we know now" question is that something new fixes these concerns with unknown methods, then fine. However, one of the elements I was discussing was that there is a set of hardware elements in the graphics pipeline that do not engage with the L2--either in part or fully. Whatever the L2 does wouldn't matter to them, so there's some other assumption built into this scenario not being discussed.
Aside from that, just saying an L2 can be unified with an unbounded number of clients, no timeline, and without a clear description of where they are physically is too fuzzy to know where the bottlenecks or problems may be.
The most probable improvements for various elements like silicon process, packaging tech, and architecture have some limits in what we can expect in terms of scaling in the near and mid-term.
I do not consider AMD's "chiplet" design as MCM.
If you mean like AMD's Rome. It's an MCM in the standard sense.
The involvement of passive and then active interposers in some of the future proposals can be called 2.5D or 3D integration at least by vendors in order to differentiate them from the more standard MCMs that are placed on more conventional substrates, but aside from the marketing distinction they are modules with more than one chip.
It is a sandwich design & not necessarily an edge-to-edge design (ie wafer sitting next to wafer.) So the interconnects are not necessarily edge to edge, but.... per layer (or plane).
I don't know if I follow what you mean by edge to edge in this case.
Again, two GPU don't have to be side-by-side, but stacked on top of each other... sharing the same pinouts with fabric in middle... (otherwise two mirror GPU would have to be made to have exact pinout alignment.)
Thermal problems and wire routing are an immediate concern. If you mean literally stacked one on top of the other, massive thermal issues and significant limitations in terms of how to get enough wires to the internals for power and data. These chips already have a massive pinout, and whatever is in the stack gets pierced by very large and very disruptive TSVs.
If the GPUs are just on opposite sides of a PCB, it's a significantly more complicated thermal and mounting environment, plus a much more complex layering and wire congestion problem getting enough signals and power into the region. For all that, such a solution does not appear to be much different from having them side by side.
Regardless of any of this, getting signals off-die has an area and power cost, regardless of the exact choice in location of the other die. Closer typically means lower cost, but taking what is currently on-die and massive in terms of signals makes even small costs significant. A global L2 that claims to be as unified for multiple chips as it was within one die is going to be wrestling with wires climbing from tens of nm in size to hundreds/thousands of nm.
I don't know how far AMD has taken IF2.0, but YES... I do b believe you can have - "but cannot change the internals of what it connects to" -
That^^ idea
Is the whole point of AMD's chiplet/fabric design. It is not a dumb interconnect, it can manage it's own data, and interposing, etc. And have different layering of each.
If the fabric changed what it attached to, it would hamper AMD's goal of using it as a general glue to combine IP blocks without forcing either the fabric or the IP block to change when they are combined. For these purposes, it is just an interconnect and cannot make non-coherent hardware coherent.
Nvidia was testing both memory-bound and computation-bound workloads with their theoretical design - these were running non-realtime on their supercomputer simulator. The research paper cites these command-line CUDA workloads simply because these would be much easier to script and profile in this environment.
That seems like a hole too significant to extrapolate over. If a workload is too complex for them to evaluate absent real-time performance requirements, why is it certain that solutions that are declared as working without having complexity or responsiveness as part of their evaluation are sufficient?
All graphics tasks are still either compute-bound or memory bound (or both) - so profiling real games vs memory-bound CUDA tasks would not really change major design decisions about overcoming inefficiencies of far memory accesses.
Graphics tasks can also be synchronization or fixed-function bound, among other things, but that aside I would have liked confirmation that other elements of their workloads could be matched to a game or graphics workload.
A graphics pipeline is a mixture of cooperative and hierarchical tasks, and one area I would like some comparison is whether the modeled cooperative thread array scheduling behavior they modeled fit. Did warp and kernel behaviors align in terms of their access patterns, dependences, and behaviors? Some of the compute workloads were characterized as being relatively clean in how they wrote to specific ranges or could work well with a first-touch page allocation strategy.
Are graphics contexts as clean, or which compute workloads may have complex input/output behaviors that have been found well-handled?
Do the non-evaluated graphics workloads have similar locality behaviors? Can the behavior swing enough to hinder the L1.5 or upset the mix of local/remote accesses? Not finding significant problems with unrelated workloads is not comfortable for me.
Then there are architectural questions, such as with GCN. Does the remote-coherent memory hierarchy break elements like DCC? In that case, there would be graphics workloads that weren't limited by a resource in a monolithic context that become bottlenecked after. If there are scheduling methods or optimizations that avoid this, are they included in the CTA scheduling methods discussed?
As a counterpoint, if the CTA scheduling was straightforward and transparent for the profiled workloads, how should I look at the explicitly exposed thread management of the geometry front end with task and mesh shaders? It might be nice if there were a profiled workload that would indicate that whatever problem those shaders address has been handled.
