https://bugs.freedesktop.org/show_bug.cgi?id=106601
--- Comment #13 from Yunchao He yunchao.he@intel.com --- (In reply to Tapani Pälli from comment #11)
(In reply to Yunchao He from comment #10)
(In reply to Tapani Pälli from comment #8)
What comes to conformance, you should refer to latest OpenGL spec (now being 4.6). In this case you want to render to RGB32F we should take a look at section "9.2.5 Required Renderbuffer Formats". Since you are using a sized format, it means you need to check if driver is required to support this from column 'Req. rend" as said in 9.2.5.
That said, IMO this bug should be considered a feature request (which is fine) rather than a missing feature.
Sorry. Maybe the description is not clear. The issue we raised is to render into a RGB32F format texture, not RGB32F format renderbuffer.
For the latest OpenGL 4.6 spec, RGB32F internalformat is required by texture, see Table 8.12 in GL 4.6 spec. So I think it is a missing feature in mesa for Intel devices.
'Req. tex.' column in that table means that texture mapping with this format should work (sample from in a shader), it does *not* mean that rendering to such format should work, for that there is column 'Req. rend.'.
Sorry, I didn't state this clearly. "Req. tex' column in Table 8.12 do means that texture mapping with this format should work (sample from in a shader), but whether we can render into such a format depends on "CR" column. CR is an abbreviation of color-renderable, I think. And corresponding section about "CR" at 9.4 "Framebuffer Completeness" do talk about rendering into such a texture as a render target. And section 9.4 also states that it is valid to render into such a texture (RGB32F).
While "Req. rend" column means whether a format is required by a renderbuffer.
So, according to Table 8.12, RGB32F should be used as a color buffer via fbo in latest GL 4.6 spec. When we attach a texture with RGB32F internal format to fbo as color attachment, generating "framebuffer incomplete" in mesa for Intel devices is incorrect.