Nvidia's G-Sync: Attempting to Revolutionize Gaming via Smoothness

http://www.anandtech.com/show/7436/nvidias-gsync-attempting-to-revolutionize-gaming-via-smoothness

by cobrausn • 13 years ago

191 153 13 years ago

anandtech.com

cobrausn2• 13 years ago

Submitted this a bit earlier with a link to the actual press release, but it never made front page.

http://www.geforce.com/whats-new/articles/introducing-nvidia...

brymaster• 13 years ago

Carmack had some interesting notes on this, a couple being:

- This would be perfect for games common in emulation where frame rates are capped but vertical sync isn't used. https://twitter.com/id_aa_carmack/status/391303034745401344

- This technology will come later to laptop and mobile devices and sadly, he tried to get Apple to do this years ago. https://twitter.com/id_aa_carmack/status/391303627278925824

MBCook• 13 years ago

and sadly, he tried to get Apple to do this years ago.

As an Apple user, this doesn't really surprise me. Apple has never liked games, although I'm hoping that was a Steve Jobs thing and the company will see the light.

In some ways they are behind on displays. Windows 7 and above supports 'Deep Color' (30-bit or more), but as far as I know Mountain Lion doesn't.

They're were out first with retina though.

It wouldn't surprise me if this doesn't come to OS X any time soon. Too bad.

KVFinn9• 13 years ago

As an Apple user, this doesn't really surprise me. Apple has never liked games, although I'm hoping that was a Steve Jobs thing and the company will see the light.

But Apple DOES have a thing for responsiveness and smoothness, and latency and smoothness is exaclty what this tech is improving. I think you could make a strong case without mentioning games. Not that you would have to anymore, since games are so popular on these devices...

But an example: I find the animations in IOS 7 look great on 5S but a bit choppy on regular 5. They clearly aren't maintaining 60 FPS on that device and you can see some hitching. This tech is most beneficial at making variable frame rates between 30 and 60 be more smooth so it could be a big help.

danmaz745• 13 years ago

Am I missing something, or this would make a real difference only if you monitor has a low top refresh rate? If the refresh rate is 144 Hz, like the one they talk about in the article, I wouldn't expect that waiting for vsync will have big impact on the fps.

ensmotko• 13 years ago

G-Sync syncs the monitors refresh rate with the FPS your graphics card is feeding the monitor - thus removing screen tearing and other anomalies that happen when the refresh rates are out of sync.

It doesn't make a difference if your card is renderring at 60 fps with out a hitch, but you can see the difference when the fps drop to 50 or 40. Check out this video: http://www.engadget.com/2013/10/18/nvidia-g-sync/

baq2• 13 years ago

the point is that refresh rate is kept equal to gpu frame rate, so there's no need for vsync. this results in less display lag without mid-frame tearing, basically best of both worlds.

danmaz745• 13 years ago

I understand that, but if you have vsync there is already no tearing, and with a 144Hz refresh rate your lag is at most 1/144th of a second, or 7ms, and on average 3.5ms - I don't think that's something noticeable.

This would be useful for low-end monitors, but, if I understood correctly, it's not going to work on that kind of monitors anyway.

KVFinn9• 13 years ago

If you running at 144 the frame rate drops to 72 whenever the game can't maintain it. Carmack says when this happens in VR it's like being kicked in the head but they can't disable Vsync because tearing is even worse.

Unless you triple buffer but which adds its own problems, including more latency. But this tech is also about the feel -- even at the 'same' frame rate the subjective impression is of a much smoother game. For obvious reason this can not be captured in a video so it's tricky to sell, they have to show it you in person.

Their slide showing vsync lag:

http://images.anandtech.com/doci/7432/NVMontreal-097.jpg

Anand has some of his personal impressions posted already:

http://www.anandtech.com/show/7436/nvidias-gsync-attempting-...

"I can't stress enough just how smooth the G-Sync experience was, it's a game changer."

danmaz745• 13 years ago

72 FPS looks very high to me, but I never tried VR. Would be curious to see the difference there.

nhaehnle2• 13 years ago

The first ingredient of the answer is that for all sorts of video (including games) to look smooth, it is important to know exactly when a frame is going to be displayed on the screen.

The second ingredient of the answer is that, with a fixed monitor refresh rate, you're basically forced to run at a divisor of that refresh rate.

So, if your game usually runs at 72Hz (on a 144Hz monitor) and you get to a busier section, the framerate has to drop down to 36Hz, even when 60Hz would still be possible in terms of CPU and GPU power.

danmaz745• 13 years ago

I get the divisor thing (if you're not doing triple buffering), but I don't get why it should be divided by a power of two. After 72Hz it should be 48Hz (still very good) and only then 36Hz (still not bad I think).

Anyway, I would be curious to try to see if I could notice a difference. Math can take us just so far :)

