<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Add FP64 support to the i965 shader backends" href="https://bugs.freedesktop.org/show_bug.cgi?id=92760#c49">Comment # 49</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Add FP64 support to the i965 shader backends" href="https://bugs.freedesktop.org/show_bug.cgi?id=92760">bug 92760</a> from <a class="email" href="mailto:cwabbott0@gmail.com" title="Connor Abbott <cwabbott0@gmail.com>"> Connor Abbott</a> <pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=92760#c48">comment #48</a>) > Connor, I think there is a problem with the implementation of d2f and f2d in > the vec4 backend. These use a generator opcode that switches to scalar mode > like this (for d2f): > > brw_set_default_access_mode(p, BRW_ALIGN_1); > dst.hstride = BRW_HORIZONTAL_STRIDE_2; > dst.width = BRW_WIDTH_4; > brw_MOV(p, dst, src[0]); > brw_set_default_access_mode(p, BRW_ALIGN_16); > > The problem with this is that scalar mode does not consider the swizzle in > src[0] and because of copy-propagation, we can end up with a swizzle like > zwzw here. > > In the case of d2f, it seems that I can just do a normal MOV in align16 > mode and that seems to work, but f2d is not so easy and we probably need > align1 mode there. > > Of course, we can fix this by disabling copy-propagation for the generator > opcodes we use for this, I suppose that should be alright, but I wonder if > you think there is a better approach. Yeah, I think that my plan was just to disable copy propagation into those. We already do this for other opcodes where we use align1 mode, and I thought I had already disabled it, although I could be mis-remembering. If we try and handle the swizzle in the generator by emitting another MOV, we would just be undoing the copy propagation which seems a little silly.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>