[Bug 92760] Add FP64 support to the i965 shader backends

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Feb 11 15:38:54 CET 2016


https://bugs.freedesktop.org/show_bug.cgi?id=92760

--- Comment #49 from Connor Abbott <cwabbott0 at gmail.com> ---
(In reply to Iago Toral from comment #48)
> 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160211/d7283cb8/attachment-0001.html>


More information about the intel-3d-bugs mailing list