staunch3• 13 years ago

Any benefit if your game is rendering 120fps and your monitor is doing 120hz? Even though they're the same speed they're not necessarily in sync?

wmf• 13 years ago

Almost no game can render at exactly a target frame rate, and if so it means the game isn't pushing the GPU to the limit. For any graphically awesome game the frame rate will vary and G-Sync should help in that case.

staunch3• 13 years ago

Nah, there's plenty of (mostly a bit older) games that my fairly powerful gaming PC can max out on FPS at very high rates.

KVFinn9• 13 years ago

If the game ever drops below 120 there will be a benefit.

Another way of putting it -- you can crank up graphics settings so that you don't need to stay way above 120 just to maintain a minimum 120, because dipping to 90 for a second no longer produce a huge drop in quality.

ANTSANTS2• 13 years ago

Yeah, a computer can easily render frames at the same rate that the monitor accepts them, while being horribly out of phase with the timing that the monitor expects to receive the frames. Imagine you and your friend playing on a swingset, where both of you are swinging at the same speed, but you are always at the top when your friend is at the bottom. That's likely the most common source of tearing: the frame rendered within enough time, but due to poorly configured graphics card drivers, the game process being briefly swapped out for something else at the wrong moment, naive timing in the game's rendering loop, or something else, the framebuffer is swapped out too late anyway.

The traditional way to solve this is with v-sync, which works great on realtime systems like game consoles, but on multitasking operating systems, it's rather difficult to synchronize an application perfectly to the display's refresh rate. As such, every graphics card I've ever used adds a frame or two of buffer when v-sync is enabled, resulting in a buttery-smooth but very noticeably laggy display. It doesn't matter how intensive a scene you are rendering, either: I was playing a Quake source port the other day, a game released over 17 years ago, and even that was unplayable for me with v-sync enabled.

I'm very excited for this technology, because allowing programs to control both the frequency and phase of display updates has the potential to eliminate the vast majority of display artifacts I've experienced.

staunch3• 13 years ago

If they're both able to maintain 120hz/120FPS why can't they just sync up once? Or once every N minutes if they drift apart?

jamesaguilar3• 13 years ago

I used to think my next computer purchase would be whatever was required to drive the first 4k monitor under $2k. But I have seen that I was incorrect. Smoothness is far more important than resolution (to me), so if this technology proves to be useful, I will probably end up purchasing a monitor with this capability and a new computer to go with it.

I really have to applaud the engineers at Nvidia, and whoever else drove this initiative. I thought graphics were slowing down and I wouldn't need to upgrade for a while (it's already been two years). To come up with a product that proves me wrong is both surprising and delightful. Great work from a corporate perspective, great work from a gaming perspective, and great work from an engineering perspective. Just really fantastic all around.

bhauer• 13 years ago

Agreed! But I see no reason why we can't have both. Resolution and smoothness. I'd be so happy with both.

Especially if I can have it at Seiki prices. I picked up one of their $700 4Ks and the only thing holding Seiki back from cracking the desktop display market is the 30Hz limit they inherit from HDMI 1.4, making the monitor only suitable for work (but very well suited to work).

jamesaguilar3• 13 years ago

Unless the world economy collapses permanently, I have no doubt that we'll have both eventually. I don't have the patience to wait for inexpensive 4k in the face of this sync stuff though, which is why I can't have both in this generation.

seanmcdirmid• 13 years ago

Curious: how is the Seiki working out for you? I've heard its not a great TV, but might be an OK computer monitor.

rschmitty• 13 years ago

I thought 4k was just for large tvs, can you tell a difference over a retina display? Aren't they called retina because that's the most your eye can see?

Genuinely curious, thanks!

jamesaguilar3• 13 years ago

My understanding is that a 4k 30" monitor is a retina display at 30 inches. I know that I can see pixel edges on my Dell Ultrasharp, and it's 2560x1440. My guess is that I would not be able to see pixel edges if the resolution was quadrupled (4k).

jholman• 13 years ago

No. They're called "retina" because the people who name things at Apple are professionally focused on deceiving you. What a surprise.

I've seen lots of articles about this over time, here's one I googled just now:

http://www.cultofmac.com/173702/why-retina-isnt-enough-featu...

Combine this with what jamesaguillar already said, about wanting a larger screen and also wanting high PPI, and why wouldn't you want higher res?

__david__• 13 years ago

Actually, 4k screens are useless for TVs (despite what all the TV manufactures want you to believe), since you generally sit so far away from them. A 4k monitor would be very nice, since it would be large but still very high DPI (ie, "Retina").

