Commen=
t # 4
on bug 10660=
1
from wangjingbin
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 sample=
d 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 whi=
ch
format supports texture sample, texture filter and renderable, etc.
A table in isl_format.c, named "format_info", specifies support f=
or
surface(texture, renderbuffer, vertex buffer) formats across the various
hardware generations. The table shows that GL_RGB32F format is not supporte=
d as
render target for all hardware generations.
It suggest that it depend on hardware's capacity.=20
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