Lucid’s ‘smarter vsync’ could revolutionize game performance

Just after publishing my Inside the second article, I jetted off to the Intel Developer Forum last week in order to soak up the latest info on industry happenings. Little did I know that I would end up having a very interesting conversation with the folks at Lucid about one of the more intriguing concepts we’d discussed in that article. Yet that’s exactly what happened, and we’re now able to relay some news about a “better vsync” implementation with the potential to revolutionize the way graphics solutions deliver consistent and responsive in-game motion.

We met with Lucid’s Founder and President, Offir Remez, to discuss Lucid’s recent developments, and our excitement grew as Remez introduced a new technology his company has developed, dubbed (perhaps tragically) HyperFormance. With his help, we peeled back the different layers of the onion in order to understand exactly what HyperFormance does and why it matters.

To understand Lucid’s new technology, we should start by establishing an understanding of Lucid’s existing technologies. The firm’s first product was the Hydra GPU load balancing chip, but the GPU virtualization technology it invented for Hydra became much more widely known thanks to a mistake Intel made: disabling the integrated graphics processor in its Sandy Bridge CPUs when a discrete GPU is installed in the system. Sandy Bridge’s IGP has a couple of distinctive features, such as hardware-accelerated QuickSync video transcoding and Intel’s WiDi display tech, that a power user might wish to enjoy, but most power users will want a discrete GPU for gaming, too. Lucid stepped in and bridged the gap with a software product called Virtu that enables simultaneous access to both QuickSync and the rendering power of a discrete GPU by virtualizing one of the two.

Remez told us Virtu has been a nice success for Lucid, since it’s bundled with practically every Z68 motherboard sold and has produced “good feedback” with “happy end users.” Remez also revealed Lucid operates a “silent activation server” that tracks user activations, and he described the attach rate for Virtu as “unbelievable.” What’s more, he said, preliminary data may indicate that almost half of the users are running Virtu in i-mode, where the display is connected to the Sandy Bridge IGP rather than the discrete video card. That is Lucid’s preferred configuration, and widespread use of it would show faith in the firm’s virtualization tech; i-mode configs virtualize the discrete GPU and use Lucid’s abstraction layer for in-game rendering. We’d probably tend to prefer d-mode, since it gives access to GPU-specific driver control panel features and the GPU maker’s game-specific tuning. Still, if users are happy with i-mode, it is a nice testament to the compatibility and performance of Lucid’s solution.

So far, our story of Lucid’s tech may be familiar, but it took a bit of a confounding turn at Computex this past year, when the company unveiled Virtu Universal—which works on more platforms, including AMD’s Llano IGP—and a puzzling new feature known as Virtual Vsync. Our report from the show relayed Lucid’s pitch for the product, which supposedly allows “frame rates well in excess of a monitor’s refresh rate without subjecting users to unsightly tearing.”

We were a little bit dubious about the product’s merits at the time, so last week, I asked Remez to explain more clearly exactly how it works. Turns out the basics are fairly straightforward. In a dual-GPU Virtu i-mode setup, where the IGP is connected to the display and the discrete GPU is handling game rendering, there’s a bit of a tricky question about how synchronization to the display’s vertical refresh rate will be achieved. With Virtual Vsync, the IGP communicates with the display and flips to a new frame buffer in between screen painting sessions, which typically happen 60 times per second.

That’s also pretty much how standard vsync works. Many users prefer to enable vsync to avoid the tearing artifacts that can be created by flipping to a new frame buffer in middle of a screen refresh. Most GPUs these days combine vsync with a technique known as triple buffering, in which completed frames are queued up in buffers, in order to ensure a new frame is always ready for display when the time comes. Triple buffering frees the GPU to render ahead and accumulate more frames in the buffers, but if the GPU produces frames at a rate faster than the display’s refresh rate, some frames inevitably will be discarded. Superficially, from the perspective of tools and benchmarks, conventional vsync has the effect of capping frame rates at the display’s refresh rate.

In the context of our newfound focus on frame latencies as a better measure of in-game performance, a virtualized version of vsync raises some tantalizing possibilities.

With Virtual Vsync, the GPU is free to render as many frames as possible. The IGP then only displays a subset of those frames, in conjunction with the display refresh, in order to prevent tearing. The elimination of tearing is Virtual Vsync’s primary benefit. Still, the fact that the game engine and the discrete GPU are running at a faster rate is apparent to applications, and Lucid has promoted that property of Virtual Vsync. Any utilities like Fraps or benchmarks that measure performance in frames per second will report frame rates higher than 60 FPS, so long as the system’s CPU and discrete GPU are up to the task of producing more frames.

That fact alone doesn’t seem, you know, terribly useful in the grand scheme of things. One could always simply disable vsync when running benchmarks, as is our standard practice. Higher FPS counts by themselves have little meaning.

However, in the context of our newfound focus on frame latencies as a better measure of in-game performance, a virtualized version of vsync raises some tantalizing possibilities, if it were to have some smarter logic built into it. In fact, in our conversation with him about multi-GPU micro-stuttering, AMD’s David Nalasco mentioned a “smarter” version of vsync as a potential means of reducing jitter or other forms of uneven frame delivery.