masklinn• 13 years ago

I thought 4k was just for large tvs

4k is nothing more than the double resolution from 1080p

can you tell a difference over a retina display?

A 21" Retina Display iMac would be 4k (the current 21" iMac is 1920x1080). A 27" Retina Display iMac would be way beyond 4k (it would have a 5120x2880 display)

Aren't they called retina because that's the most your eye can see?

That's more of a marketing moniker and incomplete. The original point/qualifier is that they fall beyond the eye's angular resolution so you can't "see" individual pixels anymore. That's not "the most your eyes can see" though, many arthropods create details & colors through nanometric structures.

KVFinn9• 13 years ago

Video of the panel discussion between Carmack, Sweeney, and Johan (lead on EA's Frostbite engine):

http://www.twitch.tv/linustech/b/471263848?t=2h27m

Carmack answered some questions about it on twitter right after as well:

https://twitter.com/ID_AA_Carmack/with_replies

keyle• 13 years ago

Thank you for the twitch link!

wtallis5• 13 years ago

It is kind of surprising that CRTs have been dead for so long but we're still driving our displays in pretty much the same fashion, except with reduced blanking intervals. We still treat video connections as constant data-rate streams, when we should be bursting frames to the monitor as soon as they finish rendering and letting the monitor worry about when it will be able to update which part of the screen.

devindotcom• 13 years ago

That's how it would work with OLED, right? So we should have that in a few years once density and cost catch up to traditional LED-backed LCDs.

wtallis5• 13 years ago

That's how it could work on any of the common display technologies that don't use a single electron beam tracing across the screen. Active-matrix displays - be they OLED or TFT LCD - don't require that pixels be updated in any particular order or at any specific frequency save for the minimum update frequency that is analogous to DRAM refreshing.

The way we currently send pixel data to monitors is basically optimized to make the monitor's electronics as simple as possible and to minimize the bandwidth used at all times, even if the hardware is capable of communicating at higher speeds. Just simply changing DisplayPort to always send pixel data at the highest speed even when operating at less than the maximum resolution supported by that link would result in a significant reduction in latency, by no longer taking 16ms to send each frame (which almost all monitors fully buffer in order to apply color transformations or scaling). The next step after that would be to allow frames to start on irregular intervals, which is apparently what NVidia's implementing. But it's still all just about how the contents of the GPU's framebuffer are transmitted to the monitor's framebuffer, and is in no way dependent on what kind of technology is downstream of the monitor's framebuffer.

seanalltogether2• 13 years ago

So is the idea here that the buffer is actually on the monitor now and no longer on the gpu? Is that why there is 3x256MB memory on the controller? Perhaps the gpu just pushes bits across the wire as soon as its ready now? And the monitor is now responsible for maintaining a localize triple buffer mechanism?

cobrausn2• 13 years ago

The idea is that the monitor will only refresh after it is given a frame to render from the graphics card, which makes the monitor sync to the framerate of the graphics card, not the other way around. From what I can tell, this basically means instead of having a fixed refresh rate, the modified monitor now has a variable refresh rate, slaved to the output of the GPU.

seanalltogether2• 13 years ago

Right, but a traditional 1920x1080 monitor only needs ~50MB of memory to store a frame of data to flush to the screen. So why introduce 3x256MB of memory on the controller? Unless the idea is to move away from managing frame buffers on the gpu.

toast02• 13 years ago

Could this be a bits versus bytes issue? a 256MB ram chip typically is 256 megabits (and a typical memory module would have some multiple of 8 of them). 3x256Megabits is 96 Megabytes, which still seems like a lot, but might (1920 x 1080 x 32-bit = a little less than 8 megabytes, unless my math is way wrong)

csense• 13 years ago

Consider another revolutionary technology from the same company, Optimus. When it first came out, it took a number of years and a public roasting by Linus Torvalds [1] to convince nVidia to officially support it on Linux.

Hopefully, with Valve and increasing numbers of indies supporting Linux, nVidia will learn from their previous mistakes and offer official Linux support for G-Sync from the beginning.

[1] http://www.phoronix.com/scan.php?page=news_item&px=MTEyMTc

devx2• 13 years ago

Optimus wouldn't have a reason to exist if say Nvidia made their "mid-range" dedicated notebook GPU's to clock at 200 Mhz for "normal use", and then go to 600+ Mhz in games, or other high-end apps.

Of course, perhaps the company that led to the making of Optimus in the first place is Intel, because they started bundling their GPU's and then charging OEM's more for the standalone CPU than from the bundle - and eventually OEM's were like "why not just get both Intel's GPU, and a higher-end Nvidia one?"

If you ask me, I think Intel's move should've been declared anti-competitive from the beginning. There's no way the bundle cost Intel less than the CPU, but they priced it that way because they had a monopoly, and could force OEM's to just accept the deal "or buy the more expensive CPU if they don't like it", which was obviously a non-option option.

pgz• 13 years ago

This also looks really good for video playback (as in movies). It would avoid stuttering from pulldown. I am quite hyped about this.

vilhelm_s• 13 years ago

What exactly does the extension card do? 1920x1080 24-bit pixels is 6MB, so why does it need 768MB of on-board memory?

kevingadd• 13 years ago

There are games that can use up 2GB of on-board GPU memory right now, for textures/buffers/etc. It won't be difficult to use up as much as 8 in the near future when panel resolutions get higher - higher panel resolution means a demand for higher resolution textures.

Given this, I'm sure there are things they can do with that onboard memory in the display. Maybe buffer up a half dozen video frames with timing data for smooth high res video playback?

phire• 13 years ago

But we aren't moving the gpu to the screen.

With it's currently advertised feature set, there is no need for that much ram.

Assuming future-proofing support for 4k monitors with framebuffers in 16bit floating point format, That's still only 48mb per buffer and there is no reason to have more than two buffers in a screen.

lambda• 13 years ago

But since the primary market for this is gaming, you can't buffer up anything or you kill latency, which is even more important than smoothness.

gambiting• 13 years ago

The resolution of textures has absolutely nothing to do with the fact that the size of the framebuffer is only 1920x1080x24 bits large,so 6075KB(5.93MB). Unless you are trying to imply that the memory in the monitor will be used as an extension of the GPUs memory, which I really don't see how it would work over existing connections and deal with the latency and relatively low bandwidth involved.

bcoates2• 13 years ago

This is absolutely brilliant. Pushing the clock from software seems like it'd help the issue with syncing the encoded framerate on streaming video to the display, as well. I wonder if the non-uniform refresh of a 60fps and 24fps video on-screen at the same time would look weird.

If they're adding some cpu and a framebuffer on the display, maybe they can start doing some compression for the cable link between GPU and display -- the raw bitrate is proportional to resolution² ✕ color depth ✕ framerate but the information rate doesn't go up nearly as fast as that increases. Even simple, lossless PNG-style compression would be a huge gain on a 240hz/48bit/4k display.

Scene_Cast2• 13 years ago

The flip side of the coin is that as soon as you're pushing more data than the link can hold, if you encounter incompressible data (say I just generated some recursive high-frequency Perlin noise) - you would start getting stutter and lag.

bcoates2• 13 years ago

Yeah, it couldn't be perfectly general. You could still keep the decoder simple and just put a little more intelligence on the GPU side to handle quantizing on the time/space/color dimensions appropriately when you try to send a pathological image. Getting the few multiples of compression you'd need to run 4k@48bit 240hz on current interfaces would probably be safe, trying to put HD over a serial cable will probably go less well.

Amadou• 13 years ago

Sounds great. But it should be in a standard, keeping this proprietary to nvidia means it will only be available on a limited number of monitors and cross-fingers AMD doesn't do their own version.

Put it in the next HDMI spec (and the rev the spec fast, not another 2 years or so).

nivla• 13 years ago

Here is a great read about V-Sync and how it tries to fix the disparities in refresh rates:

http://hardforum.com/showthread.php?t=928593

Contrast it with what G-Sync is trying to achieve.

aspensmonster2• 13 years ago

Reading that, it sounds like triple buffering is already a better solution to this problem. It sounds simpler than requiring a specially embedded DSP from Nvidia in your monitor to talk with your Nvidia card (and only with your Nvidia card).

vinkelhake• 13 years ago

Triple buffering does not solve the problem. If your monitor is locked at 60Hz and your rendering can't produce more than, say, 55 frames per second then you're going to have to display the same frame for multiple monitor refresh cycles. The monitor will typically show every rendered frame for 2 refresh cycles, with triple buffering you may be able to occasionally show a frame for just one cycle.

With something like G-Sync you can instead show 55 frames per second.

zokier• 13 years ago

This and Wayland and hopefully I will never ever see a teared or mistimed(stuttering) frame anymore. I can't wait.

hedgehog• 13 years ago

I'm curious how similar this is to Embedded DisplayPort's panel self refresh feature. It would be neat to be able to run the display at exactly 24 FPS for movies, down lower when staring at code (to save power), and then dial it up to 100+ Hz for scrolling and animations.

anonymous• 13 years ago

I have been wondering for a while what reason there is for LCD displays to have refresh rates at all. There is nothing to refresh per se. Shouldn't the display just tell the videocard it can handle frames as long as they're at least some ms apart, then the videocard pushes the frames when they are ready, whenever that may be?

It makes way more sense to me than carrying over the limitations of old (CRT) technology.

jblow6• 13 years ago

You are correct. The whole reason things are set up this way is historical, compatibility with CRTs.

ComputerGuru• 13 years ago

This looks incredible and I want nVidia to succeed because it's actually been a long time without any game-changing (no pun intended, honest) improvements (evolutionary or revolutionary) in the gaming and graphics market.

That said, I read the article and yet remain confused as to where exactly the G-sync module integrates with the monitor. From what I understand, it the G-sync hardware/firmware will run on a packet level, analyzing in realtime the incoming feed of DisplayPort packets and deciding how much of what goes where and when. Very neat.

The most important question, I believe, is what monitors can this be used with? The text makes it clear that users will be able to mod their own ASUS VG248QE monitors to add on the G-sync card, but that's a very, very specific make and model. Is this technology going to require hardware manufacturers to cooperate with nVidia, or will their cooperation simply make things nicer/easier?

Also, some of us have (in business environments) $1k+ S-IPS 30"+ monitors — the quality of these monitors is way above that of consumer models like the VG248QE and others. If there is no way to generically mod monitors without onboard DSPs, I could see that hindering adoption.

Miyamoto2• 13 years ago

Also, some of us have (in business environments) $1k+ S-IPS 30"+ monitors — the quality of these monitors is way above that of consumer models like the VG248QE and others. If there is no way to generically mod monitors without onboard DSPs, I could see that hindering adoption.

I think Nvidia is targeting hardcore gamers first and foremost. Most gamers are not gaming at 2560x1600/1440. Some are, but most aren't.

The most popular monitors by pro gamers right now (Twitch/eSport players and enthusiasts) are 120/144hz 1ms monitors, such as the ASUS VG248QE. Color reproduction isn't as important to pro gamers as smoothness/framerates.

Also hardcore/pro players are dumping lots of money on the most expensive computer rigs, often upgrading to the latest and greatest every generation. They are a very important marketing group for Nvidia.

rdtsc2• 13 years ago

The most popular monitors by pro gamers right now (Twitch/eSport players and enthusiasts) are 120/144hz 1ms monitors, such as the ASUS VG248QE.

I wonder if that latency is noticeable to them or this this the same market as the audiophile market that sells gold-plated cables for 100x markup.

jaytaylor• 13 years ago

What is the real size of the market of gamers who upgrade with every new generation of hardware? I've gotta say, I know many gamers (though no professional ones), and none of them upgrade that often. It's more like once every 2-3 years at the most.

It just seems like a bit of a sensational claim..

KVFinn9• 13 years ago

Is this technology going to require hardware manufacturers to cooperate with nVidia, or will their cooperation simply make things nicer/easier?

Carmack said on his twitter:

https://twitter.com/ID_AA_Carmack/status/391301331325321216

"great tech, but can it really survive as an NVIDIA only thing, versus an industry standard everyone could support?"

"I think everyone will wind up with it, or something similar. It is low hanging fruit."

sounds• 13 years ago

Here's an example of what's going on:

1. The game decides what happened since the last frame: an opponent appeared on the screen

2. Game -> GPU (3D geometry)

3. GPU -> Frame buffer (geometry is rasterized into pixels)

4. Another part of the GPU handles the DisplayPort protocol... Frame buffer -> DisplayPort -> Monitor

5. This is where G-sync works. Based on all the images supplied on the NVidia site, the $100 G-sync board is a drop-in _replacement_ for the controller board in your monitor. So obviously, it's only guaranteed to work on the ASUS VG248QE. Monitor's DisplayPort input -> Frame buffer

6. Where G-sync shines: a vanilla controller board in your monitor should not buffer very much of the pixel data. But they sometimes buffer waaaay more than necessary. To oversimplify, you could receive 1 row of pixels on the DisplayPort and send them out as analog signals to the transistors in the LCD panel while filling up the buffer again for the next line. NVidia's uses something about the vertical blank packet to tell the board that a new frame is coming _now_.

7. The transistors react to the change in voltage and either block light or allow it to pass through.

8. You see the change and shoot your opponent.

Because of the way the liquid crystals respond to voltage, the analog signals to the panel are anything but simple [1]. The display can't just be left "on" and can't be expected to instantly react to changes. So the G-sync board has to be panel-specific for the Asus display, but is smarter than your average display controller.

The oversimplified example above breaks down because the transistors embedded in the panel need a varying signal, so the controller is actually driving the panel at rates much higher than 144Hz per full frame. This way, each transistor experiences an average voltage something like [1] caused by the rapid updates coming from the controller. Separate LCD driver chips disappeared over 10 years ago; now all LCD panels are designed to be driven by a high-frequency digital signal that averages out to the voltage the panel needs. In car audio it's called a "1-bit DAC," but inside an LCD it's called a "wire." :)

