Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics (KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11 -lepoxy";
3. run "./copySubImageFloatRGB", will print message as follow:
        Visual 0xb9 selected
        Render: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
        Version: 3.0 Mesa 17.1.4
        
       233 glCheckFramebufferStatus error no = 0x80.

The error is result from that the FBO is not completeness when the internal format of attached image is RGB32F. In another word, The internal format RGB32F is not color-renderable. 
According to GL 3.0 Spec description, Section 4.4 page 291 and Table 3.16 Page 184, The internal format RGB32F is color-renderable

In additional, I have run this test application on Nvidia graphic, it work successfully

Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics (KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11 -lepoxy";
3. run "./copySubImageFloatRGB", will print message as follow:
        Visual 0xb9 selected
        Render: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
        Version: 3.0 Mesa 17.1.4
        
       233 glCheckFramebufferStatus error no = 0x80cdd. 
The error is result from that the FBO is not completeness when the internal format of attached image is RGB32F. In another word, The internal format RGB32F is not color-renderable. 
According to GL 3.0 Spec description, Section 4.4 page 291 and Table 3.16 Page 184, The internal format RGB32F is color-renderable

In additional, I have run this test application on Nvidia graphic, it work successfull

Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics (KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11 -lepoxy";
3. run "./copySubImageFloatRGB", will print message as follow:
        Visual 0xb9 selected
        Render: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
        Version: 3.0 Mesa 17.1.4
        
       233 glCheckFramebufferStatus error no = 0x8cdd.

The error is result from that the FBO is not completeness when the internal format of attached image is RGB32F. In another word, The internal format RGB32F is not color-renderable. 
According to GL 3.0 Spec description, Section 4.4 page 291 and Table 3.16 Page 184, The internal format RGB32F is color-renderable

In additional, I have run this test application on Nvidia graphic, it work successfully

In OpenGL ES spec, GL_RGB32F is texture supported format, but is not color renderable format, it means that texture with this format could been sampled in shader. But it cannot be as an attachment for a framebuffer object, cannot be as a render target.
In OpenGL spec, GL_RGB32F is texture supported format, and is also color renderable format.

This case could run normally on Nvidia GPU, but not on Intel GPU. OpenGL context of Nvidia GPU could support GL_RGB32F format texture as a render target. OpenGL context of Intel GPU hardware does not support this format texture as a render target.

Trace mesa code to look for clue

[some related code in mesa]
_mesa_test_framebuffer_completeness function in fbobject.c, follows specs to check completeness of fbo on OpenGL context or OpenGL ES context, there is no error. But it is not enough, it also need to call the ctx->Driver.ValidateFramebuffer() function to ask the driver to make hardware-specific validation/completeness checks.
intel_validate_framebuffer function in intel_fbo.c, makes hardware-specific validation/completeness checks.
intel_screen_init_surface_formats in brw_surface_formats.c, initializes which format supports texture sample, texture filter and renderable, etc.
A table in isl_format.c, named "format_info", specifies support for surface(texture, renderbuffer, vertex buffer) formats across the various hardware generations. The table shows that GL_RGB32F format is not supported as render target for all hardware generations.

It suggest that it depend on hardware's capacity. 

In order to figure out it whether depends on hardware's capacity. I have run
ANGLE for Texture2DTest.CopySubImageFloat_RGBA_RGB, The follow of this test is same as attachment file. It run successfully on windows Opengl.

So  need mesa team to help investigate it

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.

Looking OpenGL 3.0 spec, Section 4.4 Page 291,

The following base internal formats from table 3.15 are color-renderable:
ALPHA, RED, RG, RGB, and RGBA. The sized internal formats from table 3.16 that have a color-renderable base internal format are also color-renderable. No other formats, including compressed internal formats, are
color-renderable.

you can find it in table 3.15

Base Internal Format    RGBA, Depth, and Stencil Values     Internal Components
-------------------------------------------------------------------------------    
     RGB                    R,G,B                              R,G,B
It suggest that the  RGB format is color-renderable.

you can find it in table 3.16

Sized Internal Format    Base Internal Format   R bits    G bits   B bits   A bits 
shared bits
-------------------------------------------------------------------------------    
RGB32F                   RGB                    f32       f32     f32

According to description, as Sized Internal Format the Base Internal format of RGB32F is RGB,  RGB format is color-renderable according to description of table 3.15, So RGB32F should be color-renderable

#5, In GL 3.0. RGB32F is color-renderable for texture-only. It is not color-renderable for renderbuffer. But we do use A TEXTURE with RGB32F as color-attachment and then check the framebuffer attachment, it says framebuffer incomplete on Intel mesa driver. It is OK for Intel Windows GL driver and Intel MacOS GL driver. It's also OK for NVIDIA and AMD (Windows, MacOS, Linux, etc).

For this statement to check framebuffer completeness below:

"""
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.
"""

My understanding is that the color formats for a color attachment should be color-renderable for a texture, or color-renderable for a renderbuffer. It is not required that the color format should be color-renderable both for a texture and a renderbuffer. If you attach a texture with a color-renderable format, that format is not color-renderable for a renderbuffer (like RGB32F), it doesn't matter. This is A TEXTURE, not a renderbuffer. There is no reason that we need to go through renderbuffer's color-renderable formats for a texture. In short, this statements says that color attachment should be attached an image which is color-renderable, no matter it is a texture or a renderbuffer. 

In addition, why you say "GL_RGB32F is marked as color-renderable, but not required to be renderable"? My understanding is that, a format is color-renderable (or depth-renderable, or stencil renderable), it must be renderable. But a color-renderable format for texture is not guaranteed to be color-renderable for renderbuffer. 

Let's discuss this issue from a different perspective. You know, for a texture, it has 2 main usage: 1) sample (or read) from a texture, 2) draw (or write) to a texture. If a format is color-renderable for a texture, but we can't attach it to a FB/FBO, I don't know how could we draw into this kind of texture. As a result, it makes no sense that we say it is color-renderable. So I think attaching a color-renderable format to a fbo should be valid. 

But for same other formats which is used only for sampling from a texture, it can be not renderable. That formats can't be attached to a fbo and used as a render target. 

However, RGB32F is claimed as color-renderable in OpenGL. So texture with this format can be rendered into without error. 

For a renderbuffer, It is mainly used to draw. We can't sample from a renderbuffer (although we can call readpixel to read AFTER you draw something). So all formats for a renderbuffer should be renderable (color-renderable, depth-renderable, etc).  

Please correct me if I am wrong. Any other comments are welcome too.

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.

"Color-renderable" means "is it legal to use this format". It does NOT mean "the driver allows rendering to this format".

(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.

(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.'.

(In reply to Ilia Mirkin from comment #9)
> "Color-renderable" means "is it legal to use this format". It does NOT mean
> "the driver allows rendering to this format".

I am not a driver expert. But my understanding is that color-renderable means that we can render into this format as a color buffer. If color-renderable means "is it legal to use this format", then I can't explain these two questions as follows: 
1. why we need to list that format which is illegal to use at all in spec? I suppose there are many formats for graphics/video. Enumerating formats that are not useful for texture (or renderbuffer) seems to be weird. 
2. If color-renderable(or renderable) means that "is it legal to use this format" for a texture. Then that format is not allow to sample from. If so, how to distinguish these two kinds of formats: 1) some formats can be supported by a texture to sample only,  they can't be used to render into as a render target via fbo, 2) some other formats can be supported by a texture to sample, and render into as well.

The statement that "Color-renderable means is it legal to use this format. It does NOT mean the driver allows rendering to this format" is correct for a renderbuffer, but I think it is incorrect for a texture. Because a renderbuffer is only used to render into, they can't be used to sample from. But this issue is talking about texture, NOT renderbuffer. Maybe for the underlying implementation, both texture and renderbuffer are mapped into the same GPU memory (or even CPU memory), but from the perspective of users, texture and renderbuffer are quite different.

(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.

Is this originally a WebGL test? If so, can you paste the link here please?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/785.