AMD: Navi Speculation, Rumours and Discussion [2017-2018]

I would wager it be very hard to lock out MS when it comes to AMD, they are a long term partner (longer than sony) and not only do they have the xbox line but they also have the surface line which I am sure AMD would want to be part of. However the xbox line alone is worth hundreds of millions to AMD. And who knows how much other money MS has given amd for product changes or shrinks and so on.

 

A catch that already has a solution in the pipeline. The pipeline requirement to guarantee serial execution is the culprit here. Primitive shaders should have allowed a workaround for this, but really need standardized in an API which takes time. Relax that serial requirement or allow asynchronous graphics tasks and it should work. That's already acceptable for most rendering tasks as the drivers do what they can out of order when they detect it's possible.

As is it's just doubling CUs, likely with lower clocks, and AMD already has trouble feeding all those cores. Not all that different than single/multi threaded execution on the CPU front.

Multi-die GPUs would still be in there as those designs work well in compute and professional markets where they would be more practical from a cost perspective. Worth noting Epyc is technically a monolithic Ryzen. Even if Navi becomes a single large die there is no reason they can't pair it with another. At the very least the pro version will likely contain a wide Infinity link just to make large Epyc APUs. That would be inline with the Exascale papers we've seen with a GPU doing the heavy lifting alongside a CPU.

 

Is AMD already in a position where a dedicated HPC chip would be feasible for them? Cost, ROI, market share, software ecosystem come to mind.

 

Isn't that what Vega20 already is? I'd think they could fit a Vega20 in an Epyc socket to make an APU reasonably enough. Navi should be comparable to Vega20, but with graphics improvements. Already a picture of a dual Vega 10 in the Vega thread, so no reason they couldn't do the same with Navi for a different segment. One with FP64, one without.

 

Vega20 seems like an iteration of Vega. DP-rate has been quite modular since a couple of generations, so I would not count that as major architectural overhaul. Navi on the other hand, especially with it's scalability-turned-MCM, seems to be a little more than a shrink+DP. Hence my question, whether or not it's time for AMD already to go all-in for the market segments I lined out above (HPC obviously including high performance AI computing).

 

AMD has already gone on record saying that Navi won't be coming as MCM-solution (and that they've had the capability to do it for some time already, but they need to figure out how to make it transparent for developers before it could actually be feasible solution)

 

Nevertheless, people keep repeating the MCM mantra over and over. Maybe starting to think about it's feasibility would help - even though others might arrive at different conclusions.

 

MCM likely won't be until after AMD Next Gen / 7nm+ GPUs and future memory beyond HBM3.

 

For gaming yes, but for non-gaming professional workloads they are all in. At least according to this.

https://www.pcgamesn.com/amd-navi-monolithic-gpu-design?tw=PCGN1

There is no need for them to make it invisible to the developer outside of the gaming market. In the professional market (AI, server, etc.) developers are already used to working with multiple GPUs in their applications.

That is relevant as CarstenS was asking about its application in non-gaming workloads. IE - workloads where AMD see multi-GPU and MCM as desirable and something they are actively working towards/implementing.

Regards,
SB

 

I still think the 1st design will be dedicated and specific to HPC node in same way NVSwitch is, then with it trickling down at least 8-12 months later.
Easier to do and would mean they could bring it to market a bit sooner than they would normally while the solution also can be charged in a way to absorb all of the design implementation costs, simpler due to the solution focused purely on a dedicated all-in-one node.

 

Multi-GPU, which isn't same as MCM. If Navi is to hit gaming market as monolithic chip I can't see it being anything else on professional markets either, 2 monolithics as MCM would require incredibly big packaging. I'm quite confident Navi Multi-GPUs will be same as they're now, 2 separate chips on a board.

 

Yes, but the main part of why I quoted that was a response to this.

That only applies to the gaming market and no other GPU market. Hence, the inability to make it invisible to the developer is irrelevant for the question that CarstenS was asking.