Turns out at least one smart engineer at Lucid has been thinking along the same lines. In fact, Lucid has built just such a technology, and that’s where the unfortunate name “HyperFormance” comes into the picture. HyperFormance is an evolved version of Virtual Vsync with additional intelligence that attempts to ensure optimal delivery of frames to the user. According to Remez, the HyperFormance algorithm has many inputs, including the display timing, CPU and GPU utilization, and what’s happening with user input devices. With all of that info at hand, the algorithm attempts to make sure frames are delivered in a timely fashion just as the display is ready to be refreshed.

One of the keys to making HyperFormance work is the fact that, in many cases, frames will have to be dropped or, without vsync, only partially displayed. After all, a GPU spitting out 100 FPS will overwhelm a display scanning at 60Hz, so something has to give. Lucid’s algorithm attempts to predict which frames are likely candidates not to be displayed—or to be displayed only very partially, contributing to tearing. Those frames are considered “redundant rendering tasks” and are subject to special treatment. Lucid can’t simply discard or refuse to handle those frames; doing so would cause problems. Instead, some work is still performed on redundant frames, such as texture loads, which are needed to keep caches warm and to preserve memory locality. Once those basics are performed, though, other work like pixel shader computations can be skipped, because that frame will never be shown to the user. Instead, the GPU finishes its work quickly, the game engine churns out another frame, and Lucid again estimates whether this next frame is a good candidate for display. By tightening that loop between the game engine, DirectX, and the rendering subsystem, the HyperFormance algorithm ensures that any frames fully rendered and sent to the display are very timely.

If it works well, HyperFormance ought to have several related benefits. Evened-out frame delivery in sync with the display should provide a smooth sense of motion, of course. That motion should be improved by the fact that the frames displayed would contain timely information—i.e., the latest updates to the underlying geometry in the game world. Furthermore, the immediacy of those frames should reduce the lag between user inputs and display updates. Remez contrasted the inherent delays in conventional triple buffering, where queuing up three frames at 60 FPS would add up to 48 milliseconds of lag, with Lucid’s scheme, where frames are delivered more or less “just in time” for the display refresh.

Make no mistake: if HyperFormance works as advertised, then it should be far from a gimmicky software feature; it could bring a true and tangible improvement in perceived gaming performance, a cut above anything currently offered by AMD or Nvidia. Remez told us Lucid has a host of patents in the works related to this technology, as one might expect.

HyperFormance in motion

We got a quick demo of HyperFormance in action on a gaming rig with a Core i5-2300 and a GeForce GTX 580 graphics card. The system was running Virtu in i-mode, with the display connected to the Sandy Bridge IGP’s video output. Lucid chose Modern Warfare 2 for this demo. Because it’s not especially CPU or GPU limited, MW2 presents a particular sort of challenge to the display subsystem. In the gun range area at the beginning of the game, frame rates in the on-screen Fraps readout averaged around 330 FPS—way faster than the display can handle. Without vsync enabled, one could see loads of tearing in each screen refresh, with multiple transition lines an inch or two apart onscreen. When Remez turned on HyperFormance, the tearing was banished and yet, if anything, the on-screen motion appeared to be faster and smoother than before. I didn’t get to play a multiplayer match or spend enough time with the system to comment strongly on its responsiveness to user inputs, but the HyperFormance-enabled config did seem to be very quick, too.

Jarringly, the Fraps frame rate counter shot up to over 600 FPS with HyperFormance turned on—a consequence of the Lucid software choosing, behind the scenes, to render some frames only partially. Remez pointed out the Fraps count wasn’t really a correct number, but he asserted that the higher FPS reading was an indication of responsiveness. I can see where he’s coming from there, because the benefits of a technology like this one can be difficult to convey. Still, after all of our recent work in this area, I’m developing an allergy to gaming performance results expressed in frames per second, especially in cases like this one. The key to HyperFormance is delivering the right frame at the right time, not an increased frame rate.

If you’re salivating at the prospect of using this technology yourself, remember HyperFormance requires a Virtu setup with both an IGP and a discrete GPU. Although Z68 motherboards are pretty popular, many gamers don’t have an IGP in their systems. Also, most laptops have only an IGP and nothing else.

When we expressed our consternation about the IGP + GPU hardware requirement to Remez, he quickly steered us to another demo of an early, in-development software product Lucid calls Virtu XLR8. This program is essentially a stand-alone version of HyperFormance capable of running on a single GPU. Remez said using only one GPU for the whole enchilada adds some overhead (though he didn’t use the word “enchilada,” sadly), but Lucid is in the early stages of building a solution anyhow.

The Virtu XLR8 demo was running on a laptop with a Sandy Bridge processor and an Intel HD 3000 IGP, again in Modern Warfare 2. Without XLR8, the Fraps frame counter hovered around 30 FPS and, since vsync wasn’t enabled, we saw ample visible tearing even at this low frame rate. Worse, the entire setup was slow enough that the game’s animations didn’t appear fluid, a song heard many times in relation to integrated graphics solutions.

When Remez turned on XLR8 and restarted the game, the whole experience was unexpectedly transformed. Yes, the tearing was suppressed and the Fraps FPS counter shot up, as we’d seen with HyperFormance before. More shocking, though, was how much smoother the entire game seemed to run. When you only have 30 or so frames your GPU can deliver in a second, it apparently pays to deliver those frames at the correct intervals. The Sandy Bridge IGP went from offering a rather poor gaming experience to a borderline acceptable one, thanks to Lucid’s algorithm. Both the visual quality of the game and its fluidity were clearly improved.

