power666

I'll second the error between identifying the system memory and the VRAM.   There is 4 MB of on board memory and you can see it between the single 72 pin SIMM slot and the two VRAM slots.  Practical limit is 68 MB of RAM as I haven't seen a single 128 MB 72 pin SIMM but have encountered a 64 MB unit.  I have seen a slot adapter that would connect two 72 pin SIMMs into a single 72 pin slot.  The gotcha here is that such an adapter wouldn't let you close the chassis due to this system's small size, limiting you to 68 MB in total.
 
I also hope that some one there also figured out that old school classic Mac OS didn't dynamically allocate memory for you.  That extra 16 MB SIMM installed isn't going to be used unless you manually assign RAM to an application prior to launching it.  (Select the application in the Finder and then Get Info under the Finder's File menu.)  If you had the extra RAM, things generally were snappier even on this old hardware.  Even to this day Apple ships about half the amount of RAM that they should on every system for their baseline.  
 
For those seeking ultimate performance and had the RAM to spare, these systems can boot off of a RAM disk.  This would improve load times dramatically for games.

1:55 This machine could run System 8.1 however, a little bit more advanced than System 7.5.5, in particular the improved Finder.

9:00 Should've pulled up a game of Bolo if you wanted to know what retro Mac gaming was like in the early '90s.  Then again, I did see Marathon which would have been since to see played since Bungie is dusting off that old series for a new installment soon.

Ugh, lots of nitpicks in this video.

First of, none of the modern 4-way SLI setups from nVidia were mentioned.  Granted, you can only get them in from nVidia directly in their DGX workstations which use Quadro class graphics but they are similar to that 8-way Voodoo card by incorporating a chip on the bridge connector.  The nvLink chip on the bridge is what permits standard desktop Quadros which are normally limited to 2-way SLI scale higher via this fanout switch chip.   Some who could get their hands on this DGX bridge board could build their own 4-way Quadro setup but Conceptually 8-way SLI is still possible due to the number of nvLink buses supported on the nvLink chip, however, nVidia has kept 8 GPU and higher systems isolated to the data center and their mezzanine style carrier cards.  Since nvLink is being leveraged, it also permits memory sharing and aggregation, which is another nitpick that I'll get to later on.
 
The second nitpick is that the video doesn't dive too deep into the challenges of leveraging multiple GPUs which is simply load balancing. Splitting frames up evenly in terms of output pixel count doesn't inherently mean that each GPU does the same amount of work needs to be performed in those regions.  With an uneven load across the GPUs, performance is inherently limited to how long it takes the GPU with the most work to finish, a classic bottleneck scenario.  
 
Third nitpick is that SLI is never actually displayed on screen using its interleaving nature.  3dfx figured out early on that having each GPU work on a different scan line is a simply and relatively efficient for how 3D APIs were working back then.  As more complex rendering techniques are being developed, it was no longer to simply scale this technique:  shaders would reference data from the pixels found on the previous scan line.  

Fourth nitpick is that spit frame rendering was demonstrated as a splitting the screen into quads which isn't how it normally worked.  Rather the splits would be in horizontal lines the heights varying to load balance across the GPUs.  The reason being is that each GPU would be responsible for a full display scan line.  Splitting mid scan line was often glitchy from a visual perspective without having an additional aggregation buffer.  The additional buffer was not optimal due to the small memory sizes of GPUs at the time and the lag it would introduce.  Not impossible for a quad split to be used but it was not the norm.
 
Fifth nitpick is that different multi-GPU techniques can be used in tandem when there are 4 or GPUs in a system.  AFR of SFR was used in some games.  Not really a nitpick but more of a piece of trivia, AFR of SFR came to be as DirectX had a maximum 8 frame buffers currently in flight.  This figure is a bit deceptive as one buffer is being output to the screen while the next is being rendered which is done on a per GPU basis with that API.  This limited AFR under DirectX effectively to 4-way maximum GPU setup.  Hence why AFR of SFR was necessary to go beyond 4-way GPU setups or if triple buffering was being leveraged.  DirectX 10 did effectively off SFR support which capped GPU support on the consumer side to 4-way.   I haven't kept up but Vulkan and DX12 should be able to bring these techniques back but support rests on the game/application developer, not the hardware manufacturer/API developer.
 
Checkerboard render is interesting in several aspects.  First off, even single GPUs have leveraged this technique as a means to vary image quality in minor ways across a frame that makes it difficult to discern.  Think of a frame split up to 64 x 64 tiles but for some complex tiles and to keep the frame rate up, the GPU will instead render a 16 x 16 or 8 x 8 pixel version of that tile and brute force scale it up to save on computational time.  When multiple GPUs were involved, the tile size was important to evenly distribute the work.  There is a further technique to load balance by further breaking down larger tiles into even smaller ones and then distributing that work load across multiple GPUs.  So instead of a complex 64 x 64 tile getting a 16 x 16 rendered tile that is scaled upward, in a multiple GPU scenario four 16 x 16 tiles are split across multiple GPUs to maintain speed and quality.  Further subdividing tiles and assigning them to specific GPU is indeed a very computationally complex task but the modern GPUs already have accelerators in place to tackle this workload.  This is how various hardware video encoders function to produce high quality, compress images by subdiving portions of the screen.  While never explicitly said, I suspect that this is one of the reasons why modern GPUs have started to include multiple hardware video encoders.
 
One technique not mentioned is when multiple monitors are used as each display can be driven/rendered by a different GPU.  While not load balanced, it is pretty straight forward to implement.  Both AMD and nVidia provide additional hardware to synchronize refresh rates and output across multiple monitors as well as the GPUs.
 
The original CrossFire with dongle was mostly AFR as the there was a video output switch on the master card.  The master card decided which GPU was sending output to the monitor.  This was mostly done via detecting V-blank signals.  The chip could conceptually switch mid-frame at the end of a scanline but ATI never got this to work reliably so they to focused on AFR.  (Note: later implementations of Crossfire that used internal ribbon cables could switch on a per scanline basis making this an issue only for ATI early implementations.)  
 
In the early days of multiple GPUs, video memory was simply mirrored across GPUs.  This wasn't emphasized in the video but was implied in the scenarios leveraging AFR due to each GPU doing the same work at a different slices in time.  Modern GPUs that leverage nvLink from nVidia and Infinity Fabric links from AMD can actually aggregate memory spaces.  They also permit dedicated regions to each GPU while having a portion mirrored across the GPUs to limit.  For example two modern Quadros with 24 GB of memory on board could provide 24 GB (full mirroring), 36 GB (12 GB dedicated on each card with 12 GB mirrored), or 48 GB of memory (full dedicated) to an application to use.  That flexibility is great to have.

Ugh, lots of nitpicks in this video.

First of, none of the modern 4-way SLI setups from nVidia were mentioned.  Granted, you can only get them in from nVidia directly in their DGX workstations which use Quadro class graphics but they are similar to that 8-way Voodoo card by incorporating a chip on the bridge connector.  The nvLink chip on the bridge is what permits standard desktop Quadros which are normally limited to 2-way SLI scale higher via this fanout switch chip.   Some who could get their hands on this DGX bridge board could build their own 4-way Quadro setup but Conceptually 8-way SLI is still possible due to the number of nvLink buses supported on the nvLink chip, however, nVidia has kept 8 GPU and higher systems isolated to the data center and their mezzanine style carrier cards.  Since nvLink is being leveraged, it also permits memory sharing and aggregation, which is another nitpick that I'll get to later on.
 
The second nitpick is that the video doesn't dive too deep into the challenges of leveraging multiple GPUs which is simply load balancing. Splitting frames up evenly in terms of output pixel count doesn't inherently mean that each GPU does the same amount of work needs to be performed in those regions.  With an uneven load across the GPUs, performance is inherently limited to how long it takes the GPU with the most work to finish, a classic bottleneck scenario.  
 
Third nitpick is that SLI is never actually displayed on screen using its interleaving nature.  3dfx figured out early on that having each GPU work on a different scan line is a simply and relatively efficient for how 3D APIs were working back then.  As more complex rendering techniques are being developed, it was no longer to simply scale this technique:  shaders would reference data from the pixels found on the previous scan line.  

Fourth nitpick is that spit frame rendering was demonstrated as a splitting the screen into quads which isn't how it normally worked.  Rather the splits would be in horizontal lines the heights varying to load balance across the GPUs.  The reason being is that each GPU would be responsible for a full display scan line.  Splitting mid scan line was often glitchy from a visual perspective without having an additional aggregation buffer.  The additional buffer was not optimal due to the small memory sizes of GPUs at the time and the lag it would introduce.  Not impossible for a quad split to be used but it was not the norm.
 
Fifth nitpick is that different multi-GPU techniques can be used in tandem when there are 4 or GPUs in a system.  AFR of SFR was used in some games.  Not really a nitpick but more of a piece of trivia, AFR of SFR came to be as DirectX had a maximum 8 frame buffers currently in flight.  This figure is a bit deceptive as one buffer is being output to the screen while the next is being rendered which is done on a per GPU basis with that API.  This limited AFR under DirectX effectively to 4-way maximum GPU setup.  Hence why AFR of SFR was necessary to go beyond 4-way GPU setups or if triple buffering was being leveraged.  DirectX 10 did effectively off SFR support which capped GPU support on the consumer side to 4-way.   I haven't kept up but Vulkan and DX12 should be able to bring these techniques back but support rests on the game/application developer, not the hardware manufacturer/API developer.
 
Checkerboard render is interesting in several aspects.  First off, even single GPUs have leveraged this technique as a means to vary image quality in minor ways across a frame that makes it difficult to discern.  Think of a frame split up to 64 x 64 tiles but for some complex tiles and to keep the frame rate up, the GPU will instead render a 16 x 16 or 8 x 8 pixel version of that tile and brute force scale it up to save on computational time.  When multiple GPUs were involved, the tile size was important to evenly distribute the work.  There is a further technique to load balance by further breaking down larger tiles into even smaller ones and then distributing that work load across multiple GPUs.  So instead of a complex 64 x 64 tile getting a 16 x 16 rendered tile that is scaled upward, in a multiple GPU scenario four 16 x 16 tiles are split across multiple GPUs to maintain speed and quality.  Further subdividing tiles and assigning them to specific GPU is indeed a very computationally complex task but the modern GPUs already have accelerators in place to tackle this workload.  This is how various hardware video encoders function to produce high quality, compress images by subdiving portions of the screen.  While never explicitly said, I suspect that this is one of the reasons why modern GPUs have started to include multiple hardware video encoders.
 
One technique not mentioned is when multiple monitors are used as each display can be driven/rendered by a different GPU.  While not load balanced, it is pretty straight forward to implement.  Both AMD and nVidia provide additional hardware to synchronize refresh rates and output across multiple monitors as well as the GPUs.
 
The original CrossFire with dongle was mostly AFR as the there was a video output switch on the master card.  The master card decided which GPU was sending output to the monitor.  This was mostly done via detecting V-blank signals.  The chip could conceptually switch mid-frame at the end of a scanline but ATI never got this to work reliably so they to focused on AFR.  (Note: later implementations of Crossfire that used internal ribbon cables could switch on a per scanline basis making this an issue only for ATI early implementations.)  
 
In the early days of multiple GPUs, video memory was simply mirrored across GPUs.  This wasn't emphasized in the video but was implied in the scenarios leveraging AFR due to each GPU doing the same work at a different slices in time.  Modern GPUs that leverage nvLink from nVidia and Infinity Fabric links from AMD can actually aggregate memory spaces.  They also permit dedicated regions to each GPU while having a portion mirrored across the GPUs to limit.  For example two modern Quadros with 24 GB of memory on board could provide 24 GB (full mirroring), 36 GB (12 GB dedicated on each card with 12 GB mirrored), or 48 GB of memory (full dedicated) to an application to use.  That flexibility is great to have.

Those PCIe switches are pricy and hence the high cost of the carrier card.  One of the things on the switch spec sheet for the chip but isn't on the card is a 100 Mbit Ethernet out-of-band management support.   Mention in the video as a use-case is leveraging these chips for compositable infrastructure but like all enterprise grade infrastructure you want management functionalities to be separated from production data paths.  So why would some one want out-of-band management on a particular card like this?  First thing is encryption support as it would provide a means to pass keys around that would not touch the host system or production path ways.  While it would be painfully slow, it does provide an online means of extracting data in the event of a host system failure.  Lastly and seen in the video, is that out-of-band management can pass health information.  For a carrier card crammed like this, being able to run an instance of monitoring software on the card itself to record drive temperatures for a monitoring platform would be great.   
 
One thing not fully explored here but it is a power of the PCIe switch chip is that while link between the CPU and card is 16 lane PCIe 4.0, the drives could be simple 4 lane PCIe 3.0 units and performance would not be significantly impacted.  Similar situation if a 100 lane PCIe 5.0 switch was used with PCIe 4.0 based NVMe drives.  In fact, with a 100 lane PCIe 5.0 switch chip and 21 drives at PCIe 3.0 speeds, the link between the card and the host system will still be a bottleneck vs. the aggregate drive bandwidth.
 
 

I'm perplexed why an audiophile portable rack and some 15-18" depth rackmount cases to fit everything was considered.  This would also permit inclusion of a good rackmount switch and leave room for a UPS (though shipping the UPS across boarders might be problematic, you'd have the room*). The downside is that you'd have to ship it via freight but those cases are designed to be abused in transit.  Hotels generally can hold some freight and it is always courteous  to work with them ahead of time to be prepared to received the gear.  Doubly so when going across borders to account for custom times.  
 
