From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 106601] The internal format RGB32F should be color-renderable
for texture, But mesa can not support it
Date: Thu, 24 May 2018 06:24:04 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1252947323=="
Return-path:
Received: from culpepper.freedesktop.org (culpepper.freedesktop.org
[131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id A6D98898BE
for ; Thu, 24 May 2018 06:24:04 +0000 (UTC)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel"
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============1252947323==
Content-Type: multipart/alternative; boundary="15271430441.2fe6Ff5.29966"
Content-Transfer-Encoding: 7bit
--15271430441.2fe6Ff5.29966
Date: Thu, 24 May 2018 06:24:04 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated
https://bugs.freedesktop.org/show_bug.cgi?id=3D106601
--- Comment #13 from Yunchao He ---
(In reply to Tapani P=C3=A4lli from comment #11)
> (In reply to Yunchao He from comment #10)
> > (In reply to Tapani P=C3=A4lli from comment #8)
> > > What comes to conformance, you should refer to latest OpenGL spec (no=
w 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 t=
his
> > > from column 'Req. rend" as said in 9.2.5.
> > >=20
> > > That said, IMO this bug should be considered a feature request (which=
is
> > > fine) rather than a missing feature.
> >=20
> > Sorry. Maybe the description is not clear. The issue we raised is to re=
nder
> > into a RGB32F format texture, not RGB32F format renderbuffer.=20
> >=20
> > 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 feat=
ure
> > in mesa for Intel devices.
>=20
> 'Req. tex.' column in that table means that texture mapping with this for=
mat
> 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 textu=
re
as a render target. And section 9.4 also states that it is valid to render =
into
such a texture (RGB32F).=20
While "Req. rend" column means whether a format is required by a renderbuff=
er.=20
So, according to Table 8.12, RGB32F should be used as a color buffer via fb=
o 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.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
--15271430441.2fe6Ff5.29966
Date: Thu, 24 May 2018 06:24:04 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated
Comme=
nt # 13
on bug 10660=
1
from Yunchao He
(In reply to Tapani P=C3=A4lli from comment #11)
> (In reply to Yunchao He from comment #10)
> > (In reply to Tapani P=C3=A4lli 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 ta=
ke a look at
> > > section "9.2.5 Required Renderbuffer Formats". Si=
nce 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.
> > >=20
> > > That said, IMO this bug should be considered a feature reque=
st (which is
> > > fine) rather than a missing feature.
> >=20
> > Sorry. Maybe the description is not clear. The issue we raised is=
to render
> > into a RGB32F format texture, not RGB32F format renderbuffer.=20
> >=20
> > 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 missin=
g feature
> > in mesa for Intel devices.
>=20
> '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 render=
ing 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" colu=
mn. CR is an
abbreviation of color-renderable, I think. And corresponding section about =
"CR"
at 9.4 "Framebuffer Completeness" do talk about rendering into su=
ch a texture
as a render target. And section 9.4 also states that it is valid to render =
into
such a texture (RGB32F).=20
While "Req. rend" column means whether a format is required by a =
renderbuffer.=20
So, according to Table 8.12, RGB32F should be used as a color buffer via fb=
o 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.
You are receiving this mail because:
- You are the assignee for the bug.
=
--15271430441.2fe6Ff5.29966--
--===============1252947323==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==
--===============1252947323==--