We want to spend more time with HyperFormance and a later, finished version of Virtu XLR8, but we’re compelled by the concept and by the two quick demonstrations of the tech we’ve seen. The next question many of us will be asking is how we can get our hands on the software. The first place HyperFormance will be available is in Virtu Universal MVP, Lucid’s new top-end product in its Virtu lineup.

Lucid issued a press release at IDF announcing, “Virtu Universal MVP is available to system platform manufacturers using Intel Sandy Bridge Z68/H67/H61, and other Intel integrated graphics, as well as many AMD processor-based PCs and notebooks.” We’re not yet aware of any motherboard or system makers who have licensed Virtu Universal MVP to ship with their products, but we’d expect adoption to take a little bit of time. For most of us, the larger issue is the fact Virtu is sold exclusively as a bundled software package, not as a stand-alone product end users can purchase for themselves.

Fortunately, Remez told us Lucid is considering other avenues for its software sales, given the potential appeal of the HyperFormance algorithm and especially of Virtu XLR8. He confided that his hope was to see XLR8 technology licensed by Intel and built right into its IGP graphics drivers. Such an arrangement would be quite the coup for, say, the gaming responsiveness of Ivy Bridge graphics. Intel Capital helped to fund Lucid, and that relationship was obviously instrumental when Intel pushed Virtu as a solution to the Z68 QuickSync dilemma. Still, the integration of XLR8 into Intel’s graphics drivers was just Remez’s ambition when we spoke with him, nothing like a done deal. Lucid’s other obvious option is to sell its Virtu products directly to end users, including PC gamers looking for an improved experience. As far as we know, nothing has been decided on that front yet, but Lucid is eyeing the possibility carefully.

We’d very much like to see a version of XLR8 that runs on a single, discrete GPU or perhaps even a mismatched team of discrete GPUs, if the overhead of doing it all on one chip is too great. Although we ran out of time before we could discuss this issue with Remez, we’re also curious about whether a HyperFormance-type algorithm could be the answer to the multi-GPU micro-stuttering problems we’ve recently encountered. Of course, Lucid has a different solution, in its Hydra chip, for multi-GPU load balancing. Still, we can’t help but wonder if a software-only option for multi-GPU load balancing—with HyperFormance smarts built in—might be feasible.

Regardless, Virtu Universal MVP is already a real product, and the question now is whether key decision-makers in the industry—and end users—will understand the benefits of a technology like HyperFormance. If they do, and if Lucid’s software can deliver on its theoretical promise, then we may have a minor revolution in the way we think about GPU and gaming performance on our hands.

