Not being identical doesn't mean they don't both have a copy of the data - as explained already, the data can be duplicated and modified so they both have data but it's not mirrored (identical)
Games use AFR almost exclusively so you require very close to everything being duplicated.
VRAM doesn't stack, that is not a myth, as it would only stack if you could add the two quantities up which is never true. That isn't the same as never getting any benefit from the extra, which is overlapping not stacking.
The guy is correct that in non-gaming situations the gains can be very significant however.
Edit: Man, I wrote this badly.
I'll try to use an imaginary example. We want to draw a coin (flat faced cause it's easier) spinning using AFR.
Each GPU will have a copy of the coin textures (say heads, tails, side) - these are identical (mirrored).
Each GPU will also calculate what will be shown based on the coins angle for their frame. This will be different on each GPU as they're drawing a different frame where the coin is at a different angle, so this information is not mirrored. However, this info still takes up space on each GPU so individual frames cannot require more available memory than if we were using a single GPU solution.
Now imagine we were using split-frame rendering.
Initially it looks like no change. However, we could optimise by splitting our textures so they're now top_heads, bottom_heads, top_tails, bottom_tails etc. We still need to do the calculations as above, but for less of the coin so this takes slightly less space too. Woohoo, lower memory use! We could have a larger texture for the coin to make it look better. However, if the coin is ever to be drawn spun in a non-totally flat way then we'd need the full texture, so that optimisation probably won't have been done as we'd not know what divisions of the texture file we need. Also, imagine the coin is reflecting light onto whatever surface it's spinning on, using ray tracing (OK, unlikely, but it's an easy example, so sue me!
). The bottom-image GPU should be drawing this onto the surface, but how can it know what to draw given it doesn't know what the top part of the coin is doing? (Especially if we imagine a coin with features like the head being slightly raised etc rather than a flat coin) Suddenly we've got a very tough problem that results in poor performance when we could have stuck with AFR and never had the issue.
In non-gaming things can look very different, especially non-realtime as you can divide the tasks very differently and build your result.
Note: While I am a programmer I don't do graphics so have almost certainly made a bit of a mess of this description, please feel free to correct/enhance it if you are an expert in the area!
