| Summary: | [bisected i965] oglc pxtrans-cidraw(basic.allCases) regressed | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | fangxun <xunx.fang> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | chadversary |
| Version: | git | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 42993, 43327 | ||
|
Description
fangxun
2012-01-13 01:13:54 UTC
It also happens on mesa 8.0 branch. The failure occurs when there is a shader generated for fixed-function and glDrawPixels has to use _swrast_DrawPixels. Eventually the call to _swrast_DrawPixels will get into _mesa_execute_program. However, since _mesa_ir_link_shader is never called, there is no Mesa IR to execute. Fixed on Mesa master by: commit 9be3be3c6654da18466626c2d45ff4d06b5fb953 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jan 19 17:29:37 2012 -0800 swrast: Use fixed-function processing instead _TexEnvProgram for DrawPixels This is a hack to work around drivers such as i965 that: - Set _MaintainTexEnvProgram to generate GLSL IR for fixed-function fragment processing. - Don't call _mesa_ir_link_shader to generate Mesa IR from the GLSL IR. - May use swrast to handle glDrawPixels. Since _mesa_ir_link_shader is never called, there is no Mesa IR to execute. Instead do regular fixed-function processing. Even on platforms that don't need this, the software fixed-function code is much faster than the software shader code. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44749 Cherry-picking this commit to 8.0 (specifically, atop 19f88670b528827f201bba2a996405d230cedc1b) does not fix zbfunc(basic.glAlways.bitmap) on Sandybridge. Ian, any idea why? (In reply to comment #4) > Cherry-picking this commit to 8.0 (specifically, atop > 19f88670b528827f201bba2a996405d230cedc1b) does not fix > zbfunc(basic.glAlways.bitmap) on Sandybridge. Ian, any idea why? The reason is that use_fragment_program is incorrectly set to true because ctx->FragmentProgram._Current = a valid pointer ctx->FragmentProgram._TexEnvProgram = null When cherry picking this patch (9be3be3), patch 34db7a8 must also be cherry picked. Fix on 8.0 by: commit d51ec2bc2487f5284dd555255dd213742d4bf5f1 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jan 19 17:29:37 2012 -0800 swrast: Use fixed-function processing instead _TexEnvProgram for DrawPixels This is a hack to work around drivers such as i965 that: - Set _MaintainTexEnvProgram to generate GLSL IR for fixed-function fragment processing. - Don't call _mesa_ir_link_shader to generate Mesa IR from the GLSL IR. - May use swrast to handle glDrawPixels. Since _mesa_ir_link_shader is never called, there is no Mesa IR to execute. Instead do regular fixed-function processing. Even on platforms that don't need this, the software fixed-function code is much faster than the software shader code. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44749 (cherry picked from commit 9be3be3c6654da18466626c2d45ff4d06b5fb953) commit a0d4675b312241ec797014921c9b2468cbff56d6 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jan 19 17:23:51 2012 -0800 mesa: Make sure _TexEnvProgram points at the current ff fragment program At least one place, the _mesa_need_secondary_color function in state.h, uses this to make decisions. The next patch in this series will add another dependency. Ideally, this field would go away and be replace by a flag or something. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit 34db7a8c1e775aaefad7952133e087f1c1a569f6) System Environment: -------------------------- Libdrm: (master)2.4.30-18-gb643b0713aefdc0611e47654e88263b53b0de6f5 Mesa: (master)f9f8ce3ead04b5334bb323c37ec1f905ca5f58b2 Xserver: (master)xorg-server-1.11.99.902 Xf86_video_intel: (master)2.17.0-599-gca252e5b51d7b2f5a7b2c2e0d8fdb024b08096db with the latest mesa, this issue has been fixed. (In reply to comment #7) > Fix on 8.0 by: > commit d51ec2bc2487f5284dd555255dd213742d4bf5f1 > Author: Ian Romanick <ian.d.romanick@intel.com> > Date: Thu Jan 19 17:29:37 2012 -0800 > swrast: Use fixed-function processing instead _TexEnvProgram for DrawPixels > This is a hack to work around drivers such as i965 that: > - Set _MaintainTexEnvProgram to generate GLSL IR for > fixed-function fragment processing. > - Don't call _mesa_ir_link_shader to generate Mesa IR from the > GLSL IR. > - May use swrast to handle glDrawPixels. > Since _mesa_ir_link_shader is never called, there is no Mesa IR to > execute. Instead do regular fixed-function processing. > Even on platforms that don't need this, the software fixed-function > code is much faster than the software shader code. > NOTE: This is a candidate for the 8.0 branch. > Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> > Reviewed-by: Brian Paul <brianp@vmware.com> > Reviewed-by: Eric Anholt <eric@anholt.net> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44749 > (cherry picked from commit 9be3be3c6654da18466626c2d45ff4d06b5fb953) > commit a0d4675b312241ec797014921c9b2468cbff56d6 > Author: Ian Romanick <ian.d.romanick@intel.com> > Date: Thu Jan 19 17:23:51 2012 -0800 > mesa: Make sure _TexEnvProgram points at the current ff fragment program > At least one place, the _mesa_need_secondary_color function in > state.h, uses this to make decisions. The next patch in this series > will add another dependency. Ideally, this field would go away and be > replace by a flag or something. > NOTE: This is a candidate for the 8.0 branch. > Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> > Reviewed-by: Brian Paul <brianp@vmware.com> > Reviewed-by: Eric Anholt <eric@anholt.net> > (cherry picked from commit 34db7a8c1e775aaefad7952133e087f1c1a569f6) System Environment: -------------------------- Libdrm: (master)2.4.30-18-gb643b0713aefdc0611e47654e88263b53b0de6f5 Mesa: (8.0)caebd7929dca802ece8ef36b0f85094d66133b57 Xserver: (server-1.11-branch)xorg-server-1.11.3 Xf86_video_intel: (master)2.17.0-599-gca252e5b51d7b2f5a7b2c2e0d8fdb024b08096db verify with mesa 8.0 branch, this case also can pass. so it has been 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.