If I had an existing PBuffer code path than knew not to do special blending etc. when working with a floating point PBuffer (by testing GL_RGBA_FLOAT_MODE_ARB), now will this same sort of test work with floating point FBO’s?
I know I could just try and see, but I see nothing in the FBO spec about GL_RGBA_FLOAT_MODE_ARB (or any other way easy way to tell if I am rendering to a floating point surface).
I don’t understand what you mean. What’s in fact a floating point FBO ?
I’d like to say that it all depends on the renderbuffer and such you attached to your FBO.
Framebuffer objects are a little different, and some global queries won’t work well even with EXT_framebuffer_blit, where you now have separate READ and DRAW framebuffer attachment points. When you query something like RGBA_FLOAT_MODE, are you asking about the READ or the DRAW framebuffer? And future versions may allow mixed formats withing a single FBO, e.g. you can have one color target RGBA8 and another RGBA_FLOAT16.
The new, improved mechanism for determining such information when using a FBO is to query the properties of the attachment itself. GetFramebufferAttachmentParameterivEXT can remind you which texture or renderbuffer is attached, and then you can query properties of the attachment directly with GetTexParameteriv or GetRenderbufferParameterivEXT, as appropriate.
This is the cost of greater flexibility.