From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 106601] The internal format RGB32F is not color-renderable, This is not in accordance with Opengl 3.0 spec
Date: Tue, 22 May 2018 06:36:55 +0000 [thread overview]
Message-ID: <bug-106601-502-MHMmHnuuRu@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-106601-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 2051 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=106601
--- Comment #4 from wangjingbin <jingbin.wang@intel.com> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2947 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
next prev parent reply other threads:[~2018-05-22 6:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 5:39 [Bug 106601] angle_end2end_test Texture2DTest.CopySubImageFloat_RGB_RGB/ES2_OPENGL fails bugzilla-daemon
2018-05-22 6:09 ` bugzilla-daemon
2018-05-22 6:12 ` bugzilla-daemon
2018-05-22 6:16 ` [Bug 106601] The internal format RGB32F is not color-renderable, this is not in accordance with Opengl 3.0 spec bugzilla-daemon
2018-05-22 6:16 ` [Bug 106601] The internal format RGB32F is not color-renderable, This " bugzilla-daemon
2018-05-22 6:22 ` bugzilla-daemon
2018-05-22 6:36 ` bugzilla-daemon [this message]
2018-05-22 13:23 ` bugzilla-daemon
2018-05-23 5:01 ` bugzilla-daemon
2018-05-23 6:09 ` bugzilla-daemon
2018-05-23 15:52 ` bugzilla-daemon
2018-05-24 1:46 ` [Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it bugzilla-daemon
2018-05-24 2:37 ` bugzilla-daemon
2018-05-24 5:43 ` bugzilla-daemon
2018-05-24 5:53 ` bugzilla-daemon
2018-05-24 6:08 ` bugzilla-daemon
2018-05-24 6:24 ` bugzilla-daemon
2018-10-12 7:12 ` bugzilla-daemon
2019-09-18 19:41 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-106601-502-MHMmHnuuRu@http.bugs.freedesktop.org/ \
--to=bugzilla-daemon@freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).