"Multi-Core" graphics cards

[xFluing]

Just now, xAcid9 said:

Sorry what? That's not how this work i think. 

Yep, not at all how it works.

[Cereal5]

4 minutes ago, xAcid9 said:

Sorry what? That's not how this work i think. 

Yes it is lol. He said that squeezing more dies onto a wafer will reduce the cost of the wafer, since there are more dies. So the dies become smaller. But each die is still the same price. So since there are more dies on the wafer, the wafer is worth more.

 

edit: like it was originally said, it increases the yield per wafer. It only reduces overall costs if the goal is to produce the same amount of dies. However the money spent on the technology it will take to shrink dies further will probably outweigh the money saved by fitting more of them onto a single wafer, at least until the process gets smoothed out.

[xAcid9]

Just now, Cereal5 said:

Yes it is lol. He said that squeezing more dies onto a wafer will reduce the cost of the wafer, since there are more dies. So the dies become smaller. But each die is still the same price. So since there are more dies on the wafer, the wafer is worth more.

They pay for the wafer not how much die you can fit into a wafer iirc. 

[Cereal5]

Just now, xAcid9 said:

They pay for the wafer not how much die you can fit into a wafer iirc. 

check edit, sorry

[GoldenLag]

20 minutes ago, Cereal5 said:

-snip-

The cost of the wafer is constant.

The failure rate per inch of die/wafer is the same.

Smaller dies mean less "dead space" on the edges of the round wafer.

 

The smaller dies the less chance of failure that die has. Meanwhile a larger die has a larger chance of failure. 

 

4 smaller dies the size of 1 larger die has the same total chance of getting a failure, but since it is split into 4, only 1 of the dies will fail leaving 3 functioning dies instead of 1 large dead die.

 

Due to the points above the cost of 4 smaller chips with the same metrics as a larger one is less than one monolithic die.

 

Edit: shrinking of the die has nothing to do with this. The premise is producing four 4 core dies to link into one large 16 core die instead of producing a single large 16 core die. The single large 16 core die has a larger failure rate compared to each induvidual 4 core die. 

 

The process node remains the same. 

Edited September 12, 2018 by GoldenLag
Just tidying stuff up

[xAcid9]

9 minutes ago, Cereal5 said:

check edit, sorry

how to shrink dies if 

1 hour ago, xFluing said:

So, now that we are getting closer and closer to the end of the manufacturing process shrink, how will GPUs evolve from here on out?

[GoldenLag]

14 minutes ago, Cereal5 said:

check edit, sorry

The edit still isnt remotely how it works.

 

See my response above

[Cereal5]

1 hour ago, xFluing said:

So, now that we are getting closer and closer to the end of the manufacturing process shrink, how will GPUs evolve from here on out?

 

1 minute ago, xAcid9 said:

how to shrink dies if 

 

Just now, GoldenLag said:

The edit still isnt remotely how it works.

 

See my response above

So if we can't shrink dies any more why are we having this discussion...

[GoldenLag]

Just now, Cereal5 said:

 

 

So if we can't shrink dies any more why are we having this discussion...

Read my edit on tye responce i made. 

 

5 minutes ago, GoldenLag said:

Edit: shrinking of the die has nothing to do with this. The premise is producing four 4 core dies to link into one large 16 core die instead of producing a single large 16 core die. The single large 16 core die has a larger failure rate compared to each induvidual 4 core die. 

 

The process node remains the same

By this method you can create a large CPUs using low yield nodes. 

[porina]

Having multiple cores/dies/whatever works well if they don't have to talk to each other. When they do... that's when the problems start. Look at HPC as a long standing example into this. You can relatively easily add more compute resource, but the bandwidth and latency for that resource to communicate with each other is where things really get bottlenecked.

 

Part of the problem with SLI/Crossfire might have been bandwidth after all. PCIe 3.0 is near enough 1GB/s per lane. nvidia's SLI bridges are 1 or 2 GB/s depending on model. nvlink for the upcoming RTX cards is 50GB/s. That's far more than we had before, but will it help? We might find out soon, but that still assumes multiple cards.

 

Multiple dies on one card wouldn't need an external solution, so are there high bandwidth low latency interconnects that could be used?

 

Using Epyc as an example, it looked like that is 42GB/s per link (all dies linked to each other) and 38GB/s die to die between sockets. Would something like this allow future SLI/Crossfire to work better and more seamlessly to the developer? I don't know...

[GoldenLag]

3 minutes ago, porina said:

Using Epyc as an example, it looked like that is 42GB/s per link (all dies linked to each other) and 38GB/s die to die between sockets. Would something like this allow future SLI/Crossfire to work better and more seamlessly to the developer? I don't know...

According to AMD such an approach wont work due to how cache and memmory is handled. 

 

This was regardless of the bandwidth.

The developer wont see them as a single GPU. 

[E.Mon]

4 hours ago, xFluing said:

Nah, I'm talking about some kind of tech that's not shit, something that would make the GPU modules work as one singular GPU unit instead of taking turns rendering frames or each one rendering half a frame.

Well if developers would put the time in to support it, crossfire and SLI wouldn't BE shit. 

[porina]

5 hours ago, GoldenLag said:

According to AMD such an approach wont work due to how cache and memmory is handled. 

 

This was regardless of the bandwidth.

The developer wont see them as a single GPU. 

While the dev not having to deal with multiple GPUs is ideal, the middle ground might be a way to make it easy enough to scale.

 

As a more recent example, nvidia has been saying for the RTX quadros, if you use nvlink on two cards, you get the combined vram available for use. As in, not duplicated data on both of them. We're still lacking technical details, but this is likely in part due to the 50GB/s path from nvlink, on top of the existing PCIe. Things like this could be the first steps to a return to higher order SLI.

 

I still remain cautiously optimistic that, as GPUs are inherently more parallel than CPUs, some way to improve this in future may be found. I still believe that both bandwidth and latency are key to enabling this.

[pas008]

1 hour ago, porina said:

While the dev not having to deal with multiple GPUs is ideal, the middle ground might be a way to make it easy enough to scale.

 

As a more recent example, nvidia has been saying for the RTX quadros, if you use nvlink on two cards, you get the combined vram available for use. As in, not duplicated data on both of them. We're still lacking technical details, but this is likely in part due to the 50GB/s path from nvlink, on top of the existing PCIe. Things like this could be the first steps to a return to higher order SLI.

 

I still remain cautiously optimistic that, as GPUs are inherently more parallel than CPUs, some way to improve this in future may be found. I still believe that both bandwidth and latency are key to enabling this.

along with dx/vulkan

 

remember the hydra 100 and 200 chips that allowed for mixed gpus

these companies might have to possibly include something like those to split the work loads on the card itself but then again have low latency putting it all back together