13 ms·

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

191 points by cobrausn 13y ago

cobrausn 13y 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-g-sync-revolutionary-ultra-smooth-stutter-free-gaming http://www.geforce.com/whats-new/articles/introducing-nvidia...
brymaster 13y 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 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 https://twitter.com/id_aa_carmack/status/391303627278925824
- MBCook 13y 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.
  - KVFinn 13y 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.
danmaz74 13y 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 13y 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/ http://www.engadget.com/2013/10/18/nvidia-g-sync/
- baq 13y 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.
  - danmaz74 13y 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.
    - reitzensteinm 13y ago
      The problem with vsync is that if your FPS drops below the refresh rate, the next frame is skipped, straight out halving your FPS. So if you have a 60hz display, and you're capable of rendering at 59fps smoothly, you actually end up rendering at 30fps. Worse, if you're alternating between 55-65fps due to subtle changes in scene complexity, the FPS will flip between 30fps and 60fps erratically, which is absolutely horrific (worse than just sticking at 30fps). To get smooth vsync 60fps, you probably want to be capable of running at 100fps on average, so there's a margin of safety and your worst case doesn't drop below 60fps. If this technology can make 55-65fps rendering seem as smooth as a 100fps capable machine with vsync enabled, it just nearly halved the system requirements. If it sounds like a mundane way to progress, that's because it is. All this is doing is replacing a system of bad design due to legacy reasons. Pushing data when it's done is almost always more sensible than an awkward fixed interval polling loop.
SmokyBourbon 13y ago
Could this be integrated into future versions of Nvidia's mobile gaming device?
staunch 13y 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 13y 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.
  - staunch 13y 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.
- KVFinn 13y 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.
- ANTSANTS 13y 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.
jamesaguilar 13y 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 13y 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).
  - jamesaguilar 13y 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 13y 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 13y 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!
KVFinn 13y 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 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 https://twitter.com/ID_AA_Carmack/with_replies
- keyle 13y ago
  Thank you for the twitch link!
wtallis 13y 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 13y 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.
  - wtallis 13y 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.
seanalltogether 13y 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?
- cobrausn 13y 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.
  - seanalltogether 13y 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.
- toast0 13y 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 13y 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 http://www.phoronix.com/scan.php?page=news_item&px=MTEyMTc
- devx 13y 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 13y 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 13y 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 13y 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 13y 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.
    - Dylan16807 13y ago
      Maybe they were 256 megabit chips.
  - lambda 13y 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 13y 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.
bcoates 13y 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 13y 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.
  - bcoates 13y 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 13y 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 13y 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 http://hardforum.com/showthread.php?t=928593 Contrast it with what G-Sync is trying to achieve.
- aspensmonster 13y 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 13y 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.
    - aspensmonster 13y ago
      My understanding from nivla's link is that triple buffering does solve the problem. Rather than experiencing the Frequency/N fps drop when the card can't push out enough frames, triple buffering lets the display's framerate stay at the framerate the card is pushing, with the price being VRAM overhead. But perhaps I'm misunderstanding the problem statement. The link talks merely about fps drops and how triple buffering can permit the display to be more efficient than Frequency/N fps by essentially pipelining the frames over 3 buffers to keep the monitor's framerate at the graphic card's framerate. However, it accomplishes this by having some frames stay for 2 cycles and others for 1. I don't know how noticeable this is. Perhaps it's a perceptible problem, in which case being able to dynamically manipulate the display's refresh rate is a suitable solution. Granted, at the current price range it sounds like a cheaper solution would be to simply buy a newer model graphics card that can maintain an FPS greater than or equal to your monitor's refresh rate. Though of course I'm sure the goal is to drive the price down and it appears they already have display partners lined up to integrate their embedded DSP.
zokier 13y ago
This and Wayland and hopefully I will never ever see a teared or mistimed(stuttering) frame anymore. I can't wait.
hedgehog 13y 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 13y 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.
- jblow 13y ago
  You are correct. The whole reason things are set up this way is historical, compatibility with CRTs.
ComputerGuru 13y 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.
- Miyamoto 13y 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.
  - rdtsc 13y 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.
devx 13y 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 13y ago
For anyone excited about this, check out http://www.blurbusters.com/ http://www.blurbusters.com/. It's a blog dedicated to everything-refresh-rate.
jswanson 13y 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 https://twitter.com/ID_AA_Carmack/status/391299110344867841
Demiurge 13y 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 13y 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 13y ago
Are my eyes just that bad or is this solving a problem I didn't ever notice exists?
TheZenPsycho 13y 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 13y 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.
  - TheZenPsycho 13y 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?
    - jblow 13y ago
      See my Rocket comment above. But in reply to this specific comment I will drop you a hint (this hint is still just a small piece of the whole situation): 3D rendering is so deeply pipelined that it is difficult or even impossible for the program to know if a frame render is going to finish on time. It takes a long time to get information about completed results back from a GPU; on PCs you almost certainly can't get that info during the same frame you are rendering, unless you are rendering tremendously slowly. In order to make an estimate about whether the frame is going to be done in time, you would have to guess. Okay, then, so now you decided to stop rendering this frame, what do you do? Leave a giant hole in the scene? Turn off the postprocess? Draw low-detail versions of some things (hint: still very slow)? Your program does not even really know for sure which pieces of the scene are fast to render and which are slow. It does not know if specific textures are going to be paged out of VRAM by the time you get to a specific mesh, or not. etc etc
