Intel Patents Forming MP Chips Using Dual Processors

[blazorthon]

[citation][nom]sykozis[/nom]It's very similar. Also just a modification of how they made the Pentium-D.... Also similar to what AMD is doing with Bulldozer[/citation]

Bulldozer? The only Bulldozer arch chips that do this are Interlagos Opterons. The rest are all native 4/6/8 core dies.

 

[blazorthon]

[citation][nom]Tomfreak[/nom]so they gonna manufacture i3 CPU only and put 4 of them together call it i7 with 8 cores?Much cheaper this way but hopefully I can cheaper CPU in the future across the entire line of Intel processor.[/citation]

It's not really cheaper if you split all of the cores into separate packages, at least I don't think that it would be. Remember, there are also the memory controllers and the IGPs, among other hardware on the CPU (SB-E also has the PCIe lanes if I remember correctly, some other platforms might too, but I don't know if any others do). So, would each piece of hardware get their own die as well? That would be a lot of dies per chip if so. Besides, it would hinder multi-threaded performance scaling. Intel probably won't do this again much, so it might just be that their old patent for it, that they filed back when they were doing it, was finally legitimized.

If they put four i3s together, then it would have four HD 2500 IGPs and eight memory controllers, so that's not likely. The Core 2 Quads and the Pentium Ds didn't have this problem because the IGPs and the memory controllers were on-board rather than on-die. For example, the Interlagos CPUs have double the memory controllers of the Valencia CPUs because the memory controllers are on-die.

 

[thomaseron]

Intel IS evil!

edit: Hey, don't hate the messenger!
Check the top image...

 

[doorspawn]

I feel something's a bit wrong if cores need so much bandwidth between eachother that proximity between cores is more important than proximity to memory. This is mostly for cache coherency, right?

Why is there so much cache coherency traffic? Is it that most programmers still suck at designing highly concurrent workflows?

The only data elements that should be written to and routinely cached by more than one core are mutexes and other concurrency structures, and writes to these structures should not be occuring with high enough frequency that they require a seriously large data bus.

 

[blazorthon]

[citation][nom]doorspawn[/nom]I feel something's a bit wrong if cores need so much bandwidth between eachother that proximity between cores is more important than proximity to memory. This is mostly for cache coherency, right?Why is there so much cache coherency traffic? Is it that most programmers still suck at designing highly concurrent workflows?The only data elements that should be written to and routinely cached by more than one core are mutexes and other concurrency structures, and writes to these structures should not be occuring with high enough frequency that they require a seriously large data bus.[/citation]

If they all have their own memory controllers, then they might sometimes need access to memory that is controlled by another processor on the chip. That would need a high bandwidth connection.

 

[Guest]

Now if Intel could invent a way to update the computer's OEM's customized HD graphics drivers for Intel's GPUs Without The computer's OEMs having to write new driver software, we all know the computer OEM's just can not provide timely updates to their customized Intel HD graphics drivers. Maybe Intel could provide a graphics driver framework with, APIs that are updated and maintained by Intel, and that the computers's OEM's could utilize in their customized hardware, API's that are part of a Intel GPU Hardware Abstraction Layer. Intel could provide a toolkit to the OEM's that allows any new API feature to be added without the OEMs having to write a single line of new graohics drivers code! These API's would expose a genaric pathway to any past and future API call to the Intel GPU.

 

[paleoism1007]

Congratulations!