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
Last week Ryan and I had a meeting with Offir Remez, Co-Founder, President and Vice President of Business Development at Lucid. It went on a while, as Offir described Lucid and we peppered him with questions. There are several points worth mentioning about the functionality of Virtu MVP, which Offir was happy to share with us so we could share with you.
The first, to reiterate, is that Virtu requires a system with an integrated GPU (iGPU, such as a mainstream Intel Sandy/Ivy Bridge processor or an AMD APU) as well as discrete graphics (dGPU, AMD or NVIDIA). Without this setup, Virtu will not do anything. This also means that both the drivers for the iGPU and dGPU have to be installed at the same time. Lucid have validated the several previous generations of discrete cards (AMD 5xxx and above, NVIDIA 4xx and above), but are keen to stress that the technology should work with any card, including 8800 and 2400 series—they don’t have the time to validate every configuration being the point here.
In terms of how Virtu functions, it is important to understand the concept of being able to perform what was mentioned on the previous page—being able to manipulate what the GPU does and what it does not do. The underlying technology of Virtu is that the environment is virtualized. This means that instead of the GPUs working on top of the operating system, Virtu adds in a middle layer between the operating system and the GPU. This way, Virtu can manipulate everything that the operating system wants to say to the GPU, and vice versa, without either of them knowing that there is a middleware layer.
The second is most important perhaps, which I will go into later. Virtual V-Sync and HyperFormance will only make a difference in the following circumstances:
a) You suffer from visual tearing in your games, or you actively use V-Sync
b) If your setup (screen resolution and graphics settings) perform better than your refresh rate of your monitor (essentially 60 FPS for most people). If you have less than this, then you will probably not see any benefit.
I should mention some terminology. Virtu works in two modes, i-Mode and d-Mode, depending on if the display is connected to the integrated graphics or discrete graphics:
Let us go over the technologies again quickly.
Virtual V-Sync: Making sure the last fully rendered frame is shown, without tying the CPU, display and input down to 60 Hz (or the refresh rate of your display) and increasing responsiveness.
Virtual V-Sync works by making the integrated GPU probe the rendering buffer on the discrete card. In i-Mode, it transfers the last completed frame that the GPU has processed into the iGPU, and then when the display requires a refresh, it can process that entire frame. This results in no tearing, and the latest frame being shown. This means that Virtual V-Sync only works when your frame rate is greater than the refresh rate—if it is worse, then Virtual V-Sync will show stuttering in the periods where the next frame is not complete in time, thus it shows an old frame.
To reiterate, Virtual V-Sync will only work if your frame rate is greater than your refresh rate, usually 60 FPS. It does not increase frame rates, but removes tearing while keeping the responsiveness of the input system (mouse) better than normal V-Sync.
HyperFormance: Predicting which frames (or rendering tasks) will never be shown and taking them out of the pipeline so the GPU can work on what is needed (which also increases input responsiveness).
HyperFormance is a tool that uses the iGPU to examine rendering tasks. It applies a prediction algorithm to calculate how long the next few frames will take to render. If the refresh rate of the monitor means that the next two frames have no chance of being shown, then HyperFormance removes all applicable rendering tasks for those frames. Some rendering tasks still need to be processed (certain features like smoke or iterative algorithms), however a lot can be nullified. It then does the predictive algorithm and probe again; when it finds a frame which needs to be rendered for the refresh rate, it will make sure all rendering tasks are done on the GPU.
As the FPS counter is increased at the beginning of a frame, this makes it look like the FPS has shot up as rendering tasks are removed. However, this is a poor indication of what the software does—it means that the responsiveness of the input peripherals (e.g. mouse) goes up in line with this ‘FPS’ number.
This means, HyperFormance increases responsiveness and makes FPS meaningless. In order to work, HyperFormance will only make a difference if your normal frame rate is greater than your refresh rate, usually 60 FPS.
Essentially, the FPS number you get from HyperFormance becomes a measure of system responsiveness, not GPU output.
If the prediction algorithm for HyperFormance is wrong and a frame takes longer to render than predicted, the system will show the last fully rendered frame, causing stuttering. Lucid have asked us to make clear that this should be reported to them as a bug, stating the system being used, settings, and version of Lucid MVP.
What you will see on a system
As the technologies are all based around a virtualization layer, there is a little overhead in processing. Information from the frame buffer has to be passed from the iGPU to the dGPU and vice versa over the PCIe bus. If your screen resolution is high (~2MP for 1920x1080, ~4.1 MP for 2560x1600), this means data transfer could potentially be limited by bandwidth, but it should not be at 5GBps. The virtualization layer actually adds in latency, per frame and per call.
For Virtual V-Sync, in i-Mode, frames need to be transferred between dGPU to iGPU, and then displayed through the iGPU. The latency for this, or so we are told, should be around 3% for high frame rates greater than 100 FPS, compared to that from d-Mode. d-Mode requires less overhead as frames do not need to be copied for display, but commands still have to go between the iGPU and dGPU.
For HyperFormance, in i-Mode, we still have to transfer frames to output on the integrated graphics. However, as the iGPU is also dealing with rendering calls for parts of the frame, this is the main transfer between the two graphics units. In d-Mode, we have a similar experience to Virtual V-Sync.
The upshot of how all this works comes in the form of several numbers and a feature, depending on which settings you choose. The table below shows a theoretical result of what you can expect to get with these technologies in d-Mode mode. Here we are going with Lucid’s standard predictions—Virtual V-Sync and HyperFormance causing a 3% reduction in frame rates above 60 FPS, Virtual V-Sync removing tearing and utilizing more of the GPU, and HyperFormance removing 30% of rendering tasks.
FPS | Refresh Rate | Tearing | On-Screen FPS | Responsiveness | |
Normal | 100 | 60 | Yes | 60 | 100 |
In Game V-Sync | 100 | 60 | No | 60 | 60 |
Virtual V-Sync | 100 | 60 | No | 60 | 100 |
HyperFormance | 100 | 60 | Yes | 60 | 130 |
Virtual V-Sync + HyperFormance |
100 | 60 | No | 60 | 130 |
As you can see, both Virtual V-Sync and HyperFormance are designed to work together, but are available in the software as separate options. This is, as we found out, because there may be the odd setup that does not like a particular game/setting, or that it changes the feel of a game too much to what the user is used to. Thus, Lucid allows users to chop and change with whatever feels good to them.
The ultimate realization is this—the FPS counter shown in games when using Virtu MVP no longer means the true FPS value of the output of your GPU. The FPS counter is now a measure of responsiveness. So please be wary when reading reviews using this technology and of the analysis of the results—the refresh rate of the monitor is also a vital component of the results.
Caveats of the Technology
There are a few bumps in the road, as expected with anything new, and we put these to Lucid for answers. The first is the possibility of stuttering as mentioned above when the prediction algorithm cannot cope with a massively different frame to previous—Lucid has asked us to reiterate that this should be reported as a bug.
In terms of multiple GPU users, Lucid says they are not specifically designing the software for them. However, they have said that multiple GPU users are more than welcome to assign Virtu MVP to their games to see if it works—Lucid just will not be validating multi-GPU scenarios due to the additional QA required.
There are currently three main titles as of today that Lucid are still fine-tuning for HyperFormance—Crysis 2, Lost Planet 2, and most importantly, Battlefield 3. These games are currently not validated as they are experiencing stuttering, which Lucid hopes to fix. This is more than likely related to the way the software interprets the rendering calls and the adaptive prediction algorithm specifically for these titles.
There is also an issue of licensing. Lucid MVP is a licensed bit of software, requiring motherboard manufacturers to write specific BIOS code in order for it to work. This obviously costs some money to the motherboard manufacturers as well. Some motherboard manufacturers will be licensing it for their back catalogue of hardware (H61, H67), whereas some will focus only from Z77/H77 onwards. There is a possibility that we will see SKUs that do not have it, either through design or as a sales decision. Despite this, Lucid expects Virtu MVP to be enabled on 100 different Z77/H77 motherboards, and up to 10 million motherboards shipped in the next twelve months.
In addition, as graphics cards become more powerful, HyperFormance obviously will increase, surpassing the responsiveness of the input system. Thus running a 7970 with an old DX9 game at 1024x768 may make your FPS hit 1500+, but your responsiveness will be limited by the system.
Future for Virtu MVP
On paper, Virtu MVP sounds like a great technology to have if you are a gamer demanding a more responsive system for 'immersive' gameplay. If Lucid can make Virtu MVP live up to the software’s lofty goals (and not be dogged by new game releases), it sounds good. Arguably, the best place to see this technology would be with upcoming consoles. If it is integrated into the console, and part of the validation of future games is that is has to run with Lucid, it could mean a lot cleaner and more responsive gameplay.
So much for the new technologies; what about the motherboards themselves? In this preview (we will come back at a later date with Ivy Bridge performance numbers), we aim to cover as many boards as possible to give you an idea of what is available on the market. Up first is the ASRock Z77 Extreme4.
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...