[Bug 106601] angle_end2end_test Texture2DTest.CopySubImageFloat_RGB_RGB/ES2_OPENGL fails

[Bug 106601] angle_end2end_test Texture2DTest.CopySubImageFloat_RGB_RGB/ES2_OPENGL fails

[bugzilla-daemon]

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

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

            Bug ID: 106601
           Summary: angle_end2end_test
                    Texture2DTest.CopySubImageFloat_RGB_RGB/ES2_OPENGL
                    fails
           Product: Mesa
           Version: 17.1
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i915
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: jingbin.wang@intel.com
        QA Contact: dri-devel@lists.freedesktop.org

Created attachment 139671
  --> https://bugs.freedesktop.org/attachment.cgi?id=139671&action=edit
Test application used to reproduce bug

1.

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

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

[Bug 106601] angle_end2end_test Texture2DTest.CopySubImageFloat_RGB_RGB/ES2_OPENGL fails

[bugzilla-daemon]

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

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

--- Comment #1 from wangjingbin <jingbin.wang@intel.com> ---
Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics
(KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11
-lepoxy";
3. run "./copySubImageFloatRGB", will print message as follow:
        Visual 0xb9 selected
        Render: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
        Version: 3.0 Mesa 17.1.4

       233 glCheckFramebufferStatus error no = 0x80.

The error is result from that the FBO is not completeness when the internal
format of attached image is RGB32F. In another word, The internal format RGB32F
is not color-renderable. 
According to GL 3.0 Spec description, Section 4.4 page 291 and Table 3.16 Page
184, The internal format RGB32F is color-renderable

In additional, I have run this test application on Nvidia graphic, it work
successfully

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

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

[Bug 106601] angle_end2end_test Texture2DTest.CopySubImageFloat_RGB_RGB/ES2_OPENGL fails

[bugzilla-daemon]

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

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

--- Comment #2 from wangjingbin <jingbin.wang@intel.com> ---
Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics
(KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11
-lepoxy";
3. run "./copySubImageFloatRGB", will print message as follow:
        Visual 0xb9 selected
        Render: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
        Version: 3.0 Mesa 17.1.4

       233 glCheckFramebufferStatus error no = 0x80cdd. 
The error is result from that the FBO is not completeness when the internal
format of attached image is RGB32F. In another word, The internal format RGB32F
is not color-renderable. 
According to GL 3.0 Spec description, Section 4.4 page 291 and Table 3.16 Page
184, The internal format RGB32F is color-renderable

In additional, I have run this test application on Nvidia graphic, it work
successfull

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

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

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

[bugzilla-daemon]

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

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

wangjingbin <jingbin.wang@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|angle_end2end_test          |The internal format RGB32F
                   |Texture2DTest.CopySubImageF |is not color-renderable,
                   |loat_RGB_RGB/ES2_OPENGL     |this is not in accordance
                   |fails                       |with Opengl 3.0 spec

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

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

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

[bugzilla-daemon]

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

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

wangjingbin <jingbin.wang@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|The internal format RGB32F  |The internal format RGB32F
                   |is not color-renderable,    |is not color-renderable,
                   |this is not in accordance   |This is not in accordance
                   |with Opengl 3.0 spec        |with Opengl 3.0 spec

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

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

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

[bugzilla-daemon]

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

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

--- Comment #3 from wangjingbin <jingbin.wang@intel.com> ---
Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics
(KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11
-lepoxy";
3. run "./copySubImageFloatRGB", will print message as follow:
        Visual 0xb9 selected
        Render: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
        Version: 3.0 Mesa 17.1.4

       233 glCheckFramebufferStatus error no = 0x8cdd.

The error is result from that the FBO is not completeness when the internal
format of attached image is RGB32F. In another word, The internal format RGB32F
is not color-renderable. 
According to GL 3.0 Spec description, Section 4.4 page 291 and Table 3.16 Page
184, The internal format RGB32F is color-renderable

In additional, I have run this test application on Nvidia graphic, it work
successfully

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

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

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

[bugzilla-daemon]

[-- 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

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

[bugzilla-daemon]

[-- 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

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

[bugzilla-daemon]

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

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

--- Comment #6 from wangjingbin <jingbin.wang@intel.com> ---
Looking OpenGL 3.0 spec, Section 4.4 Page 291,

The following base internal formats from table 3.15 are color-renderable:
ALPHA, RED, RG, RGB, and RGBA. The sized internal formats from table 3.16 that
have a color-renderable base internal format are also color-renderable. No
other formats, including compressed internal formats, are
color-renderable.

you can find it in table 3.15

Base Internal Format    RGBA, Depth, and Stencil Values     Internal Components
------------------------------------------------------------------------------- 
     RGB                    R,G,B                              R,G,B
It suggest that the  RGB format is color-renderable.

you can find it in table 3.16

Sized Internal Format    Base Internal Format   R bits    G bits   B bits   A
bits 
shared bits
------------------------------------------------------------------------------- 
RGB32F                   RGB                    f32       f32     f32

According to description, as Sized Internal Format the Base Internal format of
RGB32F is RGB,  RGB format is color-renderable according to description of
table 3.15, So RGB32F should be color-renderable

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

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

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

[bugzilla-daemon]

[-- 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

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

[bugzilla-daemon]

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

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

--- Comment #8 from Tapani Pälli <lemody@gmail.com> ---
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 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 this from
column 'Req. rend" as said in 9.2.5.

That said, IMO this bug should be considered a feature request (which is fine)
rather than a missing feature.

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

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

[Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it

[bugzilla-daemon]

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

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

wangjingbin <jingbin.wang@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|The internal format RGB32F  |The internal format RGB32F
                   |is not color-renderable,    |should be color-renderable
                   |This is not in accordance   |for texture, But mesa can
                   |with Opengl 3.0 spec        |not support it

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

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

[Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it

[bugzilla-daemon]

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

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

--- Comment #9 from Ilia Mirkin <imirkin@alum.mit.edu> ---
"Color-renderable" means "is it legal to use this format". It does NOT mean
"the driver allows rendering to this format".

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

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

[Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it

[bugzilla-daemon]

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

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

--- Comment #10 from Yunchao He <yunchao.he@intel.com> ---
(In reply to Tapani Pälli 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 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 this
> from column 'Req. rend" as said in 9.2.5.
> 
> That said, IMO this bug should be considered a feature request (which is
> fine) rather than a missing feature.

Sorry. Maybe the description is not clear. The issue we raised is to render
into a RGB32F format texture, not RGB32F format renderbuffer. 

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 feature in mesa for
Intel devices.

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

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

[Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it

[bugzilla-daemon]

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

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

--- Comment #11 from Tapani Pälli <lemody@gmail.com> ---
(In reply to Yunchao He from comment #10)
> (In reply to Tapani Pälli 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 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 this
> > from column 'Req. rend" as said in 9.2.5.
> > 
> > That said, IMO this bug should be considered a feature request (which is
> > fine) rather than a missing feature.
> 
> Sorry. Maybe the description is not clear. The issue we raised is to render
> into a RGB32F format texture, not RGB32F format renderbuffer. 
> 
> 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 feature
> in mesa for Intel devices.

'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 rendering to
such format should work, for that there is column 'Req. rend.'.

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

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

[Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it

[bugzilla-daemon]

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

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

--- Comment #12 from Yunchao He <yunchao.he@intel.com> ---
(In reply to Ilia Mirkin from comment #9)
> "Color-renderable" means "is it legal to use this format". It does NOT mean
> "the driver allows rendering to this format".

I am not a driver expert. But my understanding is that color-renderable means
that we can render into this format as a color buffer. If color-renderable
means "is it legal to use this format", then I can't explain these two
questions as follows: 
1. why we need to list that format which is illegal to use at all in spec? I
suppose there are many formats for graphics/video. Enumerating formats that are
not useful for texture (or renderbuffer) seems to be weird. 
2. If color-renderable(or renderable) means that "is it legal to use this
format" for a texture. Then that format is not allow to sample from. If so, how
to distinguish these two kinds of formats: 1) some formats can be supported by
a texture to sample only,  they can't be used to render into as a render target
via fbo, 2) some other formats can be supported by a texture to sample, and
render into as well.

The statement that "Color-renderable means is it legal to use this format. It
does NOT mean the driver allows rendering to this format" is correct for a
renderbuffer, but I think it is incorrect for a texture. Because a renderbuffer
is only used to render into, they can't be used to sample from. But this issue
is talking about texture, NOT renderbuffer. Maybe for the underlying
implementation, both texture and renderbuffer are mapped into the same GPU
memory (or even CPU memory), but from the perspective of users, texture and
renderbuffer are quite different.

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

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

[Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it

[bugzilla-daemon]

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

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

--- Comment #13 from Yunchao He <yunchao.he@intel.com> ---
(In reply to Tapani Pälli from comment #11)
> (In reply to Yunchao He from comment #10)
> > (In reply to Tapani Pälli 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 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 this
> > > from column 'Req. rend" as said in 9.2.5.
> > > 
> > > That said, IMO this bug should be considered a feature request (which is
> > > fine) rather than a missing feature.
> > 
> > Sorry. Maybe the description is not clear. The issue we raised is to render
> > into a RGB32F format texture, not RGB32F format renderbuffer. 
> > 
> > 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 feature
> > in mesa for Intel devices.
> 
> '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 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 texture
as a render target. And section 9.4 also states that it is valid to render into
such a texture (RGB32F). 

While "Req. rend" column means whether a format is required by a renderbuffer. 

So, according to Table 8.12, RGB32F should be used as a color buffer via fbo 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.

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

[Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it

[bugzilla-daemon]

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

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

--- Comment #14 from Tapani Pälli <lemody@gmail.com> ---
Is this originally a WebGL test? If so, can you paste the link here please?

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

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

[Bug 106601] The internal format RGB32F should be color-renderable for texture, But mesa can not support it

[bugzilla-daemon]

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

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

GitLab Migration User <gitlab-migration@fdo.invalid> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #15 from GitLab Migration User <gitlab-migration@fdo.invalid> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/785.

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

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

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

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