Any just cause or impediment why a computer can't have two TB controllers?
I don't think TB is can be poured on like ketchup.
1. Most mainstream PC designs don't have the bandwidth. The TB controller needs x4 PCI-e v2 lanes. The IOHub/Southbridge has only x8 PCI-e v2 lanes to hand out. Other things like Ethernet, Firewire , Wifi/Bluetooth , etc. also need to tap into that limited x8 lanes. In the Intel reference designs, there are already PCI-e switches to dilute the bandwidth to farm out more shared PCI-e lanes to all of the controllers than need to be hooked up.
The designs are already oversubscribed. Another x4 for Thunderbolt controller would only double down on what there isn't enough of.
[ Dual Xeon E5 with 88 lanes ( 80 on CPU and 8 on its IOHub) have gobs of bandwidth to throw at the problem, but it doesn't have embedded GPU by default. The glut of bandwidth is so large though that is solvable too. It is the single package (E5 1600) that would present trade-offs) ]
It is doubtful that the Thunderbolt controller is going to get wider or narrower on PCI-e lanes ( go 8 v2.0 for reasons above or go 2 v3.0 because it is used a switch to multiple controllers in peripherals on the other side of the network. ). ]
Thunderbolt v2.0s reshuffling of the deck chairs to get to 20Gb/s is indicative that this isn't going to change any time soon. There is no overall net bandwidth increase, it is primarily a re-balancing of what was already there with a different DisplayPort to PCI-e data split.
2. Each Thunderbolt controller (with two ports) pragmatically needs two Display Port (DP ) inputs. Thunderbolt doesn't scale up well on the other "half" of its input requirements.
Num
TB Cntrlr _____ num DP inputs
1 _____________ 2
2 _____________ 4
3 _____________ 6
4 _____________ 8
GPUs soak up internal host bandwidth too. If a discrete (embedded on logic board or on PCI-e card... although that latter probably isn't going to pass TB certification), each GPU soaks up 8-16 lanes. That is an even faster rate than TB is soaking them up.
Modern GPUs can drive 4-6 outputs but typically not all of them DisplayPort. Also DisplayPort 1.2 means they don't have to drive as many physical separate ports as much since can get multiple outputs on one.
3. Fragmentation of PCI-e global address space.
Each TB port can support 6 devices. A two port controller could dangle 12 devices off of it. Each of those 12 could have 4 PCI-e controllers ( USB , FW , Ethernet , etc. ) controllers in them. So 12 x 4 --> 48 PCI-e controllers. Throw in the other ones inside the host PCI-e and that is a pretty large number.
Add another network of 12 and that's another 48. Effectively doubling the number.
It is the wrong way to solve the problem. It would as if USB controllers were limited to just 4 devices and you had to keep adding a myraid of controllers to get to more. As opposed to consolidate the traffic and
then get on PCI-e. PCI-e is not really design for "urban sprawl" of controllers communicating over it. It may be able to do... it is also likely not to behave well either.
Or why Intel might not have 4-port controllers on the drawing board (maybe they've noticed the problem with peripheral makers not including daisychain ports?)
They are not including daisy chain ports because that is cheaper. That is the primary reason. To daisy chain means adding hardware to the perhiperal to handle the backward compatible duties of DisplayPort ( and now DisplayPort v1.2 ).
If there is no second port than nobody can plug in a DisplayPort monitor. Period.
Throw on top of that is that Intel's can only do one port TB controller is cheaper. It is all about money. It is fear (or actual knowledge) that customers won't pay for the second port.
Intel isn't going to have any 4 port controllers while lmited to the same x4 PCI-e bandwidth on/off ramp of PCI-e bandwidth.
Peripherals that need x8 ports can simiply use an off-the-shelf switch to dilute the bandwidth inside of there box.
From the host to TB network perspective not going to able to keep up with low latency requirements.
Thunderbolt isn't USB (or even Firewire). It has far more serious isochronous constraints to match. You can't oversubscribe the network and expect users to put up with crappy network behavior. The controllers designed to send/receive traffic from PCI-e aren't gong to be designed for that.
There are good reason why Intel capped TB at much smaller network (6 per chain and two "directions" so that can put host in middle of two chains: so 12 ) than USB ( max 127 ) and FW ( 63). It has box-to-box transport duties ( distance is not suppose to become an issue) and PCI-e switching duties ( there are typically multiple controllers in external boxes ).
Well, yes - that's exactly Apple's problem. Lots of people who would previously have bought the Mac Pro can now use a Mac Mini or iMac + Thunderbolt.
That isn't a problem for Apple. Those folks just buy other Macs. Apple can survive just fine without a Mac Pro in the line up. They don't have to drop it but they also don't have to keep it either.
Now, unless you really, really need that 8-core Xeon and Quadro GPU to go with it,
That is really who the Mac Pro was always targeted at. Other folks who bought one that was fine but those older equivalents ( 6+ years ago ) were the folks being targeted.
A new headless desktop, with top-end iMac or better processor, 4 RAM slots, a nice big Fusion drive, space for an optional single high-end GPU and no other internal expansion would satisfy a lot of people who would otherwise need a MacPro.
Those folks probably didn't "need" a Mac Pro. What they required was something that gave them x2 (or more ) PCI-e like bandwidth. A box-with-slots doesn't necessarily equate with that kind of bandwidth.
Folks get fixated on the form ("it has gotten look like this") over function ("what are the core requirements")
