An eventuality, however dual core gpu's may have been a better root instead of SLI.
http://www.theinquirer.net/?article=21822
http://www.theinquirer.net/?article=21822
ATI & Nvidia investigating dual core GPU's
- Thread starter Redeemer
- Start date
Sxotty said:Maybe they will end up doing what I suggested earlier and making smaller cores, but finding a way to package different numbers of corse to differentiate products. Of course that will be the end of unlocking pipes and so forth
according to anandtech, thats exactly what intel plans on doing for their future dual core cpus.
You sure? I don't do this lightly, but if you really think so I will...Uttar said:
Slowly and deliberately the Dig types the name "Redeemer" on to his ever expanding shitlist.
Well, I think a multi-chip approach can have quite a few benefits, especially if there is a good mechanism for load balancing between the different chips.
If you split a 400 million transistor chip into 2 200million ones, presumably yield goes up (a fatal defect requires you to throw away half the number of transistors). Also, to achieve a given power target, you could pair up chips with slightly different characteristics (e.g. one chip that requires slightly higher voltage than the other to run at a given clock). Finally, if each chip has it's own memory, you scale memory bandwidth without having to go to wider (potentially more wasteful) bus widths.
You could also put geometry processing onto a separate chip (a la 3dlabs).
Edit: I am taking the original post to mean : multiple cores on the same card or package, not on the same die.
If you split a 400 million transistor chip into 2 200million ones, presumably yield goes up (a fatal defect requires you to throw away half the number of transistors). Also, to achieve a given power target, you could pair up chips with slightly different characteristics (e.g. one chip that requires slightly higher voltage than the other to run at a given clock). Finally, if each chip has it's own memory, you scale memory bandwidth without having to go to wider (potentially more wasteful) bus widths.
You could also put geometry processing onto a separate chip (a la 3dlabs).
Edit: I am taking the original post to mean : multiple cores on the same card or package, not on the same die.
DOGMA1138 said:
Right, you would not gain performance advantage in doing so unless you look at performance in a more open way. By splitting the package into two cores you gain in production. You'd have better succes on yield with two 200M parts (cores) than one 400M part. So, the underlying assumption here would be that scaling performance up by increasing the number of transistors per core would become prohibitive because your yield would drop to unacceptable levels. If it can be alleviated by pairing cores on one package then you will have more success in increasing performance that can actually be sold in the form of a working product.
It's no good having a 1billion transistor GPU running at 1GHz if it takes you ten wafers of silicon to get one functioning one.
Intel is apparently even thinking about doing this in future CPUs. That's right, they seem to be wanting to go from dual core per silicon to two pieces of silicon per package. GPUs and CPUs have some important differences and if you consider that the CPU is at an advantage on some levels, the prospect of doing this for GPUs becomes more clear.
GPUs are very task specific and the task is of a streaming nature. This means two things: GPUs are not using/needing as much cache as a CPU and GPUs are more fully utilized when running. A CPU is more or less designed to stall and have half its logic working at times. While the ALU is doing this the FPU stands idle, for example. This is not always the case, but I am generalizing here. For this reason it makes sense to shut down parts of the CPU when not used. Intel SpeedStep and AMD's Cool n Quiet are going in some way to reduce the electrical load on the system, but future processors will be more adept at shutting down specific, finely grained, areas or circuits depending on need. This doesn't seem like it could help GPUs very much because they are always streaming and running at full capacity (relatively).
I mentioend cache because a pool of cache is very simple to make redundant so if a flaw arises there it is masked at very little cost. However, if your processing logic has a flaw it would be very expensive to replicate and nearly impossible given the overall design. This would be simpler on a GPU, but then you end up building a 36 pipeline GPU in hopes of getting 32 fully functional ones. Again increasing transistor count and a count you are having to accept as defective.
So when Nvidia makes a NV40 it is not so bad to take the rejects and make 6800s out of them. Just mask those pipelines. But what if you want to scale up? If 16 pipelines was tough, what will 32 be like? What about 64? Soon you'd have 1 billion transistors that will all need to operate constantly and flawlessly on a single chip. When Intel manufacture's the Itanium Montecito at 1.7billion transistors it has a large cache (that can be redundant) and they sell them at a huge price. Who will want to buy the entertainment video card where the GPU alone costs $4,000?
So, in many ways it would probably make sense to make GPUs multicore. Not to get a speed enahancement (the single larger chip will be a better performer), but to allow scaling up to happen at all with the constraints of the market.
Jawed
Legend
If we consider the concept of a unified shader design with a farm of "ALUs" assigned work units (shader code) against a pool of pixels/vertices, would this be a strong argument against a dual-GPU graphics card?
I'm thinking that latency across multiple GPUs' discrete pixel/vertex pools becomes prohibitive, or that the architectural benefits in using a farm<->pool architecture are heavily depleted by halving (at least) the possibility that an ALU can work on a pixel/vertex. i.e. if a farm becomes "free" to work on a pixel, but the pixel that's "ready" at that moment is on the other GPU's pool, then you've lost some of the benefits of the unification.
Alternatively, if you consider that the unified model is designed to hide the latency of memory, and that a moderate increase in latency caused by a multi-GPU architecture can be overcome by a small increase in the overall capacity of the farms and pools, then maybe multi-GPU isn't fatal.
Perhaps a single shared pool between multiple cores would be required. Blimey, what kind of memory controllers are you talking about then?
It's also interesting to think about whether ATI's "super-tiled" (R300) architecture naturally progresses (by way of increased granularity) into a unified architecture. This transition seems to require an increase in granuality in both functionality and time. If super-tiling provides such a neatly load-balanced approached to a multi-GPU architecture, then I suppose a unified architecture would follow quite smoothly, being nothing more than a finer-grained version of the super-tiled architecture.
Well, I expect I'm talking to myself...
Jawed
I'm thinking that latency across multiple GPUs' discrete pixel/vertex pools becomes prohibitive, or that the architectural benefits in using a farm<->pool architecture are heavily depleted by halving (at least) the possibility that an ALU can work on a pixel/vertex. i.e. if a farm becomes "free" to work on a pixel, but the pixel that's "ready" at that moment is on the other GPU's pool, then you've lost some of the benefits of the unification.
Alternatively, if you consider that the unified model is designed to hide the latency of memory, and that a moderate increase in latency caused by a multi-GPU architecture can be overcome by a small increase in the overall capacity of the farms and pools, then maybe multi-GPU isn't fatal.
Perhaps a single shared pool between multiple cores would be required. Blimey, what kind of memory controllers are you talking about then?
It's also interesting to think about whether ATI's "super-tiled" (R300) architecture naturally progresses (by way of increased granularity) into a unified architecture. This transition seems to require an increase in granuality in both functionality and time. If super-tiling provides such a neatly load-balanced approached to a multi-GPU architecture, then I suppose a unified architecture would follow quite smoothly, being nothing more than a finer-grained version of the super-tiled architecture.
Well, I expect I'm talking to myself...
Jawed
Similar threads
