Am 30.06.2015 um 03:42 schrieb Dave Airlie: > On 30 June 2015 at 09:36, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 29.06.2015 um 22:18 schrieb Dave Airlie: >>> On 30 June 2015 at 00:58, Roland Scheidegger <srol...@vmware.com> wrote: >>>> Don't worry about the AoS stuff. Only meant to do simple things. >>>> >>>> Looks good overall, I guess it makes sense to not split execution too >>>> (so you'd have native hw vector size there), llvm should handle that >>>> pretty well these days (the sse intrinsics won't get used that way >>>> probably (though there's a helper for that too which makes it possible >>>> but it might not be hooked up, but I guess there's not really much need >>>> for them). >>>> >>>> Some comments inline. >>> >>> I've noticed we have no tests for indirect access to fp64 things, so >>> I'll probably write some first to validate the indirect paths I >>> haven't fixed up yet. >> Ok, thanks for looking at that. > > Okay I've posted a new version of just this patch, > > I fixed up the indirect fetchers all fine, the indirect stores don't occur > with mesa/st and I'm not sure I want fo fix them up without test cases, > I've put an assert in the new patch in case it ever happens. Sounds like a good idea. So doe mesa/st store those to temps then move them to indirect via the address reg? I thought we wanted to kill that eventually...
Roland > > It also uses shufflevector instead of insert/extract fun. > > Otherwise I should have addresses all the things mentioned. > > Dave. > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