An alternative to freight shipping and dealing with customs would be to have some one drive it down since it is 'only' Canada to the US.  Custom checks are relatively painless, you can move more and you have a built-in chain of custody presuming it is a member of the team driving it.  Less lead time is necessary vs. freight but I'd still plan for a buffer in case anything goes wrong.  The unused buffer time can be used for prep at the hotel prior to everyone else's arrival:  you'd have the network built up and tested as people are arriving to the hotel.  If you reserve neighboring rooms, often there are side doors connecting them all which you can run cables underneath.  Literally get everyone on to high speed hardwired network.  The downside is that this removes members of the staff for rather mundane work that'd otherwise be doing something else.  Gotta weigh the cost-benefits here as man power and insurance are factors.
 
There is yet another solution being Las Vegas:  rental gear from various AV production companies.  Most have huge warehouses in Las Vegas due to the numerous shows taking place there.  Various Dell/HP/Lenovo workstations can be rented ahead of time and delivered to the hotel without worry from customs.  Same day replacement options are possible (still buffer in some setup time prior to production).  Items like storage would have to be flow in but straight forward.  This setup can be tested ahead of time by having a unit shipped to the offices and mocked there.  It might even be possible to arrange for the same unit used in the mock to be the one used in Las Vegas.  This eliminates much of the freight shipping but the upfront costs are not cheap.  This can still provide savings if you have good tracking on how much your logistics cost.  One downside for CES in particular is that you have to get in your rental requests early.  CES is one of the few shows that can drain inventory.
 
