F-buffer on ATI - How to use it?

[Jaromir]

ATI Radeon 9800 and X800 have the 'F-buffer' functionality (as mantioned in technical specifications on ATI www). Apart this, no other (more precise) information about how it is implemented and how can it be programmed. (The tech support of ATI gave me no information and passed me a link to google :-))
I read the article from Stanford from 2001, but this is only case-study.

Does anyone know how can I use F-buffer on these ATIs?

[Rodéric]

Isn't that a regular OpenGL Accumulation buffer ?

[Jaromir]

I don't think so,
f-buffer enables the possibility to store the fragments (and other intermediate results) in a FIFO buffer and pass them back to pixel shader "without writing each pixel to the frame buffer and taking another trip through the graphics pipeline"

http://tech-report.com/reviews/2003q1/radeon-9800pro/index.x?pg=1

[Rodéric]

Indeed, it's not what I thought, it reminded me the 3Dfx T-Buffer...

All those weird names...

So the F-Buffer is a loopback thing basically, I remember it now, however I'm not sure it's exposed in any API.

In theory it wouldn't need anything to work, in ARB_fp and GLSlang.

Don't have a R3xx+ board to check fragment program/shader capabilities.

[Chalnoth]

As far as I know, the F-buffer has never been enabled, in any form.

[AlphaWolf]

As far as I know, the F-buffer has never been enabled, in any form.

but... you don't know very much.

As for F-Buffer, it's expose through beta extensions right now in OGL. X800 series has seriously improved its ease of use and speed (which make it more in line with DX), so it might be something we could expose in the future in DX, but for now it remains an OGL feature.

From here (http://www.rage3d.com/board/showthread.php?t=33758176&highlight=f-buffer)

[bloodbob]

I think it might work with OpenGl ARB_FP.

[Chalnoth]

Well, then, I guess I'll have to amend that statement to say that it's never been enabled in any public API. Not exactly much of a change, if you ask me.

[Sigma]

I am almost absolutly sure it will be enabled under GLSL only. Since the driver compiles GLSL code, it will decide if it must break up the code with several passes using the F-Buffer in order to run the shader, instead of giving: "shader to long to run...."

[Chalnoth]

Since it was announced over a year ago, and GLSL drivers have been available for nearly as long, what makes you think that the F-buffer, which apparently has not yet been enabled for GLSL compiling, will be enabled in the future?

[Rodéric]

Since it was announced over a year ago, and GLSL drivers have been available for nearly as long, what makes you think that the F-buffer, which apparently has not yet been enabled for GLSL compiling, will be enabled in the future?

cause it would be stupid not to do so ?

[Dave Baumann]

IIRC, there may have been some issues with the R350/360 versions of the F-Buffer in that, I think, it would replicate every pixel regardless of whether it was touched on the extra passes, which kinda screws the memory up a bit. I believe this was resolved with R420, so for usability purposes it may end up as R420 (and later) only.

[Rodéric]

That's the only explanation I could find for ATI not to make use of it in GLSlang. (ie broken/slow hardware)

[bloodbob]

Since it was announced over a year ago, and GLSL drivers have been available for nearly as long, what makes you think that the F-buffer, which apparently has not yet been enabled for GLSL compiling, will be enabled in the future?

cause it would be stupid not to do so ?
As it would be stupid not to think that SSAA would come be introduced after they talked about it back around the R300 launch?