| Summary: | [SNB/IVB/HSW Bisected]Piglit spec/OpenGL_1.2/tex3d-maxsize fail | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | lu hua <huax.lu> |
| Component: | Drivers/DRI/i965 | Assignee: | Kenneth Graunke <kenneth> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | idr, xunx.fang |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
lu hua
2013-04-10 02:39:43 UTC
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.