https://bugs.freedesktop.org/show_bug.cgi?id=106601
--- Comment #5 from Ilia Mirkin imirkin@alum.mit.edu --- Note that in the core OpenGL 4.6 specification, table 8.12, GL_RGB32F is marked as color-renderable, but not required to be renderable.
Looking at the OpenGL 3.0 spec, page 180, RGB32F is listed in the "texture-only" formats. Table 3.18 has nothing to do with these from what I can tell, but table 3.16 merely lists out the formats and their info, not whether they must be possible to render to.
A few more quotes:
""" Required Renderbuffer Formats
Implementations are required to support the same internal formats for renderbuffers as the required formats for textures enumerated in section 3.9.1, with the exception of the color formats labelled “texture-only” """
""" Required Framebuffer Formats
Implementations must support framebuffer objects with up to MAX COLOR ATTACHMENTS color attachments, a depth attachment, and a stencil attachment. Each color attachment may be in any of the required color formats for textures and renderbuffers described in sections 3.9.1 and 4.4.2. """
I'll admit that the latter is slightly vague, whether texture-only formats need to be supported. However looking at some of the other texture-only formats, like RGB9_E5 or COMPRESSED RG RGTC2 -- I think it's pretty clear that those aren't meant to be required to be renderable to.
However in practice, FYI, no hardware actually supports rendering to RGB32F (irrespective of what the driver might let you do). On the bright side, (almost) no hardware supports RGB32F for texturing either (except TBO's) -- creating a RGB32F texture will allocate a RGBA32F texture deep down inside. So chances are, the NVIDIA driver sees that the true internal format is RGBA32F and lets you render to it, even though the API internal format is RGB32F.
I don't see anything in the spec which requires this type of logic on the driver's behalf though. What the NVIDIA driver does is fully legal, but hardly required.