Nvidia's G-Sync: Attempting to Revolutionize Gaming via Smoothness
anandtech.com
anandtech.com
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.
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...
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.
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.
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.
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.
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 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."
- 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.
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.
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.
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)...
Details will vary between different displays but my point is that due to the pixels being on a grid sequential access is going to be faster. This is not unlike memory.
EDIT: Here's a reference that discusses scanning in a TFT: http://www.electronicsforu.com//EFYLinux/efyhome/cover/March...
"The TFT-LCD panel of the AMLCD is scanned sequentially line-by-line from top to bottom. Each line is selected by applying a pulse of +20V to gate line Gn, which turns on the TFTs in that specific row. Rows are deselected by applying –5V to G n-1 and G n+1, which turns off all the TFTs in the deselected rows and then the data signal is applied from the source driver to the pixel electrode. The voltage applied from the source driver, called ‘gray-scale voltage,’ decides the luminance of the pixel. The storage capacitor (CS) maintains the luminance of the pixel until the next frame signal voltage is applied. In this way, the next line is selected to turn on all the TFTs, then the data signal is fed from the source driver and hence scanning is done."
From my point of view you have not explained why it's not technologically feasible. You're merely describing that the current display tech isn't working that way.. of course not..
The motivation for the gridded layout is clear I think? You have this grid of transistors and you need to address them individually. Being able to drive an entire line and then select the columns is a good and relatively cheap solution. Now you can drive all pixels in one line concurrently if you need to and the performance of a single pixel becomes less of a bottleneck. So the row/col grid structure isn't a result of needing to be compatible with CRTs... Also naturally accessing in sequence allows you to simply send the data and clock down the line. Random access would require either multiplexing the coordinates or widening your bus.
I would imagine it's possible to design a random access LCD. You would need better performing individual pixels, you will almost certainly need more layers and more conductors, you will complicated your interfaces and protocols. So you end up with a more complex and expensive system for practically little benefit. In many applications (games, videos) all pixels change every frame.
Sub-scanning a rectangular portion of the display is maybe a more reasonable target.
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.
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
-------------
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.
http://www.twitch.tv/linustech/b/471263848?t=2h27m
Carmack answered some questions about it on twitter right after as well:
http://www.geforce.com/whats-new/articles/introducing-nvidia...
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.
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.
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.
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.
Put it in the next HDMI spec (and the rev the spec fast, not another 2 years or so).
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?
However, in simpler scenes the same renderer is likely to output significantly more frames (even up to thousands) at the same detail level.
So in this scenario, all you're doing by setting a fixed rate is throwing away tons of frames in low density scenes. Most gamers would prefer to have the most fps possible at any given moment, even if it means variability.
The most hardcore gamers I know use 120hz monitors, and machines that can deliver 241fps (120 * 2 + 1) in the highest detail scenes. They then set the engine to cap frames at 241fps which will eliminate tearing, negating the need for this technology. However, their gaming machines cost a LOT, so this would deliver similar results for a much wider range of hardware.
sigh why am I explaining this again? is it really hard to understand? why?
Having a consistent 40fps is much worse (for a gamer) than a variable framerate that will dip down to 40fps for 1% (or 10%) of the play time. Having to limit your most complex scene to what can be guaranteed rendered at 60fps is much less appealing to a developer than making sure all the likely scenes can render at 60fps.
stuttering animations is better than smooth animations?
Stuttering is better than smooth. gotcha.
> Your question was answered;
for someone who doesn't appear to understand what I'm asking you have a high degree of confidence that I've been answered.
What is so terrible about having a lower complexity budget that guarantees 60fps? What if you had 60 fps no exceptions as a constraint in your hardware and software design, how far could you really go with some creativity? Think about it- is having a complexity ceiling the only possible way to ensure 60fps?
>Think about it- is having a complexity ceiling the only possible way to ensure 60fps?
I'm really not following you. Are you asking what is the benefit of this technology when games come out every day at 60fps even now? This technology allows them to get the same fidelity and smoothness on less powerful hardware, with more complicated simulations, and lower latency.
Are you asking why renders can't maintain perfectly steady frame rates without going above or below 60fps, regardless of WHAT they are rendering on screen or what is happening in the simulation? You can't see how that's a 'non trivial' problem?
The most notable example of a game using dynamic tradeoffs to maintain a solid 60FPS is ID's Rage engine -- written by Johh Carmack, one the people on stage at this very presentation, who was lauding this technology and saying he has been pushing GPU and monitor manufacturers to implement this for years.
Carmack notes that while they were able to stay at 60 with an incredible amount of work, if they had been able to target 90% of 60fps with this technology there would have been little visual difference but the gameplay and visual complexity ceiling would have been vastly higher.
I'm asking someone to explain this. because I don't get it.
Isn't meeting the frame deadline kind of more important than scene complexity?
Pro Tip: If an entire industry of experienced people finds something very hard, and you don't know anything about the topic but you don't see why it would be hard, maybe the relevant factor here is the "you don't know."
It reminds me of my mom who said on multiple occasions "All these rockets are dangerous and they explode; I don't see why the scientists don't just use the majestic forces that keep the planets in their orbits to move the rocket."
do you understand? "because it's hard" is not an interesting answer. It's a boring and contentless answer.
Basically, a GPU is a very complex computer with several hierarchies of execution streams e.g. there are vector SIMD streams that execute same code over different data, there are threads of such streams that preempt each other, there multiple processing units each running a set of such threads, and there are even structures of such processing units. Yet all of this is hidden from the programmer and only API there is an abstract "scene" description. E.g. you can say "first render these polygons with such and such settings, then render other polygons with other settings, then show what is rendered so far and return to the default state".
Going from such a high level description to the thousands of execution streams that GPU will execute is a very complex procedure that changes with each driver version and is not fully understood by any single person. On top of this you have other processes running on your machine while playing the game and they can and will steal CPU and the OS scheduling slots, adding a lot of variance to your frame time.
You can render the same data set several times and sometime it will take 10ms but other times it will take 100ms depending on what other processes decided to do at the time so it's impossible to guarantee constant frame time on PC.
On consoles it's not a big deal as you can program the GPU directly and don't compete with other processes. A great number of games do run with constant frame rate - it's not trivial but it's not a rocket science either.
As for the start of an answer, what was wrong with just .. starting with that? What was the point of all the other stuff you wrote? Think about it. what is your mission here? to be informative or just to attempt to make me feel bad for being curious?
Seriously I will not tolerate this curiosity shaming, the ethic that one should feel embarrassed about asking questions. I do not buy the idea that it is condescending to be dissatisfied with shallow lazy nothing answers. I have no control over you perceiving it that way. It is just a flaw in your background that you should perhaps be more self aware about.
No, they are being rude. There was no reason to post that verbal diarrhoea and I'm just not taking it like a doormat, and that bothers you. The common factor is them being dickheads. If you look, there are lots of other thoughtful people answering me (with real actual answers and creativity instead of condescension) that I am rewarding and conversing with appropriately.
The common factor is the culture of curiosity shaming here. And sorry, but quite frankly you and them can just get fucked. I don't care if you think I am being rude. I want to be rude about that. It is internet cancer. Other thoughtful people should be rude about it too. I want to shoo that attitude away from everywhere I can. Not walk on eggs just in case someone might take offense. You have no interest in making me "self aware". You just see a nail sticking up and you want to hammer it down.
I don't know what to say about you telling me what my motivations are. Stop snapping to self-righteous conclusions.
Deleted comment
I was really hoping you wouldn't pull this into an argument about semantics. Since you did, I'm almost certain this will be my last post.
'smug' was a description of your mannerisms, not your motivation. And 'snapping' is only pointing out that you made your pronouncements based on three sentences. I am making no claim to psychological insight.
I just think you're acting like a petty jerk, and blaming everyone else.
Look, It's simple:
Aut Tace Aut Loquere Meliora Silentio!
THAT is petty and obnoxious. and it is to that I say, "get fucked." Criticizing superficial aspects about my manner, instead of the content of my question is the very definition of petty.
There seem to be two ways to interpret your question:
>1.) Why can't games render 60 frames per second always?
Because some scenes are more complex than others. Rendering a complex scene can longer than 16.7 ms, and there is no way around that.
>2.) If a game comes far below the frame completion deadline (e.g., completes a frame in 0.5 ms, where the deadline is 16.7 ms), why doesn't it simply stop doing anything until the deadline has passed?
I do not know the answer. But I can say that many games actually do this. It is usually referred to as a frame cap.
Furthermore, 60 fps is not "just under the limit" for what a human can see; read e.g.:
Nowadays when I program games, I cannot get a promise that a frame event will fire. I can get a "well, this code may run, unless the operating system needs those cycles".
So, so is skipping a whole frame, OR halving the frame rate really the best that is possible? Why is it either/or? What are operating systems, hardware vendors and driver writers doing about it?
But that is not what tearing is. Tearing is, you've missed the deadline, so you finish the rendering to completion, then swap the buffer in the middle of a vertical scan. What you're saying is, you can do that, or wait until the next vertical scan before swapping the buffer. And further more, that can either result in simply a skipped frame, or the game switches down to a 30fps mode, perhaps based on some running statistical about frame render durations.
I'm reminded about a discussion Carmack (was it him? or am I having a brain fart) about mitigating the tearing and framerate problem by doing per scanline rendering instead of per frame rendering.
hmmm! I will have a long think
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
Though come to think of it, there is one example that almost does what you describe. Dynamic resolution scaling has some artifacts, but is being used in some games (and is notably used in Dead Rising 3). Though one has to decide before the frame is rendered what resolution to use, so you still get frames that take longer than 16.7ms or whatever your target is.
One could do something similar with render quality, but it has the same drawback that you have to decide beforehand what quality you want to use. One would also have to ramp up and down the quality slowly, which is difficult as the complexity of a given scene can vary wildly over the space of a single second. It also wouldn't help with spikes in rendering time.
"One could do something similar with render quality. There are possible solutions, and I'm thinking creatively about it."
Thank you for taking the time to answer me. <3
Rendering a scene is kind of like constructing a building. If you stop at an arbitrary point in the construction process, you don't get a pretty good building, you get a non functional structure.
The real reason is that there might possibly be some way of doing a progressively enhanced, rendered game but it's never been high enough priority for anyone to have done serious work in that area.
The point is, this isn't a direction that cutting edge games programming has gone in, because getting more detail into the game has always been a higher priority than having a steady predictable framerate- And to make a further point, practically speaking, painter's/z-buffer algorithm is easier to optimise than some other rendering algorithms. Though, the others are not impossible, just not fruit that is quite as low hanging.
Dude seriously, I have been doing this a long time. I am going to stop replying after saying just one more thing:
If you are running on an OS like Windows (which this product is targeted at), you do realize that the OS can just preempt you at any time and not let you run? How do you predict if you are going to finish a frame if you don't even know how much you will be able to run between now and the end of the frame?
There's no point at which you have a usable partial frame to display, and it doesn't make sense to compute every other pixel, and if there's time come back and get the rest, because computing a pixel's neighbor will need a lot of the same intermediate work, and you probably don't have the resources to keep that. Parallel rendering generally divides the rendering tasks into different regions of the screen for each unit, not interleaved pixels.
To answer your question regarding why not just use 40fps, instead of going up and down; If you cap framerate at 40fps and your monitor doesn't refresh at an even multiple of 40, you're going to end up with consistent judder which is probably worse than occasional framerate dropping.
If you look at it from the other side, look at all the extra buffers that are needed to support fixed framerate monitors when frame generation really doesn't need to be fixed. At the desktop, if nothing on the screen moves, there's no need to transmit the buffer 60x per second, except for legacy reasons, in a graphics intensive application, the time to generate a buffer may vary. Video usually was recorded at fixed frequency, but it often doesn't match the frequency of the monitor. CRTs absolutely required that the electron beam trace every pixel several times a second, but LCDs don't.
Here's an idea I am curious about now. If you can almost but not quite reliably generate full res images at 60 FPS, can you generate quarter resolution (that is, half the pixels on each dimension for a quarter of the pixels) at 240 fps, or does the overhead for each render outstrip the efficiency from generating fewer pixels? That is, how much of a fixed overhead for a frame is there, and can it be spread over 4 frames, with slightly offset camera?
But on the other hand I was confused- I forgot that zbuffer was the algorithm still in use in most game rendering engines. and you cleared that up. thanks.
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.
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.
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 :)
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.
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.
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.
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.
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.
It makes way more sense to me than carrying over the limitations of old (CRT) technology.
They're going to make hardware manufacturers that strictly focused on streaming capabilities go out of business.