Coherency isn't really an issue (and not really necessary at that fine a granularity). The raw bandwidth required is the problem.
LucidLogix Hydra, madness?
- Thread starter Citrous
- Start date
I think intel's own scaling measurement with different numbers of cores have left quite an imprint on peoples minds.
Though I am not sure, i assume these were done at simulator level and wrt a single LRB solution having this and that many cores, not multiple LRB addon-cards communicating via some kind of external interface.
That is correct.
If you want a 2 chip memory uniform memory architecture wrt bandwidth (you ignore latency) where each chip has the same amount of bandwidth as a 1 chip solution and if you assume that you can spread your accesses in a uniform way across the memory of both chips, then you'll have a 50% IO pin overhead compared to a single chip solution.
In single chip mode, you have a 2x256 bit bus. In dual chip, you have 1 256-bit bus going to local memory and 1 256-bit bus going from chip a to chip b, but chip b also needs concurrent access to chip a, so you need an additional 256-bit bus for that.
In any case, your total bandwidth per IO pin (memory pins + interconnect pins) has gone down by 50%: you still only have 512 pins to memory with the same total bandwidth, but you also have 512 pins between the two chips. If your application is bandwidth limited, you didn't win anything.
If you make the interconnect only 2x128 bit and 2x384 bits to memory, then you're not uniform anymore and you have to start to implement about application specific allocation strategies. In case of a GPU, I assume you could do smart placement of textures and Z-buffers, duplicate some texture in both memories, make sure GPU-A renders one part of the screen and GPU-B renders the other...
Starts to sound a lot like SFR, doesn't it?
No matter what, you'll very soon run into issues that prevent perfect scaling.
This might be a stupid question but how exactly would a third-party compositing solution get access to intermediate buffers on a GPU without assistance from the graphics driver? Not to mention how it sends a composed multi-sampled buffer back to a card for AA resolution. Actually how does any communication happen at all without AMD's and Nvidia's blessings?
Damn...
In case of a GPU, I assume you could do smart placement of textures and Z-buffers, duplicate some texture in both memories, make sure GPU-A renders one part of the screen and GPU-B renders the other...
Starts to sound a lot like SFR, doesn't it?
SFR isn't necessarily a panacea if you could IMHLO manage to scale geometry as well as with AFR and manage to divide as good as possible the workload between GPUs.
If you want a 2 chip memory uniform memory architecture wrt bandwidth (you ignore latency) where each chip has the same amount of bandwidth as a 1 chip solution and if you assume that you can spread your accesses in a uniform way across the memory of both chips, then you'll have a 50% IO pin overhead compared to a single chip solution.
In single chip mode, you have a 2x256 bit bus. In dual chip, you have 1 256-bit bus going to local memory and 1 256-bit bus going from chip a to chip b, but chip b also needs concurrent access to chip a, so you need an additional 256-bit bus for that.
In any case, your total bandwidth per IO pin (memory pins + interconnect pins) has gone down by 50%: you still only have 512 pins to memory with the same total bandwidth, but you also have 512 pins between the two chips. If your application is bandwidth limited, you didn't win anything.
If you make the interconnect only 2x128 bit and 2x384 bits to memory, then you're not uniform anymore and you have to start to implement about application specific allocation strategies. In case of a GPU, I assume you could do smart placement of textures and Z-buffers, duplicate some texture in both memories, make sure GPU-A renders one part of the screen and GPU-B renders the other...
Starts to sound a lot like SFR, doesn't it?
No matter what, you'll very soon run into issues that prevent perfect scaling.
Nice explanation. If the software model can guarantee that no chips write to the same location, but read is arbit, then perhaps you will not have these issues. Let us take the case of simple texturing here. In a 2 gpu system, only the pixels at the border will need to read from the other gpu, so and since the ratio of border to bulk pixels goes down as the resolution increases, then numa style hacks may npt be necessary. For general texturing, it's difficult to say.
MSI works on Hydra featuring P55 board:
http://www.iopanel.net/forum/thread31404.html
http://www.iopanel.net/forum/thread31404.html
In Jon Peddie's new report you can find a generic decription of the Hydra system. It seems multi-GPU systems could take off with the help of the Hydra chipset:
Link: http://www.jonpeddie.com/special/WhitePapers/Multi-GPU-issues-and-opportunities.pdf
Link: http://www.jonpeddie.com/special/WhitePapers/Multi-GPU-issues-and-opportunities.pdf
I don’t want to spoil the party but I am still pretty sure that Hydra will never work as promised.
It could work to some degree with special modified drivers and support from the GPU manufacture but not as a generic solution. As I don’t expect support from nvidia or ATI there is only Intel left.
It could work to some degree with special modified drivers and support from the GPU manufacture but not as a generic solution. As I don’t expect support from nvidia or ATI there is only Intel left.
In other words nothing; why would Intel think of multi-GPU with a concept like Larabee anyway?
I am may be wrong but so far I never saw Intel announced some kind of inter card connection.
And it's only a glorified PCI-E bridge there. So instead of using nV's NF200 or some PLX bridge or another, they use the Hydra. Also, apparently that board is merely a prototype, whether or not it'll ever enter mass production is unknown.
Silent_Buddha
Legend
Anandtech got a bit of hands on also, and this is their impression...
http://www.anandtech.com/video/showdoc.aspx?i=3646
Multi-GPU with a Nvidia + ATI GPU on the same system.
Price is pretty steep. Over 70 USD for the high end version and over 40 USD for the low end version of the chip.
Regards,
SB
http://www.anandtech.com/video/showdoc.aspx?i=3646
Multi-GPU with a Nvidia + ATI GPU on the same system.
Price is pretty steep. Over 70 USD for the high end version and over 40 USD for the low end version of the chip.
Regards,
SB