[Bug 106601] The internal format RGB32F is not color-renderable, This is not in accordance with Opengl 3.0 spec

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 3107 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=106601

--- Comment #7 from Yunchao He <yunchao.he@intel.com> ---
#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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4027 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel