On Thu, Mar 17, 2016 at 11:17 AM, Matt Turner <matts...@gmail.com> wrote:
> On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand <ja...@jlekstrand.net> > wrote: > > --- > > src/mesa/drivers/dri/i965/brw_vec4.cpp | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp > b/src/mesa/drivers/dri/i965/brw_vec4.cpp > > index baf72a2..155a550 100644 > > --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp > > +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp > > @@ -375,6 +375,7 @@ vec4_visitor::opt_vector_float() > > if (inst->opcode != BRW_OPCODE_MOV || > > inst->dst.writemask == WRITEMASK_XYZW || > > inst->src[0].file != IMM || > > + inst->src[0].type != inst->dst.type || > > Why? > That may be the wrong condition. The reason is that the code below doesn't look at the source type at all and just assumes that it's a float. If, for instance, we had the first case below but instead of 0D we had some non-zero VF-capable value, it would interpret it as a float, cram it into a VF, and then copy it to m2 doing a re-interpret instead of doing a conversion. Thinking about it harder, I'm convinced that this patch is bogus, but the bug is real. --Jasoan > This breaks legitimate optimizations, like > > -mov m2.xy:F, 0.500000F > -mov m2.zw:F, 0D > +mov m2:F, [0.5F, 0.5F, 0F, 0F] > > and > > -mov vgrf6.0.x:D, -1082130432D > -mov vgrf6.0.y:D, 1056964608D > -mov vgrf6.0.z:D, 1065353216D > +mov vgrf6.0.xyz:F, [-1F, 0.5F, 1F, 0F] > > and > > -mov vgrf7.0.x:D, 1073741824D > -mov vgrf7.0.yz:D, 0D > +mov vgrf7.0.xyz:F, [2F, 0F, 0F, 0F] > > > The first one we should just handle in opt_algebraic by fixing the src > type. The other two look like NIR fail. If we fixed those things, I'd > be fine with this. >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