Interestingly, G-Sync may actually be capable of shortening the panel's life. Since it is capped at 144Hz which is the panel's maximum rated speed, it may be perfectly safe. But any time you go and change the analog signals to the panel there could be harmful effects: slow changes in color calibration, ghosting, or even dead pixels.

[1] Image only: http://commons.wikimedia.org/wiki/File:LCD_Panel_drive_%28Ac...

I looked for a good explanation of the physics behind LCD drive voltage, but Google apparently can't find any good articles out there...

devx2• 13 years ago

Will these work with other GPU's? How hard is it to replicate by the competitors? And will all displays have to support 10 different GPU makers for this feature, if there's no standard set?

shurcooL• 13 years ago

For anyone excited about this, check out http://www.blurbusters.com/. It's a blog dedicated to everything-refresh-rate.

jswanson• 13 years ago

One thought on this is that this technology, or something related, would be beneficial to Oculus. Carmack already had a comment on it:

  G-Sync won't work on any of the display panels Oculus is considering right now, but it will probably be influencing many future panels.

https://twitter.com/ID_AA_Carmack/status/391299110344867841

Demiurge• 13 years ago

I don't think I like the LCD refresh rate to go anywhere below 60hz. 30 seems like really quite bad, duplicated frame or not.

mistercow• 13 years ago

