View Full Version : F-Buffer?

02-01-2004, 10:24 AM
Anyone have any concrete information on ATI's F-Buffer?

Can't find anything on ATI site, except mention of it in feature lists.

Searching here and on google, I find a claim of availablilty in cat 3.4, an interview (ca. Cat 3.6) saying 'It is exposed via OpenGL', another (ca. cat 3.8) saying '...planning on exposing it (through an OpenGL extension)', and various 2nd hand references to it being OpenGL2 only. No sign of specs or info on how it actually works though...

02-01-2004, 10:57 AM
No one really knows when it's gonna be officially exposed in drivers. Here's a link to a tech paper about it and different possible implementations of it, though:

02-02-2004, 10:29 AM
Personally, I think it won't be exposed. Even if used, I guess it's better to hide it in the driver.

Isn't the F-buffer that thing to run arbitrarly long programs? If it is not, my statement does not apply (I would have made a mistake).

02-02-2004, 12:12 PM
Yup, it's a fifo buffer for fragment information. It basically lets you store temporary results without writing them to the framebuffer. The major caveat is that it has limited size and being a FIFO subsequent fragment processing needs to pull the results off the FIFO in the same pixel order they were placed into it. Avoiding overflow is the big challenge.

The main tradeoff between exposing and not exposing (that I can see) is management of state changes. If it was just about shader complexity then it would be a nobrainer, you don't expose if you could get away with it. On the other hand to get full benefit you could throretically have arbitraty texture counts & other types of state etc as well. This may lead to an optimization nightmare with trading state changes for FIFO size etc.

Will they punt and leave it up to the app? Will they allow a huge FIFO and buffering the F-Buffer off chip to video memory? Will unlimited state complexity in addition to shader length be supported? Will it all happen automatically or require the application to rebroadcast geometry data for each pass?

Exactly how much of the benefits of the F-buffer will be implemented has yet to be announced. I hope it's completely transparent to developers and that they efficiently manage to blow the doors off current texture unit & register count limits, not just shader instruction length.