fbo causes software fallback?

We're using FBOs and it works well, however in several cases we need the higher resolution of GL_RGB16 or better. We verified that these work on our hardware/OS (G5 10.5.2) via a modified version of Apples PBORenderToVertexArray sample code, but back in our software it appears (i.e. visually) to fail to set up the FBO successfully...

glCheckFramebufferStatusEXT() is reporting success, though weirdly OpenGLProfiler.App is reporting that at this point it is causing a software fallback, which has us puzzled

We have modified our FBO setup code so it identical to the above Apple sample code - but the behaviour persists. We can only assume that some other OpenGL state is inteferring. Has anyone experience with similar weirdness?

Note: the code base runs fine on windows/linux, only the mac is causing problems (and also seeing the problem on intel mac).

Using floating point textures seems to makes no difference (current test hardware is G5 + x800).

As for blending, we have blending disabled. The textures are instead being used within old style ARBvp1.0/ARBfp1.0 shaders (we even tested a GLSL workaround to no advantage).

The texture themselves currently appear to be filled with garbage, and are not being updated (not even by the glClear(..)). After creation of this FBO the overall rendering tends to break down, i.e. the window fails to flush (but only if fsaa is turned off).

PS - the code (http://sauerbraten.org/) runs happily on linux & windows, this will be the first time in 2 years that we may be unable to offer full functionality in the mac release... the projects opengl guru is at a loss too..