[Mesa-dev] [PATCH 2/3] gallivm: add fp64 support.
Dave Airlie
airlied at gmail.com
Tue Jun 30 19:49:25 PDT 2015
On 1 July 2015 at 00:52, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 30.06.2015 um 03:42 schrieb Dave Airlie:
>> On 30 June 2015 at 09:36, Roland Scheidegger <sroland at vmware.com> wrote:
>>> Am 29.06.2015 um 22:18 schrieb Dave Airlie:
>>>> On 30 June 2015 at 00:58, Roland Scheidegger <sroland at 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.
More information about the mesa-dev
mailing list