This could also be nice for watching simple videos. It's subtle, but on smooth pans, you can see the stuttering of a 24p video on a 60Hz display. If the video player could tell the display to refresh at 47.952Hz (or any other integer multiple) instead, it would clean that right up.

Combine that with morphing frame interpolation, and you could be watching movies at just about exactly the rate your hardware can manage to push them out.

pantalaimon• 13 years ago

Are my eyes just that bad or is this solving a problem I didn't ever notice exists?

TheZenPsycho23• 13 years ago

I've never understood what is so difficult about making software that can generate frames at a fixed rate, and I don't understand this product- I don't understand how having a variable refresh rate would do anything other than harm smoothness, and encourage more bad software.

Maybe someone can clarify this for me, but what is so wrong with writing software that can just meet the frame deadline? Maybe the hardware innovation should be hardware and drivers that helps you do vertical sync more reliably?

Daniel_Newby• 13 years ago

Meeting the frame deadline is about scene complexity, not code. Keeping scene complexity under the limit is nearly impossible in large, rich game worlds. On small console games it is done by putting in walls and strictly limiting the visual budget, but that would remove much of the appeal of a game like Skyrim.

TheZenPsycho23• 13 years ago

Skyrim exists on at least one console. Isn't it possible to make a game with a similar level of richness of skyrim within a budget? can hardware help with enforcing the budget? I intuit that there must be some kind of trademark you can make to get under the deadline- like for instance, perhaps, progressive rendering of a frame, so that if the frame doesn't finish in time you get a half resolution frame, instead of just the top half of a frame?

