fbo causes software fallback?

Member
Posts: 45
Joined: 2008.04
Post: #1
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 Mad

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).
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Howdy stranger Wink

Rendering to 16- and 32-bit floating point textures is better supported than rendering to 16-bit integer textures. See http://homepage.mac.com/arekkusu/bugs/GLInfo.html for details on what hardware supports what.

Even rendering to floating-point textures, blending is not broadly supported yet. There's no explicit check for that except looking for the software fallback.

If you have control over hardware, pick a piece of hardware that does what you need. If you don't, you're probably going to have to improvise here.
Quote this message in a reply
Member
Posts: 45
Joined: 2008.04
Post: #3
Heh - greetings.

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..
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
Hmm, I've successfully used FP FBOs on Mac OS X.

Try http://files.onesadcookie.net/temp/ARB_d...st.tar.bz2 (and if it doesn't look like a cube and sphere somewhat toon-shaded orbiting each other, look in the code for some ways to view intermediate results).

Perhaps some minor nit-pick of how your FBOs are being set up is causing problems, or something.
Quote this message in a reply
Member
Posts: 45
Joined: 2008.04
Post: #5
Nice little toon demo. As you say, some minor (but annoying) nit-pick in our own FBO code, so I will start ripping things apart to isolate the problem.
Quote this message in a reply
Member
Posts: 45
Joined: 2008.04
Post: #6
Solved

Whilst 16bit blend is a known issue on some hardware, further documentation (http://ati.amd.com/developer/SDK/AMD_SDK..._Guide.pdf) reveals that blend, alpha_test, and fog are unsupported. In our case we had fog enabled (though our shaders weren't using it)...

It would seem Apples driver is being extra fussy...
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Gaussian blur, software fallback on GMA950 Fenris 11 7,257 Jul 28, 2007 05:00 PM
Last Post: OneSadCookie