• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Is it possible to build a modular gpu?

tybert7

2[H]4U
Joined
Aug 23, 2007
Messages
2,763
I remember hearing reports that zen will be a modular cpu

Leaked details, if true, point to potent AMD Zen CPU | ExtremeTech


But what about a modular gpu from amd? Not just slapping two gpus on a single card like they do with x2 parts where it is still treated as two separate gpus, I am talking about a design where smaller gpu dies can be placed onto a card in such a way that they behave like a single larger die gpu.

Imagine a polaris 10 part with a 232 die size, but combining three or 4 of them and getting the scaling as a single gpu with three to four times the performance.


What is it that prevents this from happening? latency between the different gpu dies? Not being able to share the same memory pool? Is there a way so solve that?

Why not have a design with 8GB or some advanced memory that 2-4 gpus could all connect to and access? What about those optical interconnects that were talked about?




Not applicable on gpus? They keep talking about lower yields on a new process and focusing on smaller die sizes, but this modular approach would allow smaller die sizes to just connect up in some sort of megazord like monster... but is that not possible to do?
 
There are video cards with 2 GPUs on them already. You can use two of them on 2 pcie slots to get the equivalent of 4 cards. XFire/SLI scaling is poor for more than 2 cards. Hardly anyone uses more than 2 cards. So there wouldn't be the demand for what you are suggesting.
 
Not really no. If Zen's modular CPU is anything like the console SoCs. There will be a huge penalty between the 2 clusters. Also for the bigger models with more than 8 cores, you are back to MCM issues.

Between CPUs you can get away with relatively tiny interconnect. In SMP/MCM setups you can get away with 25-50GB/sec. In terms of GPUs you are going to need a lot more. And assuming you dont just match 2 slowpoke GPUs, you are going to need a lot. As in 300GB/sec+. And GPUs are terrible to work together, if they wasn't, we wouldn't have all the appalling multiGPU issues.

In short, you are better of with a single bigger GPU.
 
I believe similar information has to be shared between all 4 separate gpus there is slow down when that happens, and the gpus are physically farther away from each other so that makes for slowdown. So maybe you would need something like the original thunderbolt idea to make it happen. Don't forget in videogames frames per second is an expectation from the user, and a deadline for the computer to come up with in one second. Slowdoown is bad when you need complete results due in one second. That goes double for VR.
 
Until some revolutionary technology comes out of nowhere it's just not possible right now.
 
I remember hearing reports that zen will be a modular cpu

Leaked details, if true, point to potent AMD Zen CPU | ExtremeTech


But what about a modular gpu from amd? Not just slapping two gpus on a single card like they do with x2 parts where it is still treated as two separate gpus, I am talking about a design where smaller gpu dies can be placed onto a card in such a way that they behave like a single larger die gpu.

Imagine a polaris 10 part with a 232 die size, but combining three or 4 of them and getting the scaling as a single gpu with three to four times the performance.


What is it that prevents this from happening? latency between the different gpu dies? Not being able to share the same memory pool? Is there a way so solve that?

Very high speed dictates connections must be solid.
There are a ton of connections, all of which must be guaranteed none lossy because retransmission wont be possible.
Adding a connector block will increase the trace lengths, another enemy of high speed.
If using multiple chips, arbitration will add lag unless they are truly parallel. The longer trace lengths required to link to individual chips will add lag too.
As you pointed out, sharing memory will be a big problem. This is why most multi GPU setups have dedicated ram per GPU.

Its also futile because future chips will likely run at higher frequency which the board wont handle and may need to have a higher pinout or waste potential.
Think of CPU designs, the sockets for those only last a few years before being updated.
 
Zen is designed to have multiple dies on the same package working together with little loss. They accomplish this with fast interconnect.

AMD's GPUs are designed to communicate over PCIe with dedicated DMA engines. It's the same basic idea, with the same potential for scaling.

Both methodologies require the correct kind of software to take advantage of adding MOAR CORES. You need heavily-multithreaded code to take advantage of multi-chip Zen, and you need specially tuned software to take advantage of Crossfire.

You're much more likely to get perfect scaling from GPUs if you're running pure compute. The rendering pipeline is harder to parallelize outside a single GPU, while still maintaining compatibility with the huge amounts of software out there.
 
Zen is designed to have multiple dies on the same package working together with little loss. They accomplish this with fast interconnect.

AMD's GPUs are designed to communicate over PCIe with dedicated DMA engines. It's the same basic idea, with the same potential for scaling.

Both methodologies require the correct kind of software to take advantage of adding MOAR CORES. You need heavily-multithreaded code to take advantage of multi-chip Zen, and you need specially tuned software to take advantage of Crossfire.

You're much more likely to get perfect scaling from GPUs if you're running pure compute. The rendering pipeline is harder to parallelize outside a single GPU, while still maintaining compatibility with the huge amounts of software out there.

Zens MCM approach doesn't scale well. We can see it in GB4. Also the interconnect used isn't fast at all compared to what GPUs require.

To put something in perspective, you would have trouble just putting 340/350 cards on MCM with the interconnect. That's not moving any barriers.

Zen uses GMI that's 25GB/sec per link. And every link you add uses power and die size. Omnipath and NvLink are other examples of interconnects that is nowhere near the required speed.
 
Last edited:
Back
Top