If carry-on was a requirement due to the costs, have you considered breaking the system up across multiple chassis and multiple carry-ons?  Just moving storage externally frees up so much volume in this design.  
 
Or why not do things the LTT way and build a custom case that'd be purpose built to fit inside the Pelican box?  You'd be able to put in larger motherboard, have hot swap drive bays and utilize far more powerful hardware even after losing some volume for the necessary vibration mounting/foam.  To actually run the system, the Pelican case would have to be open like it was sitting on the table in the video but inside a hotel room this is not a big deal.  Obviously you can't put ventilation holes into the external shell. There is a time-cost-benefit analysis that'd need to be done for this.  For a media company like this though, the ROI could be spread out across over multiple trips, especially if the internal rig adheres to motherboard/component standards for upgrades later.  
 
Also good to see some testing done prior to shipping.  This will need to be repeated upon arrival before production work starts on it.
 
*One of the things I've learned for trade shows is that if something is deemed mission critical but complicates shipping, consider purchasing it locally and having it shipped to your hotel.  If you're already shipping freight there, the hotel will also accept a package.  It is possible to flip such things quickly on CL or eBay to recover some of the cost after the event is over.  
 
Vibration rigging so that you can ensure that damage done to the case doesn't get transferred to the components on the inside.  High end travel cases suspend the contents so that the exterior can be dented or even ruptured without damaging stuff on the inside.  It is possible but generally custom built which means not cheap.  
 
