ystem Environment: -------------------------- Platform: Ironlake/Sandybridge/Ivybridge/Haswell/Baytrail Libdrm: (master)libdrm-2.4.50 Mesa: (master)7435d9f77c84a57ad9bbed2e6558c0f06cac5cd6 Xf86_video_intel:(master)2.99.906-79-gbd22abee8f33b20ff6bc7297b0a9ae8708d18727 Cairo: (master)8e11a42e3e9b679dce97ac45cd8b47322536a253 Libva: (staging)1264cd81fd8728f18bd2feedf6e9c1a232663890 Libva_intel_driver:(staging)2a61b0d17072bdc5b58608e3dfa2c4f9f80dcec4 Kernel: (drm-intel-nightly) 164a4cb4c1431a0689f85507868356fae24da638 Bug detailed description: ------------------------- It fails on Ironlake/Sandybridge/Ivybridge/Haswell/Baytrail with mesa master branch. It works well on 10.0 branch. GL2Tests_three_uniforms_three_uniforms_vec4_ivec4_bool_use_vec4_to_render_frag.test also fails with same bisect commit. Bisect shows: 13de9f03f177d3ae0921fded1a102b66130f8b40 is the first bad commit. commit 13de9f03f177d3ae0921fded1a102b66130f8b40 Author: Matt Turner <mattst88@gmail.com> AuthorDate: Tue Oct 22 17:51:28 2013 -0700 Commit: Matt Turner <mattst88@gmail.com> CommitDate: Wed Dec 4 20:05:44 2013 -0800 i965/fs: New peephole optimization to generate SEL. fs_visitor::try_replace_with_sel optimizes only if statements whose "then" and "else" bodies contain a single MOV instruction. It also could not handle constant arguments, since they cause an extra MOV immediate to be generated (since we haven't run constant propagation, there are more than the single MOV). This peephole fixes both of these and operates as a normal optimization pass. fs_visitor::try_replace_with_sel is still arguably necessary, since it runs before pull constant loads are lowered. total instructions in shared programs: 1559129 -> 1545833 (-0.85%) instructions in affected programs: 167120 -> 153824 (-7.96%) GAINED: 13 LOST: 6 Reviewed-by: Paul Berry <stereotype441@gmail.com> Reproduce steps: ------------------------- 1. xinit 2. ./GTF -width=64 -height=64 -run=GL2Tests/three_uniforms/three_uniforms_vec4_ivec4_bool_use_ivec4_to_render_frag.test
This happens because the test has flag to use either vec4 or ivec4 uniform. Then branch uses assignment where rvalue expression does i2f on a ivec4, else branch just uses swizzle from a vec4 value. I've sent a patch to mesa-dev to check that types of MOV operation src match which fixes this issue.
fix committed
It still fails on Sandybridge.
(In reply to comment #3) > It still fails on Sandybridge. Not for me .. can you copy paste these lines from test ouput, Do we have some difference there? --- 8< --- gtf_version: 3.0 mode: egl arg: ./GTF -width=64 -height=64 -run=GL2Tests/three_uniforms/three_uniforms_vec4_ivec4_bool_use_ivec4_to_render_frag.test gl_renderer: Mesa DRI Intel(R) Sandybridge Desktop gl_shading_language_version: 1.40 gl_version: 3.1 (Core Profile) Mesa 10.1.0-devel (git-e8ff08e)
ConfigID: 64 RGBA bits( 8, 8, 8, 8) Depth bits: 24 Stencil bits: 8 gtf_version: 3.0 mode: egl arg: ./GTF -width=64 -height=64 -run=GL2Tests/three_uniforms/three_uniforms_vec4_ivec4_bool_use_ivec4_to_render_frag.test gl_renderer: Mesa DRI Intel(R) Sandybridge Desktop x86/MMX/SSE2 gl_shading_language_version: OpenGL ES GLSL ES 3.0 gl_version: OpenGL ES 3.0 Mesa 10.1.0-devel (git-847bc36) gl_vendor: Intel Open Source Technology Center gl_extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_EXT_map_buffer_range GL_OES_depth_texture_cube_map GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_shader_integer_mix stamp: 20140109140917 Zero epsilon: 0.000122, RGBA epsilon: ( 0.004044, 0.004044, 0.004044, 0.004044) three_uniforms: Start #+ GL2Tests/three_uniforms/three_uniforms_vec4_ivec4_bool_use_ivec4_to_render_frag.shader1.ppm and GL2Tests/three_uniforms/three_uniforms_vec4_ivec4_bool_use_ivec4_to_render_frag.shader2.ppm are different three_uniforms: total = 1, failure = 1, #1
(In reply to comment #5) > gl_version: OpenGL ES 3.0 Mesa 10.1.0-devel (git-847bc36) I think the problem is that your Mesa does not have the fix yet, my commit is just one commit above 847bc36, please try again with at least 0978a69 or above.
(In reply to comment #6) > (In reply to comment #5) > > gl_version: OpenGL ES 3.0 Mesa 10.1.0-devel (git-847bc36) > > I think the problem is that your Mesa does not have the fix yet, my commit > is just one commit above 847bc36, please try again with at least 0978a69 or > above. Fixed on latest Mesa.
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.