On 31 October 2011 11:59, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5">On 10/28/2011 02:59 PM, Eric Anholt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 28 Oct 2011 10:42:44 -0700, "Ian Romanick"<<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Ian Romanick<<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.<u></u>com</a>><br>
<br>
_mesa_ir_link_shader needs to be called before cloning the IR tree so<br>
that the var->location field for uniforms is set.<br>
<br>
WARNING: This change breaks several integer division related piglit<br>
tests. The tests break because _mesa_ir_link_shader lowers integer<br>
division to an RCP followed by a MUL. The fix is to factor out more<br>
of the code from ir_to_mesa so that _mesa_ir_link_shader does not need<br>
to be called at all by the i965 driver. This will be the subject of<br>
several follow-on patches.<br>
</blockquote>
<br>
How close are we to avoiding Mesa IR at this point? I'd rather see us<br>
hack in something to suppress that lowering or something if it's going<br>
to be very long.<br>
</blockquote>
<br></div></div>
A week or two, tops. Most of the bits that need to be split out are already split out (and are shared between ir_to_mesa and st_glsl_to_tgsi). I thought about adding a boolean flag so that ir_to_mesa would skip all lowering, but I think that would lead to a lot of follow-on failures in ir_to_mesa. That code rightfully makes a lot of assumptions about how the IR will look before it does code generation.</blockquote>
<div><br>Just noticed that this patch series got pushed without resolving the integer division problems. Was that intentional? If so, do we have a new ETA on fixing it? Some of the transform feedback tests I've been working on do a lot of integer math and I'm wondering whether I should avoid integer division for a while.<br>
<br>Paul<br></div></div>