Gigabyte GA-Z77X-UD3H WiFi—Visual Inspection

Black and blue seems to be the order of the day when it comes to mainstream boards, as indicated by some of the previous boards but also with the Gigabyte GA-Z77X-UD3H WiFi. Perhaps there is a sale on black PCBs and blue heatsinks?

Joking aside, Gigabyte intends to release two high- end boards initially—the Z77X-UD5H and the Z77X-UD3H, both in regular and WiFi variants. The WiFi variant comes with a PCIe x1 WiFi card to be used in the first PCIe slot on the board, and aerials for the outside of the case.

We have the Z77X-UD3H WiFi in to review for the launch of Ivy Bridge, which should retail for around $160 MSRP. Gigabyte has chosen a few different directions regarding which controllers are on the motherboard. This should provide interesting results when it comes to performance.

The VRM power delivery weighs in at 6 + 4 phase, which is by no means substantial (remember the ASRock Z77 Extreme4 was 8 + 4 and less expensive), and comes paired with a relatively small blue heatsink next to the socket. I’ve noticed that Gigabyte tend to have their memory closer to the socket than most other manufacturers, presumably in the name of performance due to shorter interconnects, but the downside is that it can restrict big air coolers. Nonetheless, it all still conforms to Intel specifications, and there is actually a large gap to the south of the socket.

In terms of fan headers, there are only two within reach of the socket. We have a 4-pin CPU header at the top near the memory slots, and another near the power/reset/ClearCMOS buttons at the top right of the board. The other three headers on board are found at the bottom—one 4-pin beside the SATA ports, one 4-pin next to the USB headers and another 4-pin beside the TPM.

Along the right hand side of the motherboard, Gigabyte has given us a different style of power/reset/clear CMOS button that I have not seen before. The power button is big and red, whereas the other two are relatively small. These will be of use to reviewers and overclockers, however having the ClearCMOS the same size and shape as the reset button may lead to several bad fumblings for the right button followed by several four-letter expletives.

Further down is another style choice—an additional power connector for the PCIe and system, but this case it is a SATA power connector. I prefer this to the awkward molex connectors we see on other products. Below this are the standard six SATA ports from the PCH—two SATA 6 Gbps and four SATA 3 Gbps. Below this is the handy two-digit debug display.

Along the bottom of the board, from left to right, we have the front panel audio, SPDIF header, a 4-pin fan header, the TPM header, three USB 2.0 headers, and another fan header. At the top of the PCIe is our mSATA connection, useful for mSATA SSDs and boot drives to save case space. In terms of PCIe, Gigabyte has installed a little nugget of common sense, giving enough space between the first two full-length PCIe for GPUs. However, in the x1, x16 (x8 in multi-GPU), x1, x1, x8, PCI, x4 setup, only the first two full length PCIe are for graphics output—the final one is a PCIe 2.0 x4 connector. This would be better served if it were a slightly different color to the other PCIe x16/x8 connectors. Also with two full length GPUs on board, the user will have access to two PCIe x1 connectors but the PCI connector is blocked.

I know Gigabyte will make a few people jump with joy in relation to the back panel layout—no USB 2.0! From left to right, we have a PS/2 combination port, two USB 3.0, D-Sub, DVI-D, an Optical SPDIF output, HDMI, DisplayPort, two more USB 3.0, two eSATA, gigabit Ethernet, a final two USB 3.0, and audio outputs.

Board Features

Gigabyte GA-Z77X-UD3H Wifi
Size ATX
CPU Interface LGA-1155
Chipset Intel Z77
Power Delivery 6 + 4
Memory Slots Four DDR3 DIMM slots supporting up to 32 GB
Up to Dual Channel, 1066-1600 MHz
Video Outputs DisplayPort, HDMI, DVI-D, D-Sub
Onboard LAN Atheros
Onboard Audio Via VT2021
Expansion Slots 2 x PCIe x16 Gen3 (x16, x8/8)
1 x PCIe x16 Gen2 (x4)
3 x PCIe x1 Gen2
1 x PCI
Onboard SATA/RAID 2 x SATA 6 Gbps (PCH), Support for RAID 0, 1, 5, 10
4 x SATA 3 Gbps (PCH)
1 x mSATA connector (shared with SATA2_5)
2 x eSATA 6Gbps (Marvell 9172), RAID 0, 1
USB Six USB 3.0 at rear (2 PCH, 4 VIA VL800)
One USB 3.0 header on board
Three USB 2.0 headers on board
Onboard 4 x SATA 3 Gbps
2 x SATA 6 Gbps
1 x mSATA Connector
5 x Fan Headers
1 x USB 3.0 Header
3 x USB 2.0 Headers
1 x Front Panel Header
1 x Clear CMOS Button
1 x TPM Header
1 x SPDIF Output
1 x SATA Power Connector
Power Connectors 1 x 24-pin ATX connector
1 x 8-pin 12V connector
1 x SATA Power connector
Fan Headers 1 x CPU Fan Header (4-pin)
4 x CHA Fan Headers (4-pin)
IO Panel 1 x Gigabit Ethernet
Audio Outputs
1 x DVI-D
1 x D-Sub
1 x DisplayPort
1 x HDMI
2 x eSATA 6 Gbps
1 x Combo PS/2 Port
6 x USB 3.0
1 x Optical SPDIF Output
Warranty Period 3 Years
Product Page Link

