System Environment: -------------------------- Platform: Ironlake Libdrm: (master)libdrm-2.4.52-4-gc5de5abbd90333fe1359283fb3a5e457b0f389f3 Mesa: (master)57405605a8c320f9d6ea389afd43ce6f013330a5 Xserver: (master)xorg-server-1.15.0-627-gf34dc7fa96457ea6a0703493d74e63cca357712e Xf86_video_intel:(master)2.99.910-47-gc91af569ee90a832899c9038badd84921e9a87fc Cairo: (master)4144307dbfbe7b297135d9ea4b080cae7e06b997 Libva: (staging)fae9c44816a4c3cfc480d2879d1b4a0c1c3a1527 Libva_intel_driver:(staging)bd630edd844b88ea543a027654db296ff7da16cd Kernel: (drm-intel-nightly) 164a4cb4c1431a0689f85507868356fae24da638 Bug detailed description: ------------------------- It fails on Ironlake with mesa master branch, works well on 10.1 branch. Following piglit cases also fail with same bisect commit: spec_ARB_depth_texture_fbo-depth-GL_DEPTH_COMPONENT24-drawpixels spec_ARB_depth_texture_fbo-depth-GL_DEPTH_COMPONENT32-drawpixels spec_EXT_framebuffer_object_fbo-alphatest-nocolor spec_EXT_framebuffer_object_fbo-alphatest-nocolor-ff Bisect shows: 09d9a8913e8c28fc4c1c60d7da85a2f093786894 is the first bad commit. commit 09d9a8913e8c28fc4c1c60d7da85a2f093786894 Author: Kenneth Graunke <kenneth@whitecape.org> AuthorDate: Fri Feb 7 22:22:45 2014 -0800 Commit: Kenneth Graunke <kenneth@whitecape.org> CommitDate: Wed Feb 19 01:46:16 2014 -0800 i965: Pull format conversion logic out of brw_depthbuffer_format. brw_depthbuffer_format is not very reusable at the moment, since it uses global state (ctx->DrawBuffer) to access a particular depth buffer. For HiZ on Broadwell, I need a function which simply converts the formats. However, at least one existing user of brw_depthbuffer_format really wants the existing interface. So, I've created a new function. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> output: Probe color at (500,400) Expected: 0.300000 0.300000 0.300000 Observed: 0.600000 0.600000 0.600000 Probe color at (220,300) Expected: 0.100000 0.100000 0.100000 Observed: 0.800000 0.800000 0.800000 Probe color at (450,350) Expected: 0.300000 0.300000 0.300000 Observed: 0.600000 0.600000 0.600000 Probe color at (270,350) Expected: 0.100000 0.100000 0.100000 Observed: 0.729412 0.729412 0.729412 Probe color at (270,225) Expected: 0.010000 0.010000 0.010000 Observed: 0.592157 0.592157 0.592157 Probe color at (450,250) Expected: 0.090000 0.090000 0.090000 Observed: 0.600000 0.600000 0.600000 PIGLIT: {'result': 'fail' } Reproduce steps: ------------------------- 1. xinit 2. ./bin/glsl-bug-22603 -fbo -auto
Following cases also fail on Ironlake with same bisect commit: spec_ARB_ES2_compatibility_FBO_blit_from_missing_attachment_(ES2_completeness_rules) spec_ARB_ES2_compatibility_FBO_blit_to_missing_attachment_(ES2_completeness_rules) spec_ARB_framebuffer_object_FBO_blit_from_missing_attachment spec_ARB_framebuffer_object_FBO_blit_to_missing_attachment spec_ARB_framebuffer_object_framebuffer-blit-levels_draw_depth spec_ARB_framebuffer_object_framebuffer-blit-levels_read_depth
Whoops, looks like I failed to rebase this properly after fixing the MESA_FORMAT X8 <-> S8 mixup. Thanks for the report! Patch on the mailing list: http://lists.freedesktop.org/archives/mesa-dev/2014-February/054581.html
commit 82f9ad8c6011f5c1e8fd7065eeb6094f6e16dea9 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Thu Feb 20 23:08:22 2014 -0800 i965: Fix S8 and X8 reversal in brw_depthbuffer_format refactor. In commit 09d9a8913e8c28fc4c1c60d7da85a2f093786894, I accidentally botched the X8 and S8 cases. (I wrote this patch before realizing that X8 and S8 had been swapped in the big MESA_FORMAT rename, and apparently didn't rebase it properly after fixing that...) Fixes regressions in 13 Piglit tests on Ironlake. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75291 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
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.