It is worth pointing out that this video's solution negates any sort of protection for the items inside due to the tight fit.  There needs to be some interior padding, especially for that fragile InWin case.  That looks like I could wrap it by just staring menacingly at it.

The system was not running true quad SLI as there was not a 4-way nvLink bridge installed.  Rather it was two dual SLI.  Same number of GPUs in total but they are seen by applications as two logical GPUs which the driver then splits the work load again in half for each individual physical GPU.  I suspect that stable results would have been achieved by either removing the nvLink bridges so the system would see four physical GPUs or disabling a pair with nvLink bridges between them.  
 
On a more positive note, the logical GPU would have had 96 GB of memory to leverage as memory is shared over the nvLink connector.  With a true quad nvLink setup, there would be 192 GB of memory for the GPUs to leverage.

A couple of corrections from the video:
 
The trash can Mac Pro is actually a six year old design:  it was announced at WWDC 2013 but first shipped in December 2013.  Given that Apple is announcing this system at WWDC 2019 and shipping later, the 6 year mark is apt. 
 
Apple has mentioned the 8 pin PCIe power connectors but no normal headers have been spotted on the motherboard shots I've seen.  Either Apple has hidden them very well or they're using some proprietary connector.  Apple has not mentioned either way if the system will include such cables or if they'll be a separate accessory.
 
