System Environment: -------------------------- Platform: i965 Libdrm: (master)libdrm-2.4.58-19-gf99522e678dbbaffeca9462a8edcbe900574dc12 Mesa: (master)8812dc503eb48bac5b9c9b5740f76025c046f90d Xserver: (master)xorg-server-1.16.99.901-84-gc1455f76c6b1aa4ecaacb2221a687244285aa44b Xf86_video_intel:(master)2.99.916-172-g04a09d353fc5ad8a55eb2457dc8bb43638ba879e Libva: (master)cdfd3d50d80c092ca3ae8914418be628d5a80832 Libva_intel_driver:(master)f2a34f94c57e1f7ce975b2068fb087df84b92e3a Kernel: (drm-intel-nightly)34d267c2ba9c0845432baf959a2c4deed87f3ee4 Bug detailed description: --------------------------- It fails on i965 platforms with mesa master branch, works well on 10.4 branch. ES3-CTS.gtf.GL3Tests.color_buffer_float.color_buffer_unsupported_format also fails on SNB+ platforms with same bisect commit. Bisect shows 78942787170615c9333810cf3a4819a13c9eb8e8 is the first bad commit commit 78942787170615c9333810cf3a4819a13c9eb8e8 Author: Eduardo Lima Mitev <elima@igalia.com> AuthorDate: Thu Nov 20 14:02:46 2014 +0100 Commit: Iago Toral Quiroga <itoral@igalia.com> CommitDate: Tue Dec 9 11:40:00 2014 +0100 mesa: Enables GL_RGB and GL_RGBA unsized internal formats for OpenGL ES 3.0 GL_RGB and GL_RGBA are valid internal formats on a GLES3 profile. See "Table 1. Unsized Internal Formats" at https://www.khronos.org/opengles/sdk/docs/man3/html/glTexImage2D.xhtml. Fixes 2 dEQP tests: - dEQP-GLES3.functional.state_query.internal_format.rgb_samples - dEQP-GLES3.functional.state_query.internal_format.rgba_samples Reviewed-by: Brian Paul <brianp@vmware.com> output: dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES2-CTS.gtf.GLCoverage.CoverageGL'.. #+ Invalid enums accepted: GL_RGB #+ Invalid enums accepted: GL_RGBA #+ glRenderbufferStorage : failed. See above errors #+ One or more tests failed. Fail (Fail) DONE! Test run totals: Passed: 0/1 (0.00%) Failed: 1/1 (100.00%) Not supported: 0/1 (0.00%) Warnings: 0/1 (0.00%) Reproduce steps: ------------------------- 1. xinit 2. ./glcts --deqp-case=ES2-CTS.gtf.GLCoverage.CoverageGL
The offending patch explicitly checks for a GLES3 context. If the failing test is a GLES2 as it seems, then it is not clear why is picking the invalid enums. Can we confirm the test is actually running a GLES2 profile? I will take a closer look.
(In reply to Eduardo Lima Mitev from comment #1) > The offending patch explicitly checks for a GLES3 context. If the failing > test is a GLES2 as it seems, then it is not clear why is picking the invalid > enums. > > Can we confirm the test is actually running a GLES2 profile? > > I will take a closer look. ES3 contexts are supposed to be backwards compatible with ES2. On platforms that support ES3, Mesa (and other implementations?) always gives an ES3 context.
Also, from the looks of the command line, this is run from the ES3 conformance suite from Khronos. Lu, is that correct?
(In reply to Ian Romanick from comment #3) > Also, from the looks of the command line, this is run from the ES3 > conformance suite from Khronos. Lu, is that correct? Yes.
Ok, then I guess adding a ctx->Version >= 30 check is what's missing. Will submit updated patch to ML. Thanks for the insights.
Oops, please ignore my last comment. Just checked that _mesa_is_gles3() already checks version >= 30. So I need other way to identify specific versions of the GLES profile.
(In reply to Eduardo Lima Mitev from comment #6) > Oops, please ignore my last comment. Just checked that _mesa_is_gles3() > already checks version >= 30. So I need other way to identify specific > versions of the GLES profile. I think it must be something deeper than that. To me, it appears that the dEQP test is expecting different behavior than the Khronos GLES3 conformance test. I think the unsized internal formats are only allowed with certain format and type combinations. Perhaps 7894278 is just too lax?
(In reply to Ian Romanick from comment #7) > I think the unsized internal formats are only allowed with certain > format and type combinations. Perhaps 7894278 is just too lax? See bug 88079. I think it describes the same issue. The spec is not always clear where GL_RGB and GL_RGBA (or other unsized internal formats) are valid internal formats, but in some cases it is very clear where it is not, like in glRenderbufferStorageMultisample(): "internalformat must be a sized internal format that is color-renderable,depth-renderable, or stencil-renderable" I just submitted a patch for reviewal <http://lists.freedesktop.org/archives/mesa-dev/2015-January/074122.html>. Perhaps it also fixes ES3-CTS.gtf.GL3Tests.color_buffer_float.color_buffer_unsupported_format. Could you please confirm?
(In reply to Eduardo Lima Mitev from comment #8) > (In reply to Ian Romanick from comment #7) > > I think the unsized internal formats are only allowed with certain > > format and type combinations. Perhaps 7894278 is just too lax? > > See bug 88079. I think it describes the same issue. > The spec is not always clear where GL_RGB and GL_RGBA (or other unsized > internal formats) are valid internal formats, but in some cases it is very > clear where it is not, like in glRenderbufferStorageMultisample(): > > "internalformat must be a sized internal format that is > color-renderable,depth-renderable, or > stencil-renderable" > > I just submitted a patch for reviewal > <http://lists.freedesktop.org/archives/mesa-dev/2015-January/074122.html>. > Perhaps it also fixes > ES3-CTS.gtf.GL3Tests.color_buffer_float.color_buffer_unsupported_format. > > Could you please confirm? Test this patch, It works well.
passes with Mesa master (tested d74a817)
Verified.Fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.