On 1 July 2015 at 00:52, Roland Scheidegger <srol...@vmware.com> wrote: > 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... >
Yes it does that, my problem is I'd can't test this without the st being fixed, so its kinda chicken/egg, if the st gets fixed then fixing this is a lot easier, and we hit an assert so we know to fix it. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