The Xeon W's used in this Mac Pro are not yet available on the PC side and they are all LGA 3647.  For those keeping track, this maybe the fourth iteration of LGA 3647 (Xeon Phi, Xeon Scalable, Xeon Scalable with FPGA and now this) which bring 64 PCIe lane support but no UPI interfaces to other sockets.  Unknown if how interoperable this socket is with existing LGA 3647 parts or if anything else in the future will use it at all.
 
Speaking of costs, you are omitting the dual 10 Gbit NIC though that may or may not be included in a workstation motherboard.  I would argue that the video card is more equivalent to the workstation Radeon Pro WX7100 which does cost a bit more.  The boot camp drivers have enabled several of the workstation only features on the trash can Mac Pro's graphics cards so there is merit there.  Still Apple is over charging versus DIY but they are not out of line from similar single socket systems from Dell/HPLenovo.  A statement made in the video also applies to the builds from Dell/HP/Lenovo as well:  they do offer different component selection that does permit a lower entry level price.  Yeah, the 1.7 Ghz hexacore entry level Xeon-SP you can get for an entry level Windows workstation is going to save you several thousand versus a 3.5 Ghz, 8 core Xeon-SP.
 
Now for my own comments on the system:  about time.  
 
Apple again when into a different direction with their design.  The most interesting aspect in my opinion is that to conserve system volume, they put the DIMM slots and SSDs on the back of the motherboard.  I would have moved the CPU to the other side as well to reduce the overall system height even further at the cost of making it wider.  Using the specialty video cards that are 'passive' rings of a server-like build where the high pressure fans at the front of the chassis are responsible the air flow there.  Apple has a good track record of keeping these quiet but sometimes ventures into form over function.  Ever put your hand on top of the new Mac Mini while under load?  
 
I do think Apple made a mistake by not leveraging Epyc as that would have provided for more memory support  (and no memory capacity premium either) and more PCIe lanes.  There does appear to be a PCIe switch on the motherboard.   A far lesser mistake here is that they are not leveraging any of the Xeon Scalable chips with an on package FPGA like he Xeon Gold 6138P.  Intel had far more plans here at 10 nm but we all know how that roadmap has played out.  Instead we get an external FPGA on a PCIe card which is fine given the niche instead of being inside the CPU socket which is fine for now.  I hope the pricing for the LGA 3647 Xeon W's are not outrageous now that Intel has competition.
 
The GPU selection is very interesting.  Good to see Infinity Fabric leveraged at last on the GPU side of things.  Very curious to see how this system performs with 1, 2 and 4 GPUs tied together.  While insane for this purpose, I am curious about gaming when topped out, especially at resolutions beyond 4K.  Frame rates shouldn't be bad but frame time is the thing to really watch.
 
SSD pricing is poor and capacity is lacking.  For a proprietary solution, there is little advantage to going this route.  There are a couple of SATA ports for spinning rust if capacity is warranted and the PCIe slots can be adapted to M.2 for more commodity storage.  There is really not incentive to go with Apple's storage options unless they force booting from it.
 
The optional wheels are going to be nice.  I like wheels.  See the Lian Li PC343.
 
The XDR display is going to be nice and I look forward to seeing one.  I have experience using a Barco reference display for medical imaging that can attain an even higher brightness so I'll be a good comparison.  The Barco unit was ~$38K a few years back and likely hasn't dropped in price due to its certification as a FDA medical device.   Apple is nickel and diming a bit here by not including the stand as the 'base' model and then offer a VESA mount model for slightly less.  Yeah, displays like these often get custom mounts but also plenty of them don't.  These reeks of being cheap on a $5000 product.
 
 
 
 

Tow that Windows boat back to port.

HPE has been doing a lot on the fabric side of things.  Gen-Z looks like an idea that was spawned for their "The Machine" research.  HPE's purchase of SGI got them NUMAlink which is used inside of the SuperDome Flex servers (though HPE doesn't scale them as large as SGI used to for various reasons).  Acquiring Cray puts another fabric designer into their portfolio while HPE is also promoting their own technology.  
 
