GIGABYTE GB-BXi7H-5500 Broadwell BRIX Review
by Ganesh T S on January 29, 2015 7:00 AM ESTFinal Words
The GIGABYTE GB-BXi7H-5500 provided us with the opportunity to take a look at what Broadwell-U can deliver. The migration from 22nm to 14nm has allowed for higher base clocks while maintaining the same power envelop. The performance delta over the Haswell-U-based GB-BXi7-4500 (particularly, on the graphics side) is notable. That said, while migrating from Sandy Bridge or Ivy Bridge is a no-brainer, there is not enough on offer to recommend migrating from a Haswell-based mini-PC.
From the perspective of the BRIX itself, the GB-BXi7H-5500 has two major downsides, and both of them are related to the networking subsystem. Considering that the i7 SKU is the 'premium' SKU in this lineup, use of a 1x1 802.11ac (Intel AC3160) card is disappointing. It would have been nice to have the AC7260 or AC7265. The Broadcom BCM4352 is even more preferable. In addition, GIGABYTE should have opted for an Intel LAN chipset instead of a Realtek one for this high-end configuration.
One of the interesting differentiating features is the availability of NFC. Along with the unit, GIGABYTE also supplied a NFC tag. The accompanying driver DVD has a NFC app (Windows program) which allows creation of profiles to link with the tag. These profiles could be associated with web addresses or files / programs in the system. Tapping the tag against the unit's lid activates the profile. Right now, this is a basic application. GIGABYTE indicated that they are working on bringing more functionality to the app and making it easier to use.
The pricing of the Core i7-5500U makes it attractive for high-end ultrabooks, but the BXi7H-5500 manages to get it to the consumer in a UCFF PC at a reasonable price ($509, when Intel apparently sells the CPU alone for $393). All in all, GIGABYTE has managed to deliver the right balance of price, power, size and thermal / acoustic design in the GB-BXi7H-5500. It remains to be seen what Intel is able to offer with the NUC lineup and how the NUCs will complement and/or compete against the Broadwell BRIX units.
Facebook
Twitter
RSS
53 Comments
View All Comments
kgh00007 - Thursday, January 29, 2015 - link
No mention of the i7-5500U turbo speeds?3GHz single core turbo and 2.9GHz dual core turbo, source notebookcheck.
voicequal - Saturday, February 7, 2015 - link
These were provided in a previous article.http://anandtech.com/show/8814/intel-releases-broa...
Shadowmaster625 - Thursday, January 29, 2015 - link
The only people who would pay that much money for so little performance already gave their money to apple.gr8pcguy - Thursday, January 29, 2015 - link
Doesn't it bother anyone that the box is printed with the statement "Supports 2.5" Hard Drivers"? Obviously Gigabyte needs to do a bit of QA on their package production line!Refuge - Thursday, January 29, 2015 - link
Ha! I noticed this to when I first clicked the link.Hopefully they fix the typo before full production for consumers. :P
skifiddle - Saturday, January 31, 2015 - link
to?Refuge - Thursday, January 29, 2015 - link
The Brix, now supports 2.5" Hard "Drivers"Is this some kind of new, super strong drivers for our HDD's?
And yes, this is me being sarcastic :P
tspacie - Thursday, January 29, 2015 - link
The huge iGPU BIOS carve-out intrigues me. Does the iGPU not handle allocations in shared system memory (in 4K pages) ?Pissedoffyouth - Thursday, January 29, 2015 - link
Nah, neither does AMD APUs. You lose whatever you allocate.rootheday3 - Friday, January 30, 2015 - link
the BIOS carve out is not necessary. The bios reserves a little (~32mb) for some internal data structures used by the driver (graphics page tables, memory for content protection, auxilary buffer for display frame buffer compression). Otherwise, the driver gets allocations out of system memory from the OS to map into the graphics page tables.the DVMT pre-Allocated is a hold over from Windows XP driver model and is no longer meaningful since Vista. In fact, if the OS comes under memory pressure and starts asking the driver to stick data into that "dedicated" segment, the PCI aperture copy/swizzle process used to load the data is slower than if the driver simply used OS allocations. Likewise, on standby/hibernate the OS "pages out" all the data from dedicated segment to "normal" memory which is slow... whereas for normal system allocations on iGPU, the pages are just "there" - no extra copy required.
The sole exception is a handful of games that are incorrectly coded to look for "Dedicated" graphics memory from OS API call and then make bogus decisions based on that (e.g. refuse to run=>PES, restrict available game resolution/settings =>SW:TOR, older Total War games, render incorrectly because they think they don't have room to load textures =>GTA IV). For this small set of games, having the BIOS option to preallocate memory (which the driver won't actually use) is a workaround to fool them into running correctly.