Now, I am not an expert on CF/SLI but let's consider two of the common rendering methods, either alternate frame rendering (each GPU renders the other frame), scissor frame rendering (each GPU renders some part of a screen, separated horizontally). In both cases it's quite apparent that you don't even need to have the entire frame buffer of the other video card in memory. In AFR you just need the frame every other frame, in SFR you'd only need the part of the frame that you are actually rendering.
Separate post to highlight my mistake before..
I'd imagine that in an AFR scenario each gpu would still maintain a two buffers so that they aren't sitting idle when they complete the frame they are currently responsible for. Assuming that, one would wonder where the active front buffer "exists", and how it's shifted.
I don't know if that's really the case though; I've read (please confirm) that one can only enable triple buffering with one or three GPUs, not two. Why would that be? I have a hunch that the answer to that may lead to at least more info about the frame buffer question...
This may contain some interesting info...
http://www.google.com/url?sa=t&source=web&ct=res&cd=1&ved=0CAYQFjAA&url=http%3A%2F%2Fdeveloper.amd.com%2Fmedia%2Fgpu_assets%2FProgramming_for_CrossFire.pdf&ei=5OmKS8XoI6XcM8j51KUB&usg=AFQjCNFrFaZY5N7TwwLsmzi_nwril-CIEw
From that document:
In some cases it might be desirable to detect if an ATI graphics system is capable of working in one of
the CrossFire™ modes. For example, when developing an AFR-friendly application, one might want to
allocate twice as many render targets to remove inter-frame dependency between cards as was described
in one of the earlier sections. The latest version of the RADEON™ SDK ships with the DLL that
provides CrossFire™ detection functionality. This library is located in “ToolsCrossFire Detect” folder
of the SDK and may be freely redistributed as a part of your application
Here's an NV equiv: http://http.download.nvidia.com/developer/presentations/2005/GDC/OpenGL_Day/OpenGL_SLI.pdf
Interesting... I don't have time to go through them now though. Please note that the docs are old so it's very possible the methodology may have changed since the they were created.