aethr• 13 years ago

If your renderer can draw 40fps in the highest density scenes (lots of polygons, particles, and effects) on specific hardware, then that is the most you'll be able to guarantee to that user without sacrificing detail. That will be your "fixed frame rate".

However, in simpler scenes the same renderer is likely to output significantly more frames (even up to thousands) at the same detail level.

So in this scenario, all you're doing by setting a fixed rate is throwing away tons of frames in low density scenes. Most gamers would prefer to have the most fps possible at any given moment, even if it means variability.

The most hardcore gamers I know use 120hz monitors, and machines that can deliver 241fps (120 * 2 + 1) in the highest detail scenes. They then set the engine to cap frames at 241fps which will eliminate tearing, negating the need for this technology. However, their gaming machines cost a LOT, so this would deliver similar results for a much wider range of hardware.

TheZenPsycho23• 13 years ago

If you're generating thousands of frames and throwing them away, you wrote your rendering software wrong. I ask again, what is so impossible about just rendering the 60fps (just a bit under the limit of the rate at which a human is able to perceive any difference), and then not rendering any more? instead of rendering as fast as you can, do the different trade of of always meeting the deadline.

sigh why am I explaining this again? is it really hard to understand? why?

lazylizard2• 13 years ago

is this what you are looking for? http://www.hialgo.com/main.html

TheZenPsycho23• 13 years ago

Huh?

ConAntonakos• 13 years ago

With this, ShadowPlay, and Gamestream, I'm very excited for the near future of gaming. NVIDIA is really streamlining the experience for PC gamers providing amenities like TwitchTV streaming via hardware acceleration.

