<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Line rendering broken in Dolphin when using gl_ClipDistance" href="https://bugs.freedesktop.org/show_bug.cgi?id=97232#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Line rendering broken in Dolphin when using gl_ClipDistance" href="https://bugs.freedesktop.org/show_bug.cgi?id=97232">bug 97232</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>I played around with this on gen6. Unfortunately the attached trace is unusable there due to the #version 400 selection, however building dolphin from the referenced PR was able to reproduce the issue. Not sure if it's related, but I'm seeing a read-out-of-bounds when running valgrind on a trace generated on gen6: ==18850== Memcheck, a memory error detector ==18850== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==18850== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==18850== Command: glretrace dolphin-emu-nogui.trace ==18850== ==18850== Invalid read of size 4 ==18850== at 0xA687DEA: brw::vec4_visitor::var_range_end(unsigned int, unsigned int) const (brw_vec4_live_variables.cpp:335) ==18850== by 0xA67B77C: brw::vec4_visitor::opt_cse_local(bblock_t*) (brw_vec4_cse.cpp:249) ==18850== by 0xA67BD7A: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:274) ==18850== by 0xA6779A5: brw::vec4_visitor::run() [clone .part.22] (brw_vec4.cpp:1988) ==18850== by 0xA678677: brw_compile_vs (brw_vec4.cpp:2173) ==18850== by 0xA5A85B5: brw_codegen_vs_prog (brw_vs.c:194) ==18850== by 0xA5A8BDD: brw_vs_precompile (brw_vs.c:405) ==18850== by 0xA5909B9: brw_shader_precompile (brw_link.cpp:65) ==18850== by 0xA5909B9: brw_link_shader (brw_link.cpp:283) ==18850== by 0xA41F715: _mesa_glsl_link_shader (ir_to_mesa.cpp:3070) ==18850== by 0xA31F9AD: _mesa_link_program.part.22 (shaderapi.c:1093) ==18850== by 0x58163D: retrace_glLinkProgram(trace::Call&) (in /usr/bin/glretrace) ==18850== by 0x40CD18: retrace::retraceCall(trace::Call*) (in /usr/bin/glretrace) ==18850== Address 0xd190280 is 0 bytes after a block of size 320 alloc'd ==18850== at 0x4C2C070: calloc (vg_replace_malloc.c:623) ==18850== by 0xA4C6E61: rzalloc_size (ralloc.c:125) ==18850== by 0xA6878EC: brw::vec4_visitor::calculate_live_intervals() (brw_vec4_live_variables.cpp:242) ==18850== by 0xA67BD5D: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:271) ==18850== by 0xA6779A5: brw::vec4_visitor::run() [clone .part.22] (brw_vec4.cpp:1988) ==18850== by 0xA678677: brw_compile_vs (brw_vec4.cpp:2173) ==18850== by 0xA5A85B5: brw_codegen_vs_prog (brw_vs.c:194) ==18850== by 0xA5A8BDD: brw_vs_precompile (brw_vs.c:405) ==18850== by 0xA5909B9: brw_shader_precompile (brw_link.cpp:65) ==18850== by 0xA5909B9: brw_link_shader (brw_link.cpp:283) ==18850== by 0xA41F715: _mesa_glsl_link_shader (ir_to_mesa.cpp:3070) ==18850== by 0xA31F9AD: _mesa_link_program.part.22 (shaderapi.c:1093) ==18850== by 0x58163D: retrace_glLinkProgram(trace::Call&) (in /usr/bin/glretrace) However commenting out opt_cse does not resolve the (underlying) issue. A separate thought is that only gl_ClipDistance[0] is written, and there is some indication that if any of the clip distances are NaN, the whole primitive gets rejected. However also writing distances 1,2,3 didn't help, nor did writing 4..7. (Although it did appear to stop flickering a wrong primitive for one frame in that situation... all black now.)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>