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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Feb 16 14:20:31 UTC 2016


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

--- Comment #57 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Iago Toral from comment #55)
> How about dvec3/4 loads (ubo, ssbo, shared variables)? Do we want to split
> these or is it fine to handle them in the backend? I think they are easy
> enough to handle in the backend (I am doing that already), but it is not
> difficult to have NIR split them either.\

Whatever makes your life easier.  If they're not bad to just implement in the
backend, do it.  If it makes things easier to have the spliting pass split
them, then do that.

(In reply to Samuel Iglesias from comment #56)
> In our current implementation, the lowering passes for floor() and ceil()
> are using trunc() to do part of the calculations. Previosly, we scalarized
> trunc() implementation because of its use of nir_if instruction.
> 
> I scalarized both floor() and ceil() lowering passes under the hypothesis
> that nir_bcsel only reads from one channel (like nir_if), because in both
> passes there is at least one bcsel operation before calling trunc(). Now,
> the floor and ceil tests pass for dvecN.
> 
> Is that assumption valid for nir_bcsel?

No.  nir_bcsel is supposed to be fully vectorized.  I'm not sure how well
tested that is though, so there may be a bug in the vec4 NIR code.

-- 
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/20160216/fea60349/attachment.html>


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