This could be a response market changes as Mellanox is being purchased by nVidia.  Intel has been quiet about Omnipath so far this year and the on package options are missing from Cascade Lake Xeons.  Intel should be debuting 200 Gbit Omnipath this year.  What ever the case maybe, the number of companies providing fabric, or at least fabric that likely will not be tied to another kit of hardware (x86 + Omnipath, nVidia Tesla + Infiniband) is declining.*  This could be seen as a defensive move in the market to ensure that they have continued access to high speed fabrics.
 
HPE could be moving in an offense nature here too.  HP purchased Compaq many years ago with one of the motivators was acquiring the DEC Alpha architecture only to kill it off in favor of the partially HP developed Itanium chip.  A bit of a shell game happened where the Alpha assets was spun off into another company (which Intel quickly bought).  The result was a reduction in competition while freeing up a custom base who needed a new hardware platform to migrate to.  Unfortunately Itanium was a flop while the combination of x86-64 + Linux exploded in popularity in the data center.  HP's offense move here ended up shooting themselves in the foot.  Acquiring Cray would remove a competitor from the market as they are just beginning to push Gen-Z and Cray is one of the few companies which could produce an open market competitor.   The likes of OpenCAPI and CCIX do overlap a bit with Gen-Z in funcitonality but are focused more on internal system communication, not between systems which Gen-Z is attempting.  It would be difficult for history to repeat itself here.
 
*High speed Ethernet is an option for bandwidth but for HPC workloads, its high latency is often suboptimal.

HPE has been doing a lot on the fabric side of things.  Gen-Z looks like an idea that was spawned for their "The Machine" research.  HPE's purchase of SGI got them NUMAlink which is used inside of the SuperDome Flex servers (though HPE doesn't scale them as large as SGI used to for various reasons).  Acquiring Cray puts another fabric designer into their portfolio while HPE is also promoting their own technology.  
 
This could be a response market changes as Mellanox is being purchased by nVidia.  Intel has been quiet about Omnipath so far this year and the on package options are missing from Cascade Lake Xeons.  Intel should be debuting 200 Gbit Omnipath this year.  What ever the case maybe, the number of companies providing fabric, or at least fabric that likely will not be tied to another kit of hardware (x86 + Omnipath, nVidia Tesla + Infiniband) is declining.*  This could be seen as a defensive move in the market to ensure that they have continued access to high speed fabrics.
 
HPE could be moving in an offense nature here too.  HP purchased Compaq many years ago with one of the motivators was acquiring the DEC Alpha architecture only to kill it off in favor of the partially HP developed Itanium chip.  A bit of a shell game happened where the Alpha assets was spun off into another company (which Intel quickly bought).  The result was a reduction in competition while freeing up a custom base who needed a new hardware platform to migrate to.  Unfortunately Itanium was a flop while the combination of x86-64 + Linux exploded in popularity in the data center.  HP's offense move here ended up shooting themselves in the foot.  Acquiring Cray would remove a competitor from the market as they are just beginning to push Gen-Z and Cray is one of the few companies which could produce an open market competitor.   The likes of OpenCAPI and CCIX do overlap a bit with Gen-Z in funcitonality but are focused more on internal system communication, not between systems which Gen-Z is attempting.  It would be difficult for history to repeat itself here.
 
*High speed Ethernet is an option for bandwidth but for HPC workloads, its high latency is often suboptimal.

Nope due to being a glorified MXM carrier card.  The outputs of the MXM card go through the edge connector.  Those outputs are routed on the carrier card to the HDbaseT transceivers.  Conceptually you could swap MXM cards but there are some quirks (nVidia GPUs only support four outputs where as the card in the video has six.)
 
If you wanted to go that distance, you can get external extenders that'll accept an ordinary HDMI input.

Most displays that large don't use ordinary displays because bezels are ugly.  The majority of LED video walls also leverage RJ45 connectors and category (STP CAT6A) cabling but are not HDbaseT either.  Most are based around the NovaStar platform with many simply reselling the design whole sale.  Mixing the NovaStar connections with HDbaseT or Ethernet will cause bad things to happen (TM).  The NovaStar platform relays on HDMI or DVI inputs. and doesn't do any sort of signal cropping (it will do scaling for the oddball LED resolutions).  Chances are that you'd also want a matrix switcher or multi view processor before the NovaStar inputs anyway, so you'd be using more traditional video card outputs anyway.  I've personally built a 2688 x 1536 and a 7680 x 2160 resolution walls based off of NovaStar platforms.
 