One of the odd choices of Gigabyte is their network and audio controllers. On near every board I have reviewed, we get either a Realtek, an Intel or a Broadcom for the network, and a Realtek or Creative audio solution. Gigabyte has decided to jump in with an Atheros network controller, and a Via VT2021 audio. It will be interesting to see if this has an effect on our test capabilities.

ASUS P8Z77-V Deluxe Gigabyte GA-Z77MX-D3H
Comments Locked

145 Comments

View All Comments

  • Iketh - Sunday, April 8, 2012 - link

    "handling input in a game engine" means nothing here. What matters is when your input is reflected in a rendered image and displayed on your monitor. That involves the entire package. Lucid basically prevents GPUs from rendering an image that won't get displayed in its entirety, allowing the GPU to begin work on the next image, effectively narrowing the gap from your input to the screen.
  • extide - Tuesday, April 10, 2012 - link

    I am sure he knows that. He was just giving a bit of detail as to his exact experience, of which I would bet is far more than most people on here. You have to be very aware of things such as latency and delay when you are handling input in a game engine. I agree with the OP and am skeptical also. The bit that makes me most curious is the transfer of the fully rendered screens from one framebuffer to the other, that has to add some latency, and probably enough to make the entire process worthless. It's not like Lucid has a good track record on stuff like this, I mean we all know how their cross platform SLI/CF took off and worked so well....
  • Iketh - Wednesday, April 11, 2012 - link

    Why would you need to physically copy framebuffers?? I'm sure pointers are used...

    I have no idea if this has tangible benefits, but theoretically it does. None of us know until we can test it. I'm more inclined to discredit the people already discrediting Lucid, despite Lucid's track record. That's what you call hating.
  • Iketh - Wednesday, April 11, 2012 - link

    excuse me, you're right... it has to copy the frame from gpu to igpu... what kind of crap tech is this???
  • ssj3gohan - Sunday, April 8, 2012 - link

    Personally, I'm absolutely uninterested in anything 'high-performance', especially fancy gaming stuff. Not to say that I don't think that's a valid market niche, but I see other possibilities.

    I'm really looking forward to new thin ITX boards with built-in DC-DC converter (i.e. running directly off a 19V brick), and I am especially wondering whether Intel (or Zotac, possibly) is going to build a golden board this time around. Last time, they made DH61AG which was a nice board, but lacked an msata port (kind of a must for a truly thin computer) and 'only' had an H61 chipset.

    With H77, I expect it will be possible to make a thin ITX board with USB 3.0 and a fast on-board SSD option, combining this with an HD 4000 equipped processor would enable users to build a truly thin (sub-4 inch thick) computer that fits on the back of their monitor but still provides ample computing power.
  • Senti - Sunday, April 8, 2012 - link

    It sounds to me that Lucid Virtual V-Sync is just glorified triple buffering with a lot of marketing and a bit of overhead for transferring frames and powering two video cards instead of one. I'm very skeptical on the HyperFormance too.
  • Cavalcade - Sunday, April 8, 2012 - link

    It seems a bit more involved than triple buffering, more like having 2 buffers where the back buffer is not flipped until it is fully rendered. Seems like this would lead to more stuttering, and given the number of times they asked Mr. Cutress to reiterate that this would be a bug, it may be something they are seriously concerned with.

    Thinking about it a little more, I'm not sure what advantages this system would have over a system with separated input and rendering modules. The academic side of me is extremely interested and hopeful, but the practical developer side of me is going to require a lot more to be brought on board.
  • Iketh - Sunday, April 8, 2012 - link

    Separate input and rendering modules, as I stated in an earlier post, means nothing. They allow for a responsive mouse cursor, for instance. But, when you actually provide input that alters the RENDERED WORLD, you have to wait for that input to reflect on screen. It doesn't matter how perfectly the software solution is architected, you still have to wait for the rendering of the image after your input.

    Lucid simply prevents renders that never get displayed in their entirety, allowing the GPU to work on the NEXT image, shortening the time from your input to the screen.
  • Cavalcade - Monday, April 9, 2012 - link

    The comment was to indicate that while I have experience writing input systems, rendering is still relatively new to me; simply a qualifier of my impression and opinion.

    The way I am understanding Lucid, it is attempting to preempt displaying a frame that is not fully rendered in time for the next screen refresh. By presenting a virtual interface to both the GPU and the application, the application believes the frame has been rendered (displaying user input at that time) and proceeds to render the next frame. Thinking more about it, would this reduce the time interval between input reflected in frame one (which was preempted) and frame two (which will be displayed) so that rather than having input sampled at a fixed rate (say 60Hz) and displayed at a variable rate, input would be more closely tied to the frame for which it is intended.

    My interest is rising, but it still seems like a rather complex solution to a problem that I either haven't experienced, or which doesn't really bother me.
  • Iketh - Tuesday, April 10, 2012 - link

    it's not preemtively doing anything, except determining if a frame added to the queue will finish rendering in time... if not, it >>>>DOESNT LET THE GPU RENDER IT<<<< and places the previously rendered image in its place, allowing the GPU to immediately begin work on the FOLLOWING frame... that's it... it cuts unneeded frames from queues

    as for your input sampling rate question, that's entirely based on how the application is coded to handle input, lucid has nothing to do with this...

Log in

Don't have an account? Sign up now