is float-point framebuffer possible with opengl?

Certainly. How else are you supposed to do things like HDR? (Luminance is stored in a single-channel fp buffer)

You will perform all of your rendering operations into an FBO. http://www.songho.ca/opengl/gl_fbo.html
If you are going to pass this frame buffer image onto another shader to do post-process effects (which it sounds like you want to do), you need to render into a texture object. I think the only thing you need to do different than how they do it in the tutorial above is request floating-point texture storage rather than 8-bit normalized.
Like so:

All sorts of available internal formats. More than just these 2. Pretty much every permutation of number of channels and widths are available (at least under the current opengl core specification) with a few exceptions.

You cannot bind texture buffers (or renderbuffers for that matter) of internal format GL_RGB32F, GL_RGB16F to an FBO.

GL_RGBA32F, GL_RGBA16F, GL_R11F_G11F_B10F, GL_RG32F, GL_RG32F, GL_RG16F, GL_R32F, and GL_R16F are all the floating-point texture formats supported by FBO attachments.

Quote:

Original post by Cathbadh You cannot bind texture buffers (or renderbuffers for that matter) of internal format GL_RGB32F, GL_RGB16F to an FBO.

Of course you can.

Quote:

Original post by Yann L Quote: Original post by Cathbadh You cannot bind texture buffers (or renderbuffers for that matter) of internal format GL_RGB32F, GL_RGB16F to an FBO. Of course you can.

Not according to the OpenGL 3.2 core spec? Implementations I suppose could support it, but they aren't required to. Most 3-channel formats, and signed normalized formats (as well as any compressed texture format) can only be used for texture object storage, but cannot be rendered into.

Quote:

Original post by Cathbadh Not according to the OpenGL 3.2 core spec? Implementations I suppose could support it, but they aren't required to. Most 3-channel formats, and signed normalized formats (as well as any compressed texture format) can only be used for texture object storage, but cannot be rendered into.

Even where you can, it tends to be as slow as hell, and GPU-to-GPU copies of 3 component formats often seem to trigger readback to main memory. In short, i would avoid 3 component formats where possible.

Quote:

Original post by Cathbadh Not according to the OpenGL 3.2 core spec?

Actually the standard contradicts itself on this issue. Section 3.8.1 does not list the formats as required under "Texture and renderbuffer color formats". However, section 4.4.4 specifically mentions that these formats are indeed colour-renderable. This section is also present in GL2.x ARB_framebuffer_object.

It's not about the base format. R11G11B10 is also RGB, yet it is specifically required to be renderable. It's about alignment.

In practice, both ATI and NV handle RGB16F just fine as a render target. From a quick test, I could not notice any speed difference to RGBA16F. It is possible that these implementations just silently pad to RGBA though.

So it is indeed possible. But if you want to be extra-sure to be compliant, you should probably avoid the formats.