fbo causes software fallback? - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Graphics & Audio Programming (/forum-9.html)
+--- Thread: fbo causes software fallback? (/thread-2688.html)
fbo causes software fallback? - aBabyRabbit - Apr 4, 2008 04:19 PM
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).
fbo causes software fallback? - OneSadCookie - Apr 4, 2008 04:50 PM
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.
fbo causes software fallback? - aBabyRabbit - Apr 4, 2008 06:12 PM
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..
fbo causes software fallback? - OneSadCookie - Apr 4, 2008 08:20 PM
Hmm, I've successfully used FP FBOs on Mac OS X.
Try http://files.onesadcookie.net/temp/ARB_draw_buffers_Test.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.
fbo causes software fallback? - aBabyRabbit - Apr 4, 2008 09:58 PM
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.
fbo causes software fallback? - aBabyRabbit - Apr 5, 2008 12:00 AM
Whilst 16bit blend is a known issue on some hardware, further documentation (http://ati.amd.com/developer/SDK/AMD_SDK_Samples_May2007/Documentations/ATI_OpenGL_Programming_and_Optimization_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...