Intel Z77 Panther Point Chipset and Motherboard Preview – ASRock, ASUS, Gigabyte, MSI, ECS and Biostar
by Ian Cutress on April 8, 2012 12:00 AM EST- Posted in
- Motherboards
- Intel
- Biostar
- MSI
- Gigabyte
- ASRock
- Asus
- Ivy Bridge
- ECS
- Z77
ASRock Z77 Extreme6—Visual Inspection
With the Extreme6, compared to the Extreme4, there are a significant number of changes, both visual and in terms of features. For a start, the heatsink design is more pronounced, using something similar to their X79 range in terms of black and gold ridged and edged surfaces. The VRM heatsink design is more substantial than the Extreme4, even though online it states it is still only an 8 + 4 VRM design—actually looking at the board, it seems more of a 10 + 4 design.
By looking at the motherboard, you would assume that it would support three-GPU setups. Unfortunately, this third full-length PCIe lane is only PCIe 2.0 x4, rather than splitting up the PCIe 3.0 lanes x8/x4/x4 or using a PLX chip. The MSRP for this board should be around $177, indicating that perhaps that is too cheap a board for one of the expensive PCIe 3.0 expansion PLX chips.
Onboard is also an mSATA port, right in the middle between the first PCIe slot and the PCI slot. Above the PCIe slots is a 4-pin molex power connector to provide extra power to the PCIe slots, although I am kind of getting tired of seeing it put in this location. If anything, it should be at the bottom end or beside the 24-pin power connector, as having it above the PCIe slots just means that there will be cables all over the place.
One other less obvious change to the Extreme4 is that there is a Floppy drive header on board. Yes, you heard me right—floppy drive! It seems odd now to include this legacy connection. It still has a place in industrial concepts (where a machine uses floppy drives and costs 1000x more than the PC processing its data), but not particularly on a higher end product which may be geared towards gaming and overclocking. Perhaps if ASRock are the only ones, then it creates a niche just for them.
In terms of fan headers on board, we have one three-pin beside the 8-pin 12V power connector, two CPU headers (one 4-pin, one 3-pin) just to the right of the top heatsink, two chassis three-pin headers beside the molex connector, and another 4-pin chassis header on the bottom of the board. On the right hand side, the USB 3.0 connector has been placed beneath the 24-pin ATX power connector, followed by the SATA ports. Like the Extreme4, we have the PCH SATA ports (two SATA 6 Gbps and four SATA 3 Gbps) and two extra SATA 6 Gbps from an ASMedia ASM1061 controller.
Around the larger chipset heatsink, we have power/reset buttons and a two digit debug display, both of which I personally like to see as a reviewer (makes my job a bit easier) but also helps overclockers. On the south side of the board, apart from that floppy connector I mentioned, we have a COM port, front panel audio, and an array of USB 2.0 headers.
PCIe layout is similar to the Extreme6, with a PCIe x1, PCIe 3.0 x16/x8, an mSATA connector, PCI, PCIe 3.0 x8, PCI, and a PCI 2.0 x4. This allows a user to use a dual GPU setup, and still have access to a PCIe x1 and x4.
Aside from the bowed picture from ASRock, we have something similar to the Extreme4 for the IO back panel, though this time with a DisplayPort output. From left to right, we have a combination PS/2 port, two USB 3.0 ports (blue), a D-Sub port, DVI-D, DisplayPort, HDMI, a ClearCMOS button, two USB 2.0 (red), an IEEE1394 port, eSATA, gigabit Ethernet, two more USB 3.0 (blue), and audio outputs including an optical SPDIF.
Board Features
| ASRock Z77 Extreme6 | |
| Size | ATX |
| CPU Interface | LGA-1155 |
| Chipset | Intel Z77 |
| Power Delivery | 8 + 4 |
| Memory Slots |
Four DDR3 DIMM slots supporting up to 32 GB Up to Dual Channel, 1066-2800 MHz |
| Video Outputs | DisplayPort, HDMI 1.4a, DVI-D, D-Sub |
| Onboard LAN | Broadcom BCM57781 |
| Onboard Audio | Realtek ALC898 |
| Expansion Slots |
2 x PCIe x16 Gen3 (x16, x8/8) 1 x PCIe x16 Gen2 (x4) 1 x PCIe x1 Gen2 2 x PCI 1 x mini PCIe |
| Onboard SATA/RAID |
2 x SATA 6 Gbps (PCH), Support for RAID 0, 1, 5, 10 2 x SATA 6 Gbps (ASMedia ASM1061) 4 x SATA 3 Gbps (PCH), Support for RAID 0, 1, 5, 10 |
| USB |
Two USB 3.0 at rear (PCH) Two USB 3.0 at rear (Etron EJ168A) One USB 3.0 header (PCH) |
| Onboard |
4 x SATA 6 Gbps 4 x SATA 3 Gbps 1 x Floppy Connector 1 x IR Header 1 x CIR Header 1 x COM Header 1 x SPDIF Header 1 x 4-pin Molex power connector Power/Reset Buttons Two Digit Debug LED 6 x Fan Headers Front panel audio connector 3 x USB 2.0 headers (support 6 USB 2.0 ports) 1 x USB 3.0 header (supports 2 USB 3.0 ports) |
| Power Connectors |
1 x 24-pin ATX connector 1 x 8-pin 12V connector 1 x 4-pin Molex for PCIe |
| Fan Headers |
2 x CPU Fan Header (one 4-pin, one 3-pin) 3 x CHA Fan Headers (one 4-pin, two 3-pin) 1 x SYS Fan Header (one 3-pin) |
| IO Panel |
1 x Combo PS/2 Port 1 x DisplayPort 1 x HDMI 1.4a 1 x DVI-D 1 x D-Sub 1 x Optical SPDIF 2 x USB 2.0 4 x USB 3.0 1 x IEEE1394 1 x Gigabit Ethernet 1 x Clear CMOS Audio Outputs |
| Warranty Period | 3 years from date of purchase |
| Product Page | Link |
Nothing immediately jumps out from the board features list aside from the differences to the Extreme4. This is a quite good package for an MSRP of $171.
Facebook
Twitter
RSS
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 queuesas 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...