The newer LED wall stuff from Barco and Christie oddly enough is IP based using true Ethernet and can leverage PoE to power the LED panel.  Though these installs typically will use data daisy chaining so PoE while nice can only provide power for a handful of panels.  The input side of these is still HDMI, DP, SDI or SDVoE (Ethernet) so the Advoli card would be useless.  These platforms are not as mature as I had hoped as the IP transport is designed to be on its own private 10 Gbit network separate from all other traffic.  I understand why as these design schema relies on active-active multipathing to provide link redundancy which would normally cause havoc on normal tree-leaf corporate network topologies.
 
The exception is Planar which makes a  27", 1280 x 720 resolution bezel-less cabinet with HDbaseT in.  The cabinet has the outputs for eight other cabinets to be chained from it so you can get 3840 x 2160 resolution into 81" from one HDbaseT run.  The neat thing is that the Quadro version of the Advoli carrier card supports gen-lock and the Planar cabinet supports gen-lock and 240 Hz refresh if only driving itself from HDbaseT run (no daisy chaining).  LED walls are pretty crazy and advertise up to 480 Hz refresh rate but are often limited by the source connection.  So it is possible to do a 42" 2560 x 1440 @ 240 Hz logical display from a single card 100m away from the host.  Unfortunately no G-sync support.
 
 

It should be emphasized that this IS NOT Ethernet but HDbaseT.  It is a different spec and leverages different signaling over category cable. The two things they have in common is the physical connector and cabling.  (But to make things perfectly confusing, there is a 100 Mbit Ethernet channel encapsulated in the HDbaseT signal.)
 
Cabling matters a lot for HDbaseT.  The Belden cable being used in the video is extremely high quality and necessary to go the 100 m.  It is possible to run short distances (<15 m) using unshielded Cat5E, though for an install of any kind I'd still recommend shielded CAT6A.  Many vendors don't officially support transmission over anything less than that.
 
The power over cable is 802.11at based for up to 30W.  The HDbaseT spec has extensions to go all the way up to 100W over the cable, the goal being one single cable to drive a display.  Various other HDbaseT vendors implement power over cable via PoE pass through meaning if you want power over HDbaseT, you first have to connect a PoE source.  For others, including Advoli but not the model in the video, this is also how 100 Mbit Ethernet is embedded into the cable.  Off hand, I think that this Advoli card only supports two power-over-cable connections.  If they wanted to support more, they'd have to add more 6/8 pin PCIe power headers.
 
Not explored in the video are the RS-232 and USB extension functionality.  Yep, this card will pass USB 2.0 alongside video over the same cable making this a great long distance KVM solution.  The catch is that you have to plug in a USB header from the motherboard to the card for this and it connects to a USB hub on the carrier card itself so total USB bandwidth is limited by that one uplink (you can see this in a picture I've attached).  For keyboard/mouse, this is plenty but I wouldn't expect to be a able to move large files over a thumb drive quickly at the remote end.  One cable can pass video, audio, 100 Mbit Ethernet (not supported on the model shown in the video), RS232, IR, USB and power simultaneously.  There are some command line tools that permit exploring things like signal quality, power-over-cable usage and how RS-232 is forwarded etc.  I wouldn't say they're end user friendly but they're fine for a system administrator.
 
They also make versions with nVida Quadro MXM cards.  These still have six RJ45 connectors but only four outputs.  The other two connectors are for Ethernet pass through.  This is where MXM card swapping and being unsupported comes into play.  The AMD MXM cards have six outputs on the MXM connector where as nVidia only has four outputs.   Putting a nVidia card into the Advoli AMD carrier will only permit four of the six outputs to work.  The other reason why card swapping is unsupported is that high power cards could eliminate the power-over-cable outputs that it supports.  
 
Over all this is a nice but also niche product.  Most of the use cases for multiple long range extenders also incorporate some video switching or can be just as easily accomplished by adding an external extender.  The big use-case for this is digital signage from a central host PC, absolutely the lowest video latency over distances or fixed content displays in an operations center (SOC/NOC/IRC etc.).  It appears to be a good product but you have to weigh the need for specifically this vs. alternatives in your use-case.
 
I've attached some pictures when I visited the Advoli booth at last year's Infocomm trade show.