And while it may or may not make it for Navi, AMD is certainly still actively looking at MCM as it's just a subset of multi-GPU. There may be some crossover point where it becomes more cost effective (manufacturing, design, power, inter-GPU communications, whatever.) for it be MCM on one package versus multiple GPUs on a board.

For example some developers have mentioned how it's easier to incorporate advanced compute shaders in games on XBO/PS4 due to the close relationship between the CPU and GPU (I believe iD talked about it a bit when they discussed their port of Doom to the PC and the adjustments that had to be made). Yes, that's for gaming, but for professional applications there may be some benefit to having multiple GPUs having closer ties to each other which would potentially give it a competitive advantage.

Regards,
SB

 

Since it appears nobody here noticed it: https://www.pcgamesn.com/amd-navi-performance-computex

Wang confirmed Navi isn't just a mid range GPU. They're intending to compete at the high end.

 

I think we believed Navi would end up high end as well, just not anytime soon.

 

http://www.freepatentsonline.com/20180144435.pdf

 

Any context you want to provide for this?

Here's context copied from the patent (Text Link):

Title: LOW POWER AND LOW LATENCY GPU COPROCESSOR FOR PERSISTENT COMPUTING

Document Type and Number: United States Patent Application 20180144435
Kind Code: A1
Application Number: 15/360057
Publication Date: 05/24/2018
Filing Date: 11/23/2016

Abstract: Systems, apparatuses, and methods for implementing a graphics processing unit (GPU) coprocessor are disclosed. The GPU coprocessor includes a SIMD unit with the ability to self-schedule sub-wave procedures based on input data flow events. A host processor sends messages targeting the GPU coprocessor to a queue. In response to detecting a first message in the queue, the GPU coprocessor schedules a first sub-task for execution. The GPU coprocessor includes an inter-lane crossbar and intra-lane biased indexing mechanism for a vector general purpose register (VGPR) file. The VGPR file is split into two files. The first VGPR file is a larger register file with one read port and one write port. The second VGPR file is a smaller register file with multiple read ports and one write port. The second VGPR introduces the ability to co-issue more than one instruction per clock cycle.

 

I guess AMD aimed to compete with nV's highend even with the Polaris&Greenland family. The Greenland/Vega 10 die is 484mm2 vs GP102 471mm2, HBM2 included, cutting edge features implemented, etc.

The Navi project could be positioned the same as Greenland was - die size matching a nV's flagship, exotic memory tech, innovative features, etc. However, the end result might be another GCN flop - competing with nV's future 104 or even 106 chip families.

 

To be precise, Wang confirmed, Navi architecutre is not just aimed at mid-range, still leaving open the possibility of a multi-GPU card intended for the high-end (no matter whether or not that's likely to happen). In the polaris days, AMD did indeed show how two RX480 could beat a GTX 1080 in the integrated benchmarks of games like AotS.

 

Nvidia's 2017 design simulation of a MCM-GPU is fully transparent to both the application programmer and the OS - it's indistinguishable from a monolithic integrated GPU, with the video driver handling the details. They use a global thread scheduler which works across all GPU modules and large L1.5 caches in the cross-bar memory controller to improve execution and data access locality in each GPU module and reduce remote memory accesses. The 4-die design was tested in the simulator and found to perform on par with a comparable monolithic GPU using real-life CUDA tasks.

The AMD Execution Thread [2018]#92


MCM-GPU: Multi-Chip-Module GPUs for Continued Performance Scalability
http://research.nvidia.com/publication/2017-06_MCM-GPU:-Multi-Chip-Module-GPUs

 

That never materialized in any real game or even benchmark, Including Ashes Of Singularity.

CUDA tasks are not the same as gaming workloads. The 4 die design was also found to need a tremendous amount of inter-chip bandwidth, up to 3TB/s. This is NOT feasible right now.