System Environment: -------------------------- Arch: 86_64 Platform: Ivybridge Libdrm: (master)libdrm-2.4.43-5-gb7bb9e929786eb8bae86cf50f54dcb94bfa7ad46 Mesa: (master)04ffce3004faa50f33a740ea36aa4abdc03f652f Xserver:(master)xorg-server-1.14.0-52-gecf62755086fd65898998d5a509aee5f29a9583d Xf86_video_intel:(master)2.21.6-1-g86efddd9e4b921fcfc1a4b7492ba9174b84de64c Cairo: (master)a64ce09715162c57d6e4b6a460d426af1d443cdc Libva: (staging)5ec25c3d563d9ebd479a5ff978afe0a32f9cc00b Libva_intel_driver:(staging)1fd62ffd336293dce7d091bcea8399a40ccea21e Kernel: (drm-intel-nightly) a15a0027e2fd5f5e80c86142137108c173f14b34 Bug detailed description: ------------------------- It fails on sandybridge, ivybridge and haswell with mesa master branch. It doesn't happen on 9.1 branch. Bisect shows:55ecc448b9d05e9f1e5ceb88ab35606e80e3adee is the first bad commit. commit 55ecc448b9d05e9f1e5ceb88ab35606e80e3adee Author: Kenneth Graunke <kenneth@whitecape.org> AuthorDate: Mon Apr 8 19:27:38 2013 -0700 Commit: Kenneth Graunke <kenneth@whitecape.org> CommitDate: Mon Apr 8 16:15:07 2013 -0700 i965: Prefer Y-tiling on Gen6+. In the past, we preferred X-tiling for color buffers because our BLT code couldn't handle Y-tiling. However, the BLT paths have been largely replaced by BLORP on Gen6+, which can handle any kind of tiling. We hadn't measured any performance improvement in the past, but that's probably because compressed textures were all untiled anyway. Improves performance in GLB27_TRex_C24Z16_FixedTime by 7.69231%. v2: Rebase on top of Eric's untiled-for-larger-than-aperture changes. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Eric Anholt <eric@anholt.net> output: Failed to blit Failed to blit Failed to blit Failed to blit Failed to blit Failed to blit Probe at (32,32) Expected: 0.250000 0.250000 0.250000 Observed: 0.000000 0.000000 0.000000 Probe at (96,32) Expected: 0.750000 0.750000 0.750000 Observed: 0.000000 0.000000 0.000000 Probe at (32,96) Expected: 0.250000 0.250000 0.250000 Observed: 0.000000 0.000000 0.000000 Probe at (96,96) Expected: 0.750000 0.750000 0.750000 Observed: 0.000000 0.000000 0.000000 tex3d-maxsize: failed at size 256 x 256 x 256 PIGLIT: {'result': 'fail' } Reproduce steps: ---------------- 1. xinit 2. ./bin/tex3d-maxsize -auto
Webglc case conformance/renderbuffers/renderbuffer-initialization.html fail, and has same bisect commit.
Sorry for the regression. I have patches to fix it...I'll send them out tomorrow.
Fixed by the following commit (and the two just before it): commit cbe24ff7c8d69a6d378d9c2cce2bc117517f4302 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Wed Apr 10 13:49:16 2013 -0700 intel: Fall back to X-tiling when larger than estimated aperture size. If a region is larger than the estimated aperture size, we map/unmap it by copying with the BLT engine. Which means we can't use Y-tiling. Fixes Piglit max-texture-size and tex3d-maxsize, which regressed in my recent change to use Y-tiling by default on Gen6+. This was due to a botched merge conflict resolution. v2: Return a mask of valid tilings from intel_miptree_select_tiling. This allows us to avoid the X-tiling fallback if Y-tiling is actually mandatory. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
Webglc case conformance/textures/texture-size-limit.html also fail by same commit.
I went to https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html in Firefox using the sha I posted (cbe24ff7c8d6) and it passes on Ivybridge.
spec/OpenGL_1.2/tex3d-maxsize and conformance/textures/texture-size-limit.html fixed. conformance/renderbuffers/renderbuffer-initialization.html still fails on Ivybridge. Verify renderbuffers are initialized to 0 before being read in WebGL On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". PASS internal buffers have been initialized to 0 PASS getError was expected value: NO_ERROR : should be no error after renderbufferStorage(internalformat = RGBA4). PASS user buffers have been initialized to 0 PASS internal buffers have been initialized to 0 PASS getError was expected value: NO_ERROR : should be no error after renderbufferStorage(internalformat = RGBA4). FAIL user buffers have been initialized to 0 at (0, 0) expected: 0,0,0,0 was 1,255,254,0 PASS internal buffers have been initialized to 0 PASS getError was expected value: NO_ERROR : should be no error after renderbufferStorage(internalformat = RGBA4). PASS user buffers have been initialized to 0 PASS internal buffers have been initialized to 0 PASS getError was expected value: NO_ERROR : should be no error after renderbufferStorage(internalformat = RGBA4). FAIL user buffers have been initialized to 0 at (0, 0) expected: 0,0,0,0 was 1,255,254,0 PASS clearColor is [0, 1, 0, 1] PASS getError was expected value: NO_ERROR : should be no errors PASS successfullyParsed is true TEST COMPLETE
I can't reproduce that. I went to the following page in Firefox 20 on Ivybridge: https://www.khronos.org/registry/webgl/sdk/tests/conformance/renderbuffers/renderbuffer-initialization.html It passes both with Mesa built from cbe24ff7c8d69a6d (the "fix" commit) and 55ecc448b9d05e9f (the supposed bisect, which you said failed). I don't think it's related.
We run it on chrome 16.0.912.63. https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/renderbuffers/renderbuffer-initialization.html
(In reply to comment #7) > I can't reproduce that. > > I went to the following page in Firefox 20 on Ivybridge: > https://www.khronos.org/registry/webgl/sdk/tests/conformance/renderbuffers/ > renderbuffer-initialization.html > > It passes both with Mesa built from cbe24ff7c8d69a6d (the "fix" commit) and > 55ecc448b9d05e9f (the supposed bisect, which you said failed). > > I don't think it's related. I run it with Firefox 20, It also pass.
Ken, could you try chrome?
It works fine on my system with Chrome 26.0.1410.63. Why on earth are you using Chrome 16.0.912.63? That was released in December 2011. Nobody's going to run that, archaic browsers are just asking for security problems...
Following cases still fail on sandybridge with mesa master branch, bisect shows:55ecc448b9d05e9f1e5ceb88ab35606e80e3adee is the first bad commit: spec_ARB_texture_float_fbo-alphatest-formats spec_ARB_texture_float_fbo-blending-formats spec_ARB_texture_float_fbo-clear-formats spec_ARB_texture_float_fbo-colormask-formats spec_ARB_texture_float_fbo-generatemipmap-formats spec_EXT_framebuffer_object_getteximage-formats_init-by-rendering spec_glsl-1.30_execution_isinf-and-isnan_fs_fbo spec_glsl-1.30_execution_isinf-and-isnan_vs_fbo spec_OpenGL_1.1_getteximage-formats spec_OpenGL_3.0_clearbuffer-mixed-format
(In reply to comment #12) > Following cases still fail on sandybridge with mesa master branch, bisect > shows:55ecc448b9d05e9f1e5ceb88ab35606e80e3adee is the first bad commit: > > spec_ARB_texture_float_fbo-alphatest-formats > spec_ARB_texture_float_fbo-blending-formats > spec_ARB_texture_float_fbo-clear-formats > spec_ARB_texture_float_fbo-colormask-formats > spec_ARB_texture_float_fbo-generatemipmap-formats > spec_EXT_framebuffer_object_getteximage-formats_init-by-rendering > spec_glsl-1.30_execution_isinf-and-isnan_fs_fbo > spec_glsl-1.30_execution_isinf-and-isnan_vs_fbo > spec_OpenGL_1.1_getteximage-formats > spec_OpenGL_3.0_clearbuffer-mixed-format These cases only fail on sandybridge, So file #Bug 63867. I will test conformance/renderbuffers/renderbuffer-initialization.html on latest chrome, If fixed, I will close this bug.
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.