They're going to make hardware manufacturers that strictly focused on streaming capabilities go out of business.

beloch• 13 years ago

This holds some potential for media playback as well, since matching display frame-rate to source material is usually necessary to avoid jerky playback (Some people are very sensitive to any kind of micro-stutter while others don't seem to notice). Of course, playback software will have to support it (easy) and it may be a while before HDTV's or projectors include Nvidia's chip, if that even happens at all! However, if it does happen, this will effectively signal the end of adjusting frame-rate on displays. Even simply allowing higher refresh rates than 60 Hz could clear up a lot of problems.

I don't think Displayport has sufficient bandwidth for 4K video at 144 Hz unfortunately. An upgrade on Displayport may be necessary. Given that HDCP has proven to be utterly pointless, one would hope DRM gets the boot. Encrypting and decrypting data at over 20 Gbit/s is probably a PITA when you're aiming for low latency and low cost.

asdfs4• 13 years ago

I'm glad to see others have been working on this. I'd been batting the idea of Hz-less displays around in my head over the past few weeks. I was actually going to write a blog post about the idea, as I was surprised that it seemed to have gone unimplemented.

I don't see much info about partial screen updates. I hope the eventual standardization of this sort of thing in DisplayPort will provide for Hz-less partial screen updates. It would be nice to be able to run a 3D application and a movie at the same time, providing 24 or 30 updates/second for the movie, and a dynamic rate for the 3D application. It also allows for cleaner implementation of 3D applications that aren't running fullscreen. Generally, partial updates seem like a more flexible, more natural evolution of the Hz-less display idea, particularly with "panel self refresh" and "partial frame updates" already in DisplayPort.

The obvious downside is that you've got a classic example of resource contention, this time in the case of bandwidth. If you've got two areas that want to be redrawn at the same time on different parts of the screen, only one (or a portion of one) can be sent at a time. This leads to jitter or (depending on how you decide to deal with it) some other visual problem. But let not the enemy of "good" be "perfect": it's still a very useful feature.

The best half-solution to the bandwidth contention problem (IMO) would be to push all the decision making as to who gets access to the "pipe" to the OS. It can decide which application (if any) gets a jitter-free experience (perhaps with user preference taken into account), it can provide hints to applications about when the pipe will be free, etc. The OS really has to manage it in order to provide a good experience.

nitrogen• 13 years ago

Me too. I thought about it a bunch when Abrash and Carmack were discussing VR early this year, and while thinking about 48fps movies. Really, I've wanted higher refresh rates ever since the switch to LCDs, and VFR displays would make smooth, high-refresh video much easier.

Since it's unlikely I'll ever be able to get into VFR display tech professionally, for the benefit of anyone working in the industry, here are my thoughts on the subject from February (focused more on video and movies):

  Feb. 21, 2013
  -------------

INTRO:

In the modern digital age of LCD, LED, plasma, and DLP displays, there's not much need for refresh rates to be all that high, or even constant. In the days of CRTs it was necessary to have a constantly refreshing signal coming from the video source in order to drive the electron beam across the screen and refresh the image in the phosphors without visible flicker. With film, it was much easier to run projectors and cameras at a constant rate due to their mechanical nature (and probable lack of a standard for indicating when to switch frame rates).

PROPOSAL:

I propose the development of a complete variable frame rate video chain, from camera, through production, encoding and distribution, and an HDMI/DVI-like video interface, to display devices. My primary focus of thought thus far has been on the video interface and display devices.

APPLICATIONS:

Cinema: Recently, The Hobbit was released at 24fps in some theaters, 48fps in others. As more directors want to experiment with 48fps cinema, why not remove the restriction to a fixed frame rate entirely? Initially, with widespread device support, directors and cinematographers could switch between 24fps and 48fps on a scene by scene basis. Eventually though, why not allow the frame rate to be varied continuously on a per-frame basis? Special effect sequences could be presented at 120fps, with either a gradual or an abrupt transition down to 24fps or even lower as desired for emotional or psychological effect. Variable frame rate displays would also allow mixing of NTSC, PAL, and film content without the delay of switching video signal refresh rates or using nasty time stretching or pulldown techniques. Video cameras and encoding systems could be developed that automatically adjust frame rate based on the amount of movement detected (to some extent this already exists in video codecs).

Gaming: Video games would also benefit from variable frame rate displays. No longer would gamers and game developers have to choose between a tear-free but delayed game using vertical sync, and a low-latency experience at high frame rate but with tearing. In a VFR display, the frame would be sent to the display when the game is ready, rather than the other way around. The content should be in control, not the device. This way a game could still remain artifact free if the frame rate drops, without the lag induced by waiting for the vertical blanking region before swapping buffers.

Mobile: Finally, variable frame rate devices could use much less power for signal processing and transmission; this would be especially desirable in battery-powered devices. A tablet running a word processor on an external display only needs to send an update to the screen once or twice per second to flash the cursor, saving the power that would be used for reading from video RAM and driving the display interface.

AREAS OF STUDY:

A very incomplete list of some of the considerations that must be made when developing a VFR technology suite follows:

The clock rate of an individual frame on the video display interface must be determined. Should devices negotiate an optimum clock rate upon connection and use that rate for all frames transmitted? Or should they adjust their pixel clock rate based on the current frame rate? Using the maximum possible pixel clock supported by the devices and the copper (or fiber or RF spectra) connecting them would reduce transmission-induced latency but might increase power consumption slightly.

A signaling method would need to be devised. Should the display interface protocol be verbose, with the video source announcing frame rates or frame times in advance to the display device? Or should the video card just start scanning out pixels whenever it wants to, and the display just has to deal with it?

Buffering techniques in the display would need to be considered. Should the LCD (or other) panel be updated as the pixels come in, or should a full frame be buffered first? How quickly could a buffered frame be shifted into the display panel? Given the fact that gamers can adapt to and extract greater temporal information from a higher framerate signal with tearing on a fixed rate display, there may be some benefit to scanning out the rows of an image as they arrive (the top row would be displayed a full 16ms sooner than it would otherwise).

Software would need a method of informing the video card that it's done drawing a frame. To a large extent this already exists in the form of the buffer swap call, but in a variable refresh rate system, there would be less need for double buffering to prevent artifacts. The application could draw to the scanout framebuffer as it pleases, tell the video card to send a scan to the display, then wait for the video card to notify it that the scan is done. Double buffering would still be used in games and applications that don't want to wait for one frame to finish scanning before drawing the next.

FURTHER THOUGHTS:

It would be interesting to go beyond VFR and create a display standard that can update selected regions of the screen (AKA dirty rectangles). For example, a video card could send a hypothetical "Start Scan" packet to the display device that contains the location and size of the region being updated, then stream raw pixel data that the display device fills into the updated region. For that matter, the updated region needn't be rectangular.

What about variable resolution display updates as well? This seems to make less sense in discrete pixel digital displays, but might find application when displaying low-DPI content in a subset area of a high-DPI/"retina" display.

It seems that a VFR display chain is a lot like double or triple buffering was back in the CRT days, but one of the buffers has been moved into the display device itself.

6ren• 13 years ago

Why can't a display behave exactly as bit-mapped memory? That is, you set this pixel in memory, and that pixel changes on the screen, at that time.

That is, like a vector display, but using the LEDs of a flat screen. There's no electron ray scanning over the phosphors as there was in a cathode ray tube.

The LEDs can switch only so fast - but does this latency prevent them from being switched independently?

The LEDs need to stay on for long enough for the human visual system to perceive them (and without flickering etc) - but this could be managed in other ways.

I think the main reason, apart from inertia, is that the larger market for displays is as TVs, where the concept of updating the whole frame (frames per second) is even more entrenched - though, there's no reason why video couldn't be displayed in the same way, it's just pushing out a kind of compression to the display itself. Light from real objects is not emitted one frame at a time.

YZF3• 13 years ago

I assume you're talking about LCD? Not too many LED displays around (though the principle is still similar).

While there's no scanning electron beam the electronics on these displays are still optimized for scanning. That is they push a whole bunch of adjacent pixels in every clock cycle. If you try to use those for random access your refresh rate is going to fall dramatically. The problem isn't whether or not each pixel can be switched independently it's how to efficiently address them and move data from the display controller to the display.

(editing with some more info)

If you changed the monitor's protocol to push X, Y, pixel and souped up the on-board electronics your pixel rate would probably fall by an order of magnitude. So your 80Hz display is now an 8Hz display (for full frames). In terms of how each pixel behaves they are independent (each has it's own transistor and capacitor) but the addressing is on a grid. So you can select your row and then set a whole bunch of pixels in this row (for example)...

asharp• 13 years ago

That doesn't seem to agree with http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgroun... .

kyberias• 13 years ago

Because of overhead. It's much slower to communicate "turn pixel at X,Y on" to the display for millions of individual pixels than it is to communicate "here's all the millions of pixels you need to display in sequence" in one message.

ye• 13 years ago

Because telling the display to turn one pixel at a time will require crazy bandwidth, and plus that's not how monitors or videocards or drivers or software work.

JanezStupar• 13 years ago

Where is my Optimus driver for Linux?

Nvidia's G-Sync: Attempting to Revolutionize Gaming via Smoothness

Related Stories