> 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.
>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.
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.
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/
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.
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.
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.
>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.
If the game never drops below 144 then it's not going to be very noticeable, still get extra performance of having vsync off and lower latency though. Even if you could run something that fast, though, it would likely be better overall if you could run it slightly less fast but with higher quality lighting model enabled or whatnot.
And so another way of looking at is: this lets you run at high quality than before, resulting in lower framerates of 30 - 60, because the negative effect of those lower frame rates between 30 and 60 is so minimized.
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.
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.
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 :)
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.
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.
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.
I thought I was pretty clear about that. Synchronization is relatively straightforward in a realtime system, where your program has total control over the timing of execution. On a desktop operating system, however, the graphics card and its drivers can lie, the operating system can lie, the operating system can swap your process out for something else whenever it wants, there is a delay associated with accessing a PC's high accuracy timer (so even the clock lies!), and on top of that, everyone's PC is different. It's still possible to get some rough degree of synchronization going, but it's very difficult and imperfect.
If you still don't think I'm being serious about the timing stuff, consider that some folks still keep around old machines running DOS for real-time communication with microcontrollers.
Now this is interesting. What can operating systems, drivers, and GPU manufacturers do to restore a DOS like real time sync of frame generation/transfer/display.
Now that every gamer has a multi-core processor, couldn't you allocate n-1 of them to the game with guaranteed non-preemption, and have one core where pre-emption can occur?
it's kind of a cool idea. I wonder if OS's would ever implement something like this. You would probably need to put some iOS like restrictions on it- only one app at a time, it must be running full screen in focus, and cannot be given that kind of priority in the background. Like having a dedicated built in console system.
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.
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).
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.
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?
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).
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").
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.
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.
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.
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?
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.
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.
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)
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.
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.
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?
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
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.
> 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.
If you get a chance, demo a 120hz monitor setup and spin around quickly in an FPS. It's quite noticeable. It almost feels extra surreal a la the Hobbit at 48fps until you get used to it.
It's not really about the latency (5ms vs 1ms is negligible), but its about the pixel response to reduce/eliminate ghosting and other artifacts of LCD's persistent pixels. The speed that the pixels can update is proportional to the amount of ghosting. Interestingly enough, it won't eliminate it no matter how fast the pixels update. The real problem with ghosting turned out to be precisely the pixel-persistence. Even more interesting is that someone discovered a hack for the modern 3D monitors like the ASUS mentioned that completely eliminates ghosting: the strobing backlight functionality necessary for 3D completely eliminates ghosting when applied to 2D. I currently have this setup and its exactly like using a CRT. A flat, light, 1920x1080 CRT. It's beautiful.
He's actually completely wrong. Persistence is about image quality, and can be mitigated by filtering that hardcore gamers always turn off, because it costs them latency.
Reducing latency isn't about how noticeable it is. Latency can be completely impossible to detect for you but still hurt you.
Input lag is the time between providing some input, such as clicking with your mouse, to getting feedback of this event on the screen. As the clicking will be prompted by things happening on the screen, input lag acts as a command delay to everything that is done. The most interesting feature of latency is that all latency is additive. It doesn't matter how fast or slow each part in the system is, none of them can hide latency for one another. Or, even if the game simulation adds 150ms and your stupid wireless mouse adds 15ms, the 2 ms added by the screen still matter just as much.
The second mental leap is that the human controlling the system can also be considered to be just another part in the pipeline adding latency. Consider a twitch shooter, where two players suddenly appear on each other's screens. Who wins depends on who first detects the other guy, successfully aims at him, and pulls the trigger. In essence, it's a contest between the total latency (simulation/cpu + gpu + screen + person + mouse + simulation) of one player against the other player. Since all top tier human players have latencies really close to one another, even minute differences, 2 ms here or there, produce real detectable effects.
This is completely wrong. When even the fastest human reaction time is on the order of 200ms, 5ms vs 1ms of monitor input lag has no effect on the outcome. Also consider that 5ms is within the snapshot time that servers run on, so +/- 5ms is effectively simultaneous to the server on average.
Pixel persistence is not about image quality and cannot be mitigated by anything, except turning off the backlight at an interval in sync with the frame rate you're updating the image. This is how CRTs work, and that's why they had no ghosting effects. The 3D graphics driver hack I mentioned does exactly that for 3D enabled LCD monitors.
But it doesn't average out. The 5ms player is continuosly 4ms behind the other player. As above poster explained - the times add up. So you have 200ms + one to five ms. If server tick is as little as 5ms the problem is even worse as in that case player A will with exact same reactions get a faster tick in 4 out of 5 times. I don't know how often it matters, but I'd expect top player to have pretty similar reaction times. So let's say 2 opponents are both between 200 and 220 ms reaction time - then constantly having 4ms more for one player definitely sounds like it will have an effect.
edit: Or in other words - it depends on how often the reaction of the opponents is with the 4ms difference. That certainly depends on the game and the players.
Most server ticks are nowhere near 5ms. Quake 3 ran on 20-30 tick, CS:S/CS:GO runs on 33 by default and up to 66 if you run on high quality servers. 100 tick was somewhat common in CS:S. Some really expensive servers claimed 500 tick but I never bought it. Either way no one's client would update that fast.
Furthermore, if you watch pro matches, you'll quickly realize their skill has nothing to do with having the fastest reaction time. Once you get to a certain skill level, it all comes down to game knowledge. Having a consistent 4ms advantage is absolutely negligible.
People can notice input latencies that are many times smaller than their reaction time. 200ms of input latency is going to be noticeable and bothersome to basically everyone for even basic web browsing tasks. Most gamers will notice more than 2-3 frames of latency, and even smaller latencies will be noticed in direct manipulation set-ups like touchscreens and VR goggles where the display has to track 1:1 the user's physical movements.
I think you misunderstood my point. In terms of actual advantage, 1ms vs 5ms is negligible, considering the fact that human reaction time is 200ms. So in the case of shooting someone as they popped out from behind a corner, the 200ms reaction time + human variation + variation in network latency + discreet server time, will absolutely dominate the effects.
I definitely agree that small latencies can be noticed, even latencies approaching 5ms (but not 5ms itself--I've seen monitor tests done that showed this).
> I think you misunderstood my point. In terms of actual advantage, 1ms vs 5ms is negligible, considering the fact that human reaction time is 200ms.
You did not understand the point of my post. The quality that matters is total latency. How long a human takes to react is completely irrelevant to what level of latency has an effect. Whether average human reaction time was 1ms or 1s doesn't matter. All that matters is that your loop is shorter than his, and your reaction time is very near his, so any advantage counts.
> the 200ms reaction time + human variation + variation in network latency + discreet server time, will absolutely dominate the effects.
Server tick time is the same for everyone. Top level gaming tourneys are held in lans, where the players typically make sure that the network latency from their machine to the server is not any greater than from anyone else. However, none of that matters to the question at hand.
Assume that total latency of the system, including the player, can be approximated by:
and assume all are normally distributed random around some base value, except display lag, and you have:
(midpoint, standard deviation)
rand(200,20) + rand(20,5) + rand(16,2) + 15
while I have:
rand(200,20) + rand(20,5) + rand(16,2) + 5
The total latency is utterly dominated by the human processing time. Yet if we model this statistically, and assume that lower latency wins, the one with the faster screen wins 63% of time. That's enough of an edge that people pay money for it.
No I understood your point, I just don't agree that it results in any meaningful advantage. What you didn't model was the fact that the server does not process packets immediately as they are received. They are buffered and processed in batch during a server tick. If the two packets from different players are not received along a tick boundary, then the server will effectively consider them simultaneous.
And remember, we're considering 1ms vs 5ms, so the difference would be 4ms in this case. I would like to see what percentage an advantage someone has in this setup. Even 63% isn't anything significant considering skill comes down to game knowledge rather than absolute reaction time. People will pay for smaller/bigger numbers, sure. But that doesn't mean there is anything practically significant about it.
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.
Hardcore gamers are not a great source of income however a great marketing resource for nvidia. They are very influential on others when choosing products. They also represent a large portion of the review industry online.
Having the crown for best graphic card even translates to sales on low end laptops.
Exactly, especially in the Twitch.tv and eSport era. Sponsored players flaunt their hardware, often linking to Amazon product pages or giving hardware away in their Twitch channels. These professional players have tens of thousands of viewers, and thousands of subscribers, on Twitch. There's a lot of marketing to be had.
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.
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?
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.
161 comments
[ 2.6 ms ] story [ 235 ms ] threadhttp://www.geforce.com/whats-new/articles/introducing-nvidia...
- 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
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.
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.
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/
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.
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.
If the game never drops below 144 then it's not going to be very noticeable, still get extra performance of having vsync off and lower latency though. Even if you could run something that fast, though, it would likely be better overall if you could run it slightly less fast but with higher quality lighting model enabled or whatnot.
And so another way of looking at is: this lets you run at high quality than before, resulting in lower framerates of 30 - 60, because the negative effect of those lower frame rates between 30 and 60 is so minimized.
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."
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.
Anyway, I would be curious to try to see if I could notice a difference. Math can take us just so far :)
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.
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.
If you still don't think I'm being serious about the timing stuff, consider that some folks still keep around old machines running DOS for real-time communication with microcontrollers.
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.
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).
Genuinely curious, thanks!
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?
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.
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
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.
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
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.
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?
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.
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.
Put it in the next HDMI spec (and the rev the spec fast, not another 2 years or so).
http://hardforum.com/showthread.php?t=928593
Contrast it with what G-Sync is trying to achieve.
With something like G-Sync you can instead show 55 frames per second.
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.
It makes way more sense to me than carrying over the limitations of old (CRT) technology.
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.
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.
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.
If you get a chance, demo a 120hz monitor setup and spin around quickly in an FPS. It's quite noticeable. It almost feels extra surreal a la the Hobbit at 48fps until you get used to it.
Reducing latency isn't about how noticeable it is. Latency can be completely impossible to detect for you but still hurt you.
Input lag is the time between providing some input, such as clicking with your mouse, to getting feedback of this event on the screen. As the clicking will be prompted by things happening on the screen, input lag acts as a command delay to everything that is done. The most interesting feature of latency is that all latency is additive. It doesn't matter how fast or slow each part in the system is, none of them can hide latency for one another. Or, even if the game simulation adds 150ms and your stupid wireless mouse adds 15ms, the 2 ms added by the screen still matter just as much.
The second mental leap is that the human controlling the system can also be considered to be just another part in the pipeline adding latency. Consider a twitch shooter, where two players suddenly appear on each other's screens. Who wins depends on who first detects the other guy, successfully aims at him, and pulls the trigger. In essence, it's a contest between the total latency (simulation/cpu + gpu + screen + person + mouse + simulation) of one player against the other player. Since all top tier human players have latencies really close to one another, even minute differences, 2 ms here or there, produce real detectable effects.
Pixel persistence is not about image quality and cannot be mitigated by anything, except turning off the backlight at an interval in sync with the frame rate you're updating the image. This is how CRTs work, and that's why they had no ghosting effects. The 3D graphics driver hack I mentioned does exactly that for 3D enabled LCD monitors.
edit: Or in other words - it depends on how often the reaction of the opponents is with the 4ms difference. That certainly depends on the game and the players.
Furthermore, if you watch pro matches, you'll quickly realize their skill has nothing to do with having the fastest reaction time. Once you get to a certain skill level, it all comes down to game knowledge. Having a consistent 4ms advantage is absolutely negligible.
I definitely agree that small latencies can be noticed, even latencies approaching 5ms (but not 5ms itself--I've seen monitor tests done that showed this).
You did not understand the point of my post. The quality that matters is total latency. How long a human takes to react is completely irrelevant to what level of latency has an effect. Whether average human reaction time was 1ms or 1s doesn't matter. All that matters is that your loop is shorter than his, and your reaction time is very near his, so any advantage counts.
> the 200ms reaction time + human variation + variation in network latency + discreet server time, will absolutely dominate the effects.
Server tick time is the same for everyone. Top level gaming tourneys are held in lans, where the players typically make sure that the network latency from their machine to the server is not any greater than from anyone else. However, none of that matters to the question at hand.
Assume that total latency of the system, including the player, can be approximated by:
Human_reaction_time + network_lag + processing_lag + display_lag
and assume all are normally distributed random around some base value, except display lag, and you have:
(midpoint, standard deviation)
rand(200,20) + rand(20,5) + rand(16,2) + 15
while I have:
rand(200,20) + rand(20,5) + rand(16,2) + 5
The total latency is utterly dominated by the human processing time. Yet if we model this statistically, and assume that lower latency wins, the one with the faster screen wins 63% of time. That's enough of an edge that people pay money for it.
And remember, we're considering 1ms vs 5ms, so the difference would be 4ms in this case. I would like to see what percentage an advantage someone has in this setup. Even 63% isn't anything significant considering skill comes down to game knowledge rather than absolute reaction time. People will pay for smaller/bigger numbers, sure. But that doesn't mean there is anything practically significant about it.
It just seems like a bit of a sensational claim..
Having the crown for best graphic card even translates to sales on low end laptops.
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."
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...
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.