GIGABYTE GB-BXi7H-5500 Broadwell BRIX Review
by Ganesh T S on January 29, 2015 7:00 AM ESTHTPC Credentials
The GIGABYTE GB-BXi7H-5500 is a compact PC, but, thanks to the 15W TDP CPU inside, it doesn't require a noisy thermal solution like what we saw in the BRIX Pro and BRIX Gaming units. Subjectively speaking, the unit is silent for most common HTPC use-cases. Only under heavy CPU / GPU loading does the fan become audible. However, as mentioned before, it still makes a good HTPC for folks who don't want to pay the premium for a passively cooled system.
Refresh Rate Accurancy
Starting with Haswell, Intel, AMD and NVIDIA have been on par with respect to display refresh rate accuracy. The most important refresh rate for videophiles is obviously 23.976 Hz (the 23 Hz setting). As expected, the GIGABYTE GB-BXi7H-5500 has no trouble with refreshing the display appropriately in this setting. In fact, in our recent tests, Intel's accuracy has been the best of the three.
The gallery below presents some of the other refresh rates that we tested out. The first statistic in madVR's OSD indicates the display refresh rate.
Network Streaming Efficiency
Evaluation of OTT playback efficiency was done by playing back our standard YouTube test stream and five minutes from our standard Netflix test title. Using HTML5, the YouTube stream plays back a 720p encoding. Since YouTube now defaults to HTML5 for video playback, we have stopped evaluating Adobe Flash acceleration. Note that only NVIDIA exposes GPU and VPU loads separately. Both Intel and AMD bundle the decoder load along with the GPU load. The following two graphs show the power consumption at the wall for playback of the HTML5 stream in Mozilla Firefox (v 35.0).
Differences in the power consumption numbers for the Broadwell and Haswell BRIX units can be attributed to changes in the version of Firefox as well as the drivers. Ideally, the Haswell-based unit ought to consume more power for the same workload - something brought out by the Netflix power consumption numbers shown below.
GPU load was around 13.03% for the YouTube HTML5 stream and 4.25% for the steady state 6 Mbps Netflix streaming case.
Decoding and Rendering Benchmarks
In order to evaluate local file playback, we concentrate on EVR-CP, madVR and Kodi. We already know that EVR works quite well even with the Intel IGP for our test streams. Under madVR, we used the default settings (as it is well known that the stressful configurations don't work even on the Iris Pro-equipped processors). The decoder used was LAV Filters bundled with MPC-HC v1.7.8. LAV Video was configured to make use of Quick Sync.
| GIGABYTE GB-BXi7H-5500 - Decoding & Rendering Performance | ||||||
| Stream | EVR-CP | madVR - Default | XBMC | |||
| GPU Load (%) | Power (W) | GPU Load (%) | Power (W) | GPU Load (%) | Power (W) | |
| 480i60 MPEG2 | 23.28 | 12.54 | 65.46 | 14.79 | 12.93 | 10.34 |
| 576i50 H264 | 20.18 | 11.46 | 74.94 | 15.44 | 22.15 | 10.73 |
| 720p60 H264 | 28.03 | 14.56 | 72.32 | 18.64 | 27.91 | 11.65 |
| 1080i60 MPEG2 | 29.87 | 14.40 | 48.78 | 19.73 | 27.75 | 11.88 |
| 1080i60 H264 | 32.24 | 16.06 | 49.99 | 20.24 | 31.04 | 12.21 |
| 1080i60 VC1 | 31.01 | 15.23 | 49.06 | 19.91 | 28.77 | 12.20 |
| 1080p60 H264 | 31.87 | 15.88 | 65.89 | 18.54 | 30.58 | 12.07 |
| 1080p24 H264 | 12.71 | 13.47 | 20.95 | 12.49 | 11.58 | 10.39 |
| 4Kp30 H264 | 29.87 | 20.01 | 93.85 | 38.24 | 17.67 | 12.32 |
The Intel HD Graphics 5500 throws us a nice surprise by managing to successully keep its cool with the madVR default settings. Only the 4Kp30 stream downscaled after decode for 1080p playback choked and dropped frames. Otherwise, there was no trouble for our test streams with either Kodi or MPC-HC / EVR-CP.
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.