Comments closed
    • technogiant
    • 8 years ago

    Well, as I can’t seem to find Virtu Universal MVP software either as stand alone or bundled with a motherboard then I’m going to guess that its not available and that “Remez” got his wish…ie that it’s being built into the Ivybridge graphics driver?
    I guess this would be the ideal option for both Intel who have been assisting with funding and for Lucid as if it was just released as software it would be pirated and probably hacked to run with AMD processors.

    Only trouble with that is that it would not then be available for standard non igp cpu’s with discrete gpu setups.
    Which for me is a pity as I was fancying a SB-E with possible upgrade path to IvyB-E.
    So the answer may be to invest in a 120Hz monitor and just use vsync after all :-/

    • xiaomimm
    • 8 years ago
    • xiaomim
    • 8 years ago
    • kamikaziechameleon
    • 8 years ago

    Love lucids tech but they just don’t seem to have a prevalent presence in the market and getting products that include there tech is both difficult and costs a notable premium. Hydra has pretty much died off, just look for it on newegg. I’m intrigued by this article but I’m dubious on the outlook of how this will ultimately help us actually get a better user experience and when.

      • BobbinThreadbare
      • 8 years ago

      Well this does have the advantage of being a software solution. If they look into digital distribution it could really cut down on the price.

    • kamikaziechameleon
    • 8 years ago

    No better time to look at this article than now. I watch the original teaser trailers for BF3 and they have an implied amount of tearing that was quite a put off visually.

    I hope to be able to not only achieve a better visual fidelity through attention to microstuttering but also to find improved performance. I was hoping to run a dual GPU config for BF3 but now I’m simply waiting for some legit support for the legitimate fidelity issues. While Lucid does make great tech their market penetration is extremely uneven. I would really like to see wider adaptation and support of their products by high end Mobo makers.

    • sigher
    • 8 years ago

    “revealed Lucid operates a “silent activation server” that tracks user activations”

    That’s just great that is.. the companies are starting to admit it publicly now. and getting away with it.

      • yogibbear
      • 8 years ago

      That was the first thing that made me sit up and concentrate when reading this article… I wonder if you have to register or something to get it installed or if it is truly a silent activation….

    • Taircron
    • 8 years ago

    So – who can I give money to to get an MVP install of Virtu? I’m about to buy a new Asus motherboard, but from what I can tell, they only ship the ‘basic’ version.

    Let me be frank: I have money, and want this horribly named “HyPerformance”. Who do I give money to?

    • Anomymous Gerbil
    • 8 years ago

    Question from a dummy, that I can’t fathom from the article:

    Ignoring HyperFormance, what’s the difference between Virtual Vsync and “normal” vsync/triple buffering? Both seem to work by producing more frames that the vsync rate, and throwing away a subset that can’t be used.

    Is the difference in the number of extra frames that can be built, or in deciding which frames to throw out, or..?

    • Damage
    • 8 years ago

    I’ve updated the article to:

    -Correct Offir Remez’s title
    -Remove the suggestion that HyperFormance requires i-mode (Lucid tells us they have d-mode, too.)
    -Clarify that Lucid’s usage numbers on i-mode are partial

    Just FYI. Thanks!

    • doulos1382
    • 8 years ago

    I got a question. Maybe it has been answered many times, but I just would like to be sure.

    What happens when you enable VSync and your gpu renders frames below the 60fps mark?

    Sometimes when i am playing metro or crysis I disable Vsync because my average fps is at 40-50 range.

    Thx in advance

      • Damage
      • 8 years ago

      In that case, some frames will be painted to the screen multiple times before a new frame is drawn. You don’t have tearing, but it just feels slow.

        • doulos1382
        • 8 years ago

        Thanks for the answer. That´s what I thought.So, do you recommend to disable vsync in gpu intensive games?

        Thx!!!

          • Damage
          • 8 years ago

          Personally, I dislike tearing, so I’d leave vsync on and try to adjust the game’s quality settings so that you get plenty of performance. However, for really competitive twitch shooters and such, some folks may want to disable vsync in order to get the newest info onscreen ASAP.

            • doulos1382
            • 8 years ago

            Thanks Scott for your advice.

            BTW this is my first time i’m posting here a TR, however, i’ve been a faithful reader for 4 years. I’d like to take his opportunity and congratulate you for your excepcional report about the new ways of gpu benchmarking.

            I hope that the industry takes notice of the subject, and other journalist, reviewers and, of course, the gpu makers keep developing this new exciting trend you brought forward.

            KUDOS 4 You!!

            Best regards

            • Damage
            • 8 years ago

            Aw, shucks. Thanks!

            • Meadows
            • 8 years ago

            But you just concluded that “HyperFormance” is, in a way, “better” than no vsync because it gives “fresh” information just the same, while also appearing even more fluid as well.

            • BobbinThreadbare
            • 8 years ago

            I think he’s assuming that doulos doesn’t have this Lucid software that isn’t for sale.

    • dashbarron
    • 8 years ago

    Take-backsies.

      • Kaleid
      • 8 years ago

      Taffer talksies

    • Airmantharp
    • 8 years ago

    While I certainly won’t give up AMD’s drivers to run in iGPU mode for my HD6950 team, I’d definitely give up some frames if it meant smoothing out gameplay.

    In my opinion, the problem that Lucid is addressing here (with software!) has plagued computer gaming since the beginning. I can’t wait to hear more, and when I can get my hands on it!

    • Firestarter
    • 8 years ago

    Very interesting to hear that a third party has already made some kind of solution to the whole rendering -> displaying problem.

    But I can’t help to think that an intelligent game engine (you know, developed by the likes of Carmack) could far more easily just delay its game loop, to time it so that the rendering finishes just before flipping the framebuffer. As long as the processing time required to update the game world and render it is relatively stable, the engine could pick the best time to gather user and network input and start processing, leaving the CPU and GPU idle as long as possible. But I guess the whole PC ecosystem is too complex to try such an approach (what of throttling CPUs and GPUs?).

      • Airmantharp
      • 8 years ago

      I think you’re right- game developers should be able to do this on their own. Heck, they probably do on consoles already, with console’s static computing environments.

      On the PC side, not only does stuff throttle independently of execution, but the varying hardware and driver combinations are probably far too extreme for a game-engine-centric solution.

      Lucid’s after-the-fact approach probably isn’t the most efficient, but it does afford more flexibility. I’m hoping that they get this working in dGPU mode ASAP!

      • Anonymous Hamster
      • 8 years ago

      You are absolutely right. It’s wasted work to render frames that aren’t going to be displayed. What you want to do is to render the frame at the last possible moment before it will be displayed. However, other computations should still continue asynchronously. So game input and physics and network activity should continue at the best rates for those activities, while rendering should try to provide an accurate picture of what you should see at the point in time it is displayed.

    • puppetworx
    • 8 years ago

    This company is certainly continuing to innovate. Ihave yet to meet anyone using a Virtu system but I have to admit this HyperFormance seems like it will become a must for any serious competitive gamer.

    • Pantsu
    • 8 years ago

    Sounds promising, even if the name is awful marketing. I wonder though how this would work under 60 FPS compared to traditional vsync(+tb). Personally I haven’t had much tearing issues except for Eyefinity tearing, but if this would help stuttering that would be great. I just have my doubts whether this is a proper solution for micro-stutter, I’m more inclined to believe better support by engine developers and gpu driver teams is the better way to go about that particular problem.

    For those playing 60+ fps in competitive FPS games it can be a bitch to choose between tearing and lag introduced by vsync. In single player games though at least personally I don’t mind a bit of lag if it improves smoothness.

      • Airmantharp
      • 8 years ago

      Input lag is precisely why many disable vsync. For shooters, particularly online shooters when reducing lag wherever possible has tangible benefits, vsync isn’t an option and tearing is a way of life.

      If Lucid’s solution can both minimize input lag while getting rid of tearing, they’ve got a product I’d be willing to pay for!

    • Arclight
    • 8 years ago

    Originally i wanted to use vsync to quiet down my GPU fan, because if i can cap the fps at 60 in games like CS:S the video card won’t stretch all it’s muscles resulting in less heat/noise produced by the card.

    But as soon as i turned it on i noticed a huge lag as well as “missing” frames when i moved so i resorted to another solution which thankfully Valve thought about “fps_max XX”.

    Still not all games have this sort of control panel commands (specially now with all this console ports), most of them count on vsync to combat overhead and in the article it says that with Lucid’s solution the GPU will still work at full throttle it’s just that the software will decide which frames to show. Thanks but no thanks.

      • Airmantharp
      • 8 years ago

      It sounds like your main issue is with sound.

      While reducing rendering speed has the obvious benefit of lowering GPU output, it’s also counter-productive- why would you want the game to run slower?

      The real problem here is that you purchased a GPU who’s cooling solution is too loud for your tastes when the card is running at full tilt, and has nothing to do with Lucid’s product.

      If you want to combat the problem you could always just underclock/undervolt your card, so that at maximum output it wouldn’t have to spin up it’s cooling solution.

        • Arclight
        • 8 years ago

        [quote<]While reducing rendering speed has the obvious benefit of lowering GPU output, it's also counter-productive- why would you want the game to run slower?[/quote<] Because if i'm not mistaking, that's the very reason vsync was invented. Somebody realised that although powerfull machines churn out fps above 100 or 200 fps the screen can only show 60 fps so the machine is actually using excess power and creates uneeded noise as a result. The solution was to cap the fps at the max refresh rate of the screen right? So there you go. [quote<]The real problem here is that you purchased a GPU who's cooling solution is too loud for your tastes when the card is running at full tilt, and has nothing to do with Lucid's product.[/quote<] If my understanding of the creation of vsync is correct, please see above. By that i mean it's not solving anything, the peak consumption is still reached with still no benefit. My take is that a real solution would be for game developers to include ingame commands that can cap the fps at the value chosen by the user, but ofc above 60 or 72 in multiplayer. You see, CS:S servers don't allow you to enter if your cap is bellow 72 fps. in single player you can do w/e you want in multiplayer the minimum can be set at 60 or 70 according to developer's choice when they setup the servers....elegant solution. But this is only my view of vsync, it seems that Lucid is promissing something new with their vsync not related to my issues, we shall see if they deliver. Oh i forgot, the random unrelated video 😀 [url<]http://www.youtube.com/watch?v=gyx-Qqe5Y60&feature=related[/url<]

          • cygnus1
          • 8 years ago

          no no no, vsync was not created to combat GPU’s that are too powerful. It was invented to improve visual quality. This was explained in the article. Without vsync when you have more frames rendered than your display can display you get tearing. Basically you get parts of 2 or more frames displayed, with artifacts showing on screen where a new frame starts being drawn in the middle of the previous frame being drawn onscreen.

          There’s nothing wrong with running your GPU or CPU at max capacity. That’s what they’re designed to do. As long as the accompanying cooling solution runs as designed as well, you won’t have a problem.

          You clearly bought a GPU with a cooling solution that you don’t like from an acoustic standpoint. You either need to do like Airmantharp suggested and underclock/undervolt your GPU so it produces less heat at full load or you need to buy a new GPU or cooling solution that works with your acoustic desires.

          If you are capping frame rates and causing your GPU to work less than 100%, you have GPU resources going to waste and you’ve bought a higher end GPU than you need for your ‘application’.

            • Arclight
            • 8 years ago

            [quote<]It was invented to improve visual quality. This was explained in the article. Without vsync when you have more frames rendered than your display can display you get tearing. Basically you get parts of 2 or more frames displayed, with artifacts showing on screen where a new frame starts being drawn in the middle of the previous frame being drawn onscreen.[/quote<] Ah, so it's for image quality. Hmm ok then, my mistake. Fact is i never noticed tearing....i looked it up on google, i understand how it looks like, but somehow i never noticed it in the games i played.

    • thaneross
    • 8 years ago

    This is nifty stuff, but the problem seems better solved with higher refresh rates. At 60hz, the lag a new frame can have while waiting to be sent to the display is between 0ms – 16.67ms. At 120hz it’s 8.33ms, at 240hz it’s 4.167ms.

    4ms is getting into the imperceptible range, and I’d bet most couldn’t tell the difference with 8ms. A simple vsync algorithm means if your card can do FPS higher than your refresh rate you can let the card rest in between frames.

    • bcronce
    • 8 years ago

    It sounds something like this

    Say the CPU can generate a new scene every 6ms
    The Monitor displays a constant 60fps(16.6666…ms)

    Now, the GPU renders a frame every 5ms to every 33.33….ms

    What you want to do is have the next frame from the GPU be rendered as close to before the next monitor frame. So you discard all the “cpu” frames until the estimated cpu frame time plus estimated rendered frame time finishes before the next frame time.

    How you estimate would be very important.

    This would be my guess anyway.

    • ew
    • 8 years ago

    [quote<]Most GPUs these days combine vsync with a technique known as triple buffering, in which three completed frames are queued up in buffers, in order to ensure a new frame is always ready for display when the time comes. That time comes only at a set pace, typically 60Hz, so conventional vsync has the effect of capping frame rates at the display's refresh rate.[/quote<] That's not the whole story with regards to triple buffering + vsync. With triple buffering the GPU does not have to wait for a vsync before it can start drawing a new frame. The GPU can draw as many frames as it wants switching between the two back buffers as it goes. When a vsync happens whichever back buffer is complete becomes the new front buffer. From Wikipedia [url<]http://en.wikipedia.org/wiki/Multiple_buffering#Triple_buffering[/url<] [quote<]In triple buffering the program has two back buffers and can immediately start drawing in the one that is not involved in such copying. The third buffer, the front buffer, is read by the graphics card to display the image on the monitor. Once the monitor has been drawn, the front buffer is flipped with (or copied from) the back buffer holding the last complete screen. Since one of the back buffers is always complete, the graphics card never has to wait for the software to complete. Consequently, the software and the graphics card are completely independent, and can run at their own pace. Finally, the displayed image was started without waiting for synchronization and thus with minimum lag.[1] Due to the software algorithm not having to poll the graphics hardware for monitor refresh events, the algorithm is free to run as fast as possible. This can mean that several drawings that are never displayed are written to the back buffers. This is not the only method of triple buffering available, but is the most prevalent on the PC architecture where the speed of the target machine is highly variable.[/quote<]

      • Damage
      • 8 years ago

      Yeah, I see I wasn’t entirely clear in my initial explanation. I’ve updated the article in an attempt to clarify things. Thanks.

        • crazybus
        • 8 years ago

        This article is still inconsistent with what I’ve read about triple buffering, or more specifically this statement is:

        [quote<]Remez contrasted the inherent delays in conventional triple buffering, where queuing up three frames at 60 FPS would add up to 48 milliseconds of lag, with Lucid's scheme, where frames are delivered more or less "just in time" for the display refresh.[/quote<] I was under the impression that real triple buffering is not just a render ahead queue, which would increase latency, but another back buffer that can be written to if there is enough GPU time. The most recently rendered frame after the vertical sync would always be displayed, no matter how many were actually rendered. Such a setup should incur no more than one display cycle's worth of additional latency. Source: [url<]http://www.anandtech.com/show/2794/2[/url<] [quote<]The software is still drawing the entire time behind the scenes on the two back buffers when triple buffering. This means that when the front buffer swap happens, unlike with double buffering and vsync, we don't have artificial delay. And unlike with double buffering without vsync, once we start sending a fully rendered frame to the monitor, we don't switch to another frame in the middle. [/quote<]

          • Chrispy_
          • 8 years ago

          Yep, triple buffering doesn’t work the way Remez describes it.

          Triple buffering is still technically double buffering with a front and back buffer, but since there are two back buffers, the average time it takes for one of the back buffers to be ready is effectively half that of double-buffering, not double, as inferred by Remez.

            • willmore
            • 8 years ago

            Guessing time again:

            Since tripple buffering is a good way to decrease latency, we would generally think of it as a good thing, but what effect does it have on the variance of the latency? Isn’t that what was shown to be the real problem with the within the second article? If Lucid can alter the rendering process to decrease the average latency (increase the ‘freshness’ of the most current back buffer), then the variance will go down as well. Now, that’s not the same as synchronizing the game engine to the vsync rate (which would be idea), but it should be an improvement.

            I’m curious, graphics guys, how does tripple buffering work in the context of ‘SLI’? Does each GPU get a pair of back buffers? If there are really only two back buffers, then each one will be dedicated to a GPU and, come vsync time, it’s possible that neither of them will be ready, no? I’d really appreciate some education here.

    • Bensam123
    • 8 years ago

    This seems more like a scheduler then a v-sync.

    There are a lot of theories and questions I could entertain about this, but from what we know it’s almost not even worth stating them… such as the perceived fluidity of motion might be due to eliminating other unforeseen variables by cherry picking frames, not microstuttering as we perceive it (depending on the length of the stutter, if there aren’t enough frames to pick from before it’s supposed to render, since it still has to render within a certain amount of time). All of this is really superficial though.

    Still a very interesting product and I’m looking forward to Lucids stuff.

    • rootheday3
    • 8 years ago

    “Once those basics are performed, though, other work like pixel shader computations can be skipped, because that frame will never be shown to the user”

    While I can see how Lucid can act as a bridge to decouple the framerate the GPU uses vs the display frame rate of the monitor, but I don’t see how it can avoid rendering work. How does Lucid know that it can discard some/all of the rendering (e.g. pixel shaders) in a given frame. There are lots of cases where applications do “render to texture” in one frame that is reused as a texture in a later frame. Similarly, there are some cases where each frame is used to perform physics/geometry updates – for example the Flags feature test in 3DMarkVantage or N-body gravity Direct X sdk simulations that use geometry shader/streamout to feed data forward from frame to frame.

    Intelligently skipping these would involve ex post facto knowledge of which draw calls in Frame N are used in frame N+1… Since Frame N+1 hasn’t been run yet when Lucid would have to perform the short circuiting on Frame N, this seems like it would require per-app profiles… Given Lucid’s history, this doesn’t seem promising.

      • Bensam123
      • 8 years ago

      In the article they stated that part of those frames are rendered for such effects, the entire frame isn’t just discarded.

        • rootheday3
        • 8 years ago

        My question is how lucid could know generically which draw calls had “carryforward” effects insubsequent frames so they know which draw calls can be safely skipped and which must be kept

          • djgandy
          • 8 years ago

          I’d also like to know the answer to this.

          Unless they are deferring rendering, but that’s a huge amount of work just for ensuring a vsynced frame is as fresh as possible!

          This is the problem with writing graphics drivers, you simply do not know what is going to happen next! If a slow crappy read back of the entire framebuffer comes in for whatever reason you have to have rendered it.

          • BobbinThreadbare
          • 8 years ago

          I’m guessing they don’t, and any information that might be needed for the next frame is calculated. So all geometry and texture work is done and only rendering work that will never be used by the next frame is skipped.

    • Lianna
    • 8 years ago

    Great follow-up. I hold my breath for the test on TR.

    You may have wanted to ask about transfer requirements, both on PCIE (if used) and mainboard memory bandwidth – because with IGP it is used as a framebuffer. If I was a game writer I would really want to know if my CPU performance is going to dive/tank if I’m pushing 150fps (or 600fps like in the article) of 1080p game output, going at over 1GB/s (or, respectively, almost 5GB/s) in big bursts.

      • bhassel
      • 8 years ago

      Hopefully it only transfers the frames that will actually be shown to the IGP… it would be silly to do otherwise. So at 1080p and 60 Hz that’s around 700 MB/s of memory bandwidth just for copying the framebuffer. That is only about 7% of DDR3 1333’s bandwidth though. Probably not enough to “tank” CPU performance…

        • Airmantharp
        • 8 years ago

        Particularly since SB isn’t bandwidth constrained, and IB is supporting even higher memory speeds, and the cost of memory is declining overall :).

        • willmore
        • 8 years ago

        FTFA, they aren’t even rendering the frames they expect to discard, so they’re clearly not transfering them. Does that make sense?

    • ShadowTiger
    • 8 years ago

    You mentioned a 60 hz monitor… which is what I and probably most people have. However, I would love to get a 240hz 4k monitor in the next few years… will all of this technology scale gracefully or does the overhead get prohibitive?

      • Bensam123
      • 8 years ago

      I think this is a very interesting question too… How does it handle refresh rates higher then the GPU is drawing? If the laptop demo was any indication it means it’ll even out the framerate even if it can’t draw it as fast. Assuming the laptop had a 60hz monitor, the GPU was drawing at 30fps, and everything looked better with it on.

      • trek205
      • 8 years ago

      there is no such thing as a 240Hz monitor nor will there be one anytime soon.

        • Johnny5
        • 8 years ago

        I’ve heard of 600Hz tv’s. I was never sure whether that is due to a different technology (say plasma) or just marketing lies.

          • TrptJim
          • 8 years ago

          Whatever the HDTV says it outputs doesn’t really matter for anything other than if 24hz and 60hz fit neatly into it, as it cannot accept an input higher than 60hz.

            • Bensam123
            • 8 years ago

            It can if it has a DVI or a VGA input. Limits like that only apply to HDMI, PBYR, and Displayport (although I’m not sure about that), specifically the HDTV formats they exclusively support…

            600hz TVs are what Plasmas are listed as.

          • Meadows
          • 8 years ago

          600 Hz TVs are just plain old 60 Hz TVs that interpolate between frames and pulse the same frame rapidly 10 times before the next one comes.

          It’s neither a count for true refresh rate, nor a count for framerate. Just marketing – a specific property you can attach a high number to.

            • Bensam123
            • 8 years ago

            The only TVs I’ve heard about advertised as 600Hz are Plasmas…

            If you’re talking about refresh rate vs input rate, there are LCD tvs like that too… there are also LCDs that accept higher then 60Hz inputs as well as plasmas…

            More info can be found here:
            [url<]http://www.best-3dtvs.com/guides/what-does-600hz-sub-field-drive-mean/[/url<]

          • rechicero
          • 8 years ago

          Marketing gimmick. There is something happening at 600 Hz, but that’s not the frames per second. 600 Hz is the sub-field time. Plasma pixels have a 2ms response time, but they are not lighted all at the same times, they cycle different colours. And in 600 Hz sub-field drive panels, you have 600 changes per second in the image or 10 changes per frame. I’ve looked for the Panasonic technical info I learn all this from, but I can’t find it :-(. Anyway, it’s a marketing gimmick to point out something better from the plasma tech, but not as better as it looks. It’s good against image ghosting and motion blur, but doesn’t mean more fps.

            • Bensam123
            • 8 years ago

            From what I’ve read and know, plasma TVs for all intents and purposes don’t have a response time. Their cells refresh as fast as power can be sent to them. LCDs on the other hand need time for their crystals to morph and thats where response time comes from. They are not the same thing as refresh rate though.

            “If the Plasma panel performs 8 pulses per frame, it gives a sub field drive refresh rate of 480Hz. Now when the displayed frame has to be changed to the next frame, the ultra-fast response times of the Plasma TV sub pixels enables an almost instantaneous transition to the next frame.”

            So no, it’s not a marketing gimmick.

            Refresh rates when talked about by LCD makers is how fast the panel is refreshed internally, but at the same time it doesn’t matter if the response rate for the pixels is really slow. This really doesn’t come into play unless you can input at higher then 60Hz though, some monitors or TVs allow this through DVI or VGA.

            After doing a bit of googling, it looks like most of the info you and meadows posted on can be found on this link (if that’s not where you read the information in the first place):

            [url<]http://www.best-3dtvs.com/guides/what-does-600hz-sub-field-drive-mean/[/url<]

            • Airmantharp
            • 8 years ago

            Still wrong-

            The problem is not the panel refresh rate, but rather the limits of the signaling across the cable and associated processing on both ends of the cable.

            120Hz does exist, and is what ‘3D’ systems use, but beyond that hasn’t been explored.

            • Bensam123
            • 8 years ago

            So you’re talking about input rates… which do support it over DVI or VGA…

            You know there could be multiple ‘limitations’ here. Like response time, refresh rate, input rate, and processing time…

            • rechicero
            • 8 years ago

            The best way to explain this is with an image from some Panasonic doc about the subfield drive:

            [url<]http://img200.imageshack.us/img200/8507/subfieldpulses.png[/url<] You'll see 13 images. The first 12 are the pulses (this doc is for PAL), and the last one is the original frame (it never appears in the screen as it is). I hope this is clear enough. 🙂 The link you posted is not accurate, as you can see in the picture

            • Bensam123
            • 8 years ago

            Each pulse refreshes the brightness of the pixel, each time, the amount of pulses in turn increase the rate at which plasmas can refresh…

            I mean you don’t even need to take my word for it. Go watch fast action on a plasma screen then watch it on a LCD… there is a very clear difference. You can say you’re wrong all you want, but when you look at it on a screen it most definitely looks a lot more fluid.

            • rechicero
            • 8 years ago

            Bensam123 I have a Panasonic Plasma TV. I’m well aware of the advantages and disadvantages of plasma ;-). But, Did you see the link I posted? I thought that would be better than a complicated explanation.

            In plasma TV, a frame is composed out of 10-12 pulses (depending of the refresh rate: PAL or NTSC). But each of this pulses is NOT like another frame, the information is limited. Each pulses offers just part of the colours of the frame. The good thing is, if you have good interpolating algorithms, you can use those pulses to offer better illusion of movement. But it’s not equivalent to refresh, as plasma is using something pretty similar to a dithering technique. In fact, in a lot of still images, if you are near enough, you can see how the pixels are “changing”. Even if the image is still.

            I insist, just see this link

            [url<]http://img200.imageshack.us/img200/8507/subfieldpulses.png[/url<] Do you really think that's faster refresh rate? You receive the complete frame info 50 times per second (in the example, as it's PAL). But that info is composed out of 12 different subfields (that's why they're called "sub"). So, the refresh rate is the same, but they can offer better illusion of movement as they can change some info from pulse to pulse (that means you won't see the original frame, though)

            • Bensam123
            • 8 years ago

            I did look at the link… and it shows one of the images being lighter then the other one. What you’re explaining is similar to the article I linked, however you’re describing the pulses as a composite. That each pulse directly makes up for the color in the frame and each color pulse is different so it gives the illusion of the final image.

            That aside, I don’t understand why you think a plasma would be limited to 60Hz with technology like this or that they aren’t capable of faster refresh rates. The major limiting factor for LCDs is the morph time for the crystals. Plasmas essentially have no wait time and as far as exciting the phosphor, I’ve heard on the end of 4 microseconds for green, which is limited only by the computation on board.

            Yes, I’ve witnessed the pixel jitter which is almost identical to that of CRTs.

            Helpful thread I found, includes the phosphor number:

            [url<]http://www.avsforum.com/avs-vb/showthread.php?t=1047145[/url<]

            • rechicero
            • 8 years ago

            In the link you should see 13 different images. Each different from the others. The first 12 are the pulses and the last one is the actual frame. For example, in the pulse #6, the ball is blue. In the pulse #7 is yellow. And in the #8 is red.

            I’m not saying plasma is limited to 60 Hz. In fact, now they have 3D, and that means 120 Hz. I only wanted to explain why the 600 Hz figure is misleading. It’s true, but that’s not the refresh rate. As said in the thread you link,

            Then why even use this number in marketing? – Good question! I suspect because it is bigger than 120 and has “Hz” at the end of it

            • Bensam123
            • 8 years ago

            I understood the premise of them using it as marketing and I also understood that 600Hz isn’t a completely legitimate number, it’s not completely wrong either though…

    • kamikaziechameleon
    • 8 years ago

    Interesting.

    • ColeLT1
    • 8 years ago

    Does this make the card work harder/run warmer, since it is trying to process as much as it can?

    For example, when gaming (on a game that isn’t crysis or metro2033) my cards run like 49c/45c when frame-capped by vsync with each gpu usage 30-60% in afterburner, but with vsync off they are more like 56c/52c and 100% gpu.

      • jjj
      • 8 years ago

      Somewhat related to this i wanted to ask for power consumption/battery life tests when TR gets to review it.

        • Waco
        • 8 years ago

        I was going to mention the same thing. Especially with my Quadfire setup – I use DRASTICALLY less power when playing older games with vsync enabled. I can’t imagine this will be good for battery life in laptops.

      • odizzido
      • 8 years ago

      Yeah this is a concern for me as well since I like to use as little power as I can.

      If this software had an easy way to turn it on or off, or even offer some way of making shortcuts to games that tells the software if it should run or not, I think it would be a win/win situation.

      Anyways what I am really hopeful for is this fixing vsync on games like stalker that just refuse to actually sync anything.

Pin It on Pinterest

Share This