ConAntonakos 13y 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 13y 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.
asdfs 13y 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 13y 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 13y 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.
- YZF 13y 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 13y ago
    That doesn't seem to agree with http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgrounder.pdf http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgroun... .
JanezStupar 13y ago
Where is my Optimus driver for Linux?

191 points by cobrausn 13y 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-g-sync-revolutionary-ultra-smooth-stutter-free-gaming http://www.geforce.com/whats-new/articles/introducing-nvidia...

brymaster 13y 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 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 https://twitter.com/id_aa_carmack/status/391303627278925824

MBCook 13y 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.
- KVFinn 13y 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.

danmaz74 13y 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 13y 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/ http://www.engadget.com/2013/10/18/nvidia-g-sync/
baq 13y 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.
- danmaz74 13y 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.
  - reitzensteinm 13y ago
    The problem with vsync is that if your FPS drops below the refresh rate, the next frame is skipped, straight out halving your FPS. So if you have a 60hz display, and you're capable of rendering at 59fps smoothly, you actually end up rendering at 30fps. Worse, if you're alternating between 55-65fps due to subtle changes in scene complexity, the FPS will flip between 30fps and 60fps erratically, which is absolutely horrific (worse than just sticking at 30fps). To get smooth vsync 60fps, you probably want to be capable of running at 100fps on average, so there's a margin of safety and your worst case doesn't drop below 60fps. If this technology can make 55-65fps rendering seem as smooth as a 100fps capable machine with vsync enabled, it just nearly halved the system requirements. If it sounds like a mundane way to progress, that's because it is. All this is doing is replacing a system of bad design due to legacy reasons. Pushing data when it's done is almost always more sensible than an awkward fixed interval polling loop.

SmokyBourbon 13y ago

Could this be integrated into future versions of Nvidia's mobile gaming device?

staunch 13y 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 13y 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.
- staunch 13y 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.
KVFinn 13y 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.
ANTSANTS 13y 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.

jamesaguilar 13y 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 13y 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).
- jamesaguilar 13y 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 13y 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 13y 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!

KVFinn 13y 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 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 https://twitter.com/ID_AA_Carmack/with_replies

keyle 13y ago
Thank you for the twitch link!

wtallis 13y 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 13y 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.
- wtallis 13y 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.

seanalltogether 13y 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?

cobrausn 13y 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.
- seanalltogether 13y 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.
toast0 13y 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 13y 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 http://www.phoronix.com/scan.php?page=news_item&px=MTEyMTc

devx 13y 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 13y 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 13y 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 13y 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 13y 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.
  - Dylan16807 13y ago
    Maybe they were 256 megabit chips.
- lambda 13y 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 13y 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.

bcoates 13y 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 13y 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.
- bcoates 13y 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 13y 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 13y 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 http://hardforum.com/showthread.php?t=928593 Contrast it with what G-Sync is trying to achieve.

aspensmonster 13y 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 13y 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.
  - aspensmonster 13y ago
    My understanding from nivla's link is that triple buffering does solve the problem. Rather than experiencing the Frequency/N fps drop when the card can't push out enough frames, triple buffering lets the display's framerate stay at the framerate the card is pushing, with the price being VRAM overhead. But perhaps I'm misunderstanding the problem statement. The link talks merely about fps drops and how triple buffering can permit the display to be more efficient than Frequency/N fps by essentially pipelining the frames over 3 buffers to keep the monitor's framerate at the graphic card's framerate. However, it accomplishes this by having some frames stay for 2 cycles and others for 1. I don't know how noticeable this is. Perhaps it's a perceptible problem, in which case being able to dynamically manipulate the display's refresh rate is a suitable solution. Granted, at the current price range it sounds like a cheaper solution would be to simply buy a newer model graphics card that can maintain an FPS greater than or equal to your monitor's refresh rate. Though of course I'm sure the goal is to drive the price down and it appears they already have display partners lined up to integrate their embedded DSP.

zokier 13y ago

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

hedgehog 13y 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 13y 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.

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

ComputerGuru 13y 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.

Miyamoto 13y 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.
- rdtsc 13y 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.

devx 13y 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 13y ago

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

jswanson 13y 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 https://twitter.com/ID_AA_Carmack/status/391299110344867841

Demiurge 13y 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 13y 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 13y ago

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

TheZenPsycho 13y 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 13y 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.
- TheZenPsycho 13y 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?
  - jblow 13y ago
    See my Rocket comment above. But in reply to this specific comment I will drop you a hint (this hint is still just a small piece of the whole situation): 3D rendering is so deeply pipelined that it is difficult or even impossible for the program to know if a frame render is going to finish on time. It takes a long time to get information about completed results back from a GPU; on PCs you almost certainly can't get that info during the same frame you are rendering, unless you are rendering tremendously slowly. In order to make an estimate about whether the frame is going to be done in time, you would have to guess. Okay, then, so now you decided to stop rendering this frame, what do you do? Leave a giant hole in the scene? Turn off the postprocess? Draw low-detail versions of some things (hint: still very slow)? Your program does not even really know for sure which pieces of the scene are fast to render and which are slow. It does not know if specific textures are going to be paged out of VRAM by the time you get to a specific mesh, or not. etc etc

ConAntonakos 13y 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 13y 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.

asdfs 13y 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 13y 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 13y 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.

YZF 13y 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 13y ago
  That doesn't seem to agree with http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgrounder.pdf http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgroun... .

JanezStupar 13y ago

Where is my Optimus driver for Linux?