The truth about PRE-RENDERING 0?

[boom12a1]

I used to have it set at 0, since it was taken out it is now set at 1. I don't remember seeing any difference without it.

[Cyberdyne]

@Prophet
You buy a nvidia card and use drivers on the nvidia card made by nvidia for their cards.
But you obviously know more than them about the cards they make and the drivers that run them.

No one is saying that people can not detect minuscule amount of delay, what we are saying is the delay you thought setting pre-rendering to 0 was getting rid of, was never gotten rid of.

If you are not willing to learn from those who know more than you then you are going nowhere fast.

[Prophet]

Originally Posted by Cyberdyne

@Prophet
You buy a nvidia card and use drivers on the nvidia card made by nvidia for their cards.
But you obviously know more than them about the cards they make and the drivers that run them.

No one is saying that people can not detect minuscule amount of delay, what we are saying is the delay you thought setting pre-rendering to 0 was getting rid of, was never gotten rid of.

If you are not willing to learn from those who know more than you then you are going nowhere fast.

Thanks for sharing your insight as to how my life is going I really appreciate it and your opnionion clearly matters to me. I suppose you believe what nvidia is saying even though they have a history of being less than honest. 1 frame (difference between 0 and 1) is about 10 ms its pretty easy to notice. Also when what I base my opinion is between what someoen else is saying and what I can measure, what I can measure always wins.

Also theres logic involved. Its a difference of 1 frame. Are you saying that somehow magically there is a difference between 1 and 2 frames but not 0 and 1.

Those two compromise what some would call 'thinking for yourself'. Please try it, its a little more work but totally worth it.

Ps. http://forums.guru3d.com/showpost.ph...7&postcount=12

[Cyberdyne]

You are an easily offended person aren't you. I have no idea where you are coming from with that first sentence. I know nothing about you, and I made no comment on your life (thus the confusion). Relax buddy.

I'm annoyed by when people say these types of things are opinions. For a lot of things, there is no opinion, only fact. Just like the laws of physics, technology by it's very nature is a fact oriented subject. Either it is or is not. And if it is not, - then it's repeatable.

Let's be honest for a second. You get off on yourself. Your post stink of egotistical behavior.

[Prophet]

Originally Posted by Cyberdyne

You are an easily offended person aren't you. I have no idea where you are coming from with that first sentence. I know nothing about you, and I made no comment on your life (thus the confusion). Relax buddy.

I'm annoyed by when people say these types of things are opinions. For a lot of things, there is no opinion, only fact. Just like the laws of physics, technology by it's very nature is a fact oriented subject. Either it is or is not. And if it is not, - then it's repeatable.

Let's be honest for a second. You get off on yourself. Your post stink of egotistical behavior.

That sure is a lot of opionions for someone claiming to talk about facts. Sorry mate, but when I take advice its usually from people smarter than me.

And lets be really honest. When someone starts to talk about 'ego' I guess they have to have a huge ego.

[rewt]

Originally Posted by The Chubu

No, it is bs. 0 cannot exist.

The GPU doesn't gets all the data it needs magically because you set up your frames to 0.

It's not BS. 0 did exist, and it had a clear effect (which I've already demonstrated with benchmarks). That is, until NVIDIA removed it.

0 didn't mean that CPU didn't pre-render frames, rather it forced the graphics system to work in an even more serial fashion (rather than parallel), which is why FPS often suffered so much.

[Iruwen]

Originally Posted by rewt

0 didn't mean that CPU didn't pre-render frames, rather it forced the graphics system to work in an even more serial fashion (rather than parallel), which is why FPS often suffered so much.

Pretty much sounds like you just made that up. I'm still looking for a proper explanation of what a setting of 0 should do.

[rewt]

Originally Posted by Iruwen

Pretty much sounds like you just made that up.

I suppose it would, even the folks at NVIDIA seemed confused by it.

Imagine the driver blocking until the GPU actually finished rendering/displaying the current frame, that's what 0 did (or at least very similar). That is what I meant by serial. The more pre-rendered frames you add, the more parallel processing becomes, and the more performance improves (granted the law of diminishing returns).

But I suppose I just made all of that up too.

[rewt]

It seems like our friend Timothy Lottes (FXAA developer) understands it quite well.

Originally Posted by Timothy Lottes

For DX, the vendor's graphics driver is cut into two parts, user-mode and kernel-mode, and in-between is a Microsoft layer which controls memory managment and GPU scheduling. When the application issues a DX API call, this hits the graphics vendor's user-mode driver (which note might queue the API call to a user-mode driver background thread, and then immediately return so the game thread can continue to issue draw calls as fast as possible). When the user-mode driver (finally) processes the API call, it queues grouped commands to the Microsoft layer which schedules the groups, then eventually passes the groups of commands to the graphics vendor's kernel-mode driver which then enques the groups of commands to the GPU.

Latency of the PC DX driver stack depends on when all these threads physically get scheduled on the machine. Quality of service of frame rate also depends on when these threads get scheduled on the machine. Since the Windows CPU scheduler cannot insure real-time scheduling, the DX driver stack utilizes a latency buffer of up to 3 frames before the GPU starts to render if the application is GPU bound.

Two to three frames of latency is typical of the PC driver stack. For this reason, many serious gamers disable v-sync, accept tearing, and attempt to maximize frame rate --- all in the name of reducing input latency.

Some games introduce GPU queries to force the PC driver stack to remove these extra frames of latency. This can result in the GPU idling waiting on the long CPU pipeline to feed in commands. When doing this it is likely a good idea to insure some idle CPU hardware threads which can be used by the driver threads.

The above statement in bold demonstrates the behavior of pre-rendered frames 0 that I've been trying to point out all along (you can even go back and check out the benchmarks I posted several pages back). NVIDIA reps (nice as they are) couldn't even explain the results, they simply used the excuse of "driver optimizations", which is just flat out wrong sorry (I already explained that the difference between 1 and 0 can be detected using the same driver version).

Originally Posted by Timothy Lottes

Quick Estimates of PC Latency
Lets start with speed of light for a 120Hz display with 6ms latency over scan-out, but lets skip over some important details: 8.3ms rendered frame + 8.3ms scanout + 6ms display = 22.6ms. Now if DX driver stack buffers an extra 1 frame = 31ms. Or 2 frames = 39ms. Or 3 frames = 47ms. Which is starting to get near the latency of a 60Hz console title with a good HDTV. That's at 120Hz, if your PC title is 30Hz then the 2-3 frames of PC DX driver stack latency is a huge deal.

How about my setup with a mid-range GTX 560ti. I've removed the driver buffering problem by my CPU input thread writing directly into a pinned memory buffer, with the GPU reading input from pinned memory directly then computing the view matrix and storing to the constant buffer right before the GPU renders the view-dependent part of the frame. My crappy mouse is 8ms of latency, and I have say 12ms/frame of view-dependent GPU work. Expected total latency: 8ms mouse + 12ms drawing + 4ms v-sync window + 16.7ms scanout + 18ms plasma display = 59ms expected mouse to display. Hopefully right in-line with a good 60Hz console experience.

Continuing with a high-end GPU with a gamer mouse and good PC display: 1ms mouse + 6ms drawing + 2ms v-sync window + 8.3ms scanout + 5ms display = 20.3ms.