Unfortunately, NVENC is as much of a black box to developers as it is to end users. There's no documentation about two-pass encoding; it's just a bunch of rate control modes labeled '2_PASS'.
It's not the same as x264's 2-pass encoding. Conceptually, it encodes twice to get closer to the target bitrate, but it works on a per-frame basis and is meant for low-latency applications. By low-latency, I mean things like playing PC games on an NVIDIA SHIELD, where there's virtually no buffering and pictures are displayed as soon as they're received.
Normally, a rate control algorithm doesn't know how big a coded picture will be before it's made, so it makes a guess based on prior frames. For example, if the last frame ended up too large, it lowers the quality. This works fine for most purposes, but with low-latency streaming, it's important that each coded picture doesn't go over a certain size. With 2-pass, the encoder does a mock coding to get an idea of how much the frame costs and then performs the final encode with that information. If a sudden movement in the scene causes the size to increase, rate control must reduce the quality so that it doesn't go over the limit and take too long to transmit.
The 2-pass algorithm also has the ability to detect scene cuts and double the amount of bits for them. The idea is that it's better to delay a scene change by one refresh rather than display it instantly with poor quality.
These features aren't very useful for regular live broadcasting, but there are other differences in this algorithm that are not yet known. Maxwell GPUs are fast enough to do 2-pass encoding at 1080p60, so you should try it out and see if it looks better.
For local recording, you will likely not see any benefit at all.
