Does the F-buffer increase the # of instructions per pass?

[Himself]

Let me get this straight, the F Buffer gives you more instructions, not longer bits of code?

so if before you were limited to

for (i = 0; i< 20; i++);

you would now have

for (i = 0; i < SomeNumberBasedOnAvailableRamAndHowLongYouWantToWait(); i++);

Perhaps it means, you can run more than one shader one after the other, more optimally, but you couldn't have one super long procedure that is longer than the hardware limit?

 

[Luminescent]

Before it was possible to run arbitrarily long shaders, at the expense of multipassing. With the F-buffer, only the pixel pipeline runs through multiple passes, and the latency from one pass to another is virtually absent. So now, like you say, you can run from i=0 to i=infinity, and not suffer any overhead performance degradation (in theory).

 

[Dio]

That's not quite right.

The F-buffer is a better way of storing temporary results when multipassing - allowing shaders of arbitrary length in circumstances where usual multipassing techniques would fail - see the Stanford paper for more information on that.

You do still have to multipass, but if you're exceeding the shader resources on a chip that supports F-buffer nothing except your shader execution time matters, so the multipass actually costs virtually nothing.

See also this thread
http://www.beyond3d.com/forum/viewtopic.php?t=4717
which is a bit less speculative than this one.