dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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 13:23:06 +0000	[thread overview]
Message-ID: <bug-106601-502-TsgifKCb3a@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-106601-502@http.bugs.freedesktop.org/>


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

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

--- Comment #5 from Ilia Mirkin <imirkin@alum.mit.edu> ---
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.

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

[-- Attachment #1.2: Type: text/html, Size: 3084 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

  parent reply	other threads:[~2018-05-22 13:23 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
2018-05-22 13:23 ` bugzilla-daemon [this message]
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-TsgifKCb3a@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).