Am 24.08.2018 um 18:22 schrieb Vicki Pfau:
> Is there anything else I need to do on this? This is my first mesa patch
> so I'm not entirely clear what next steps are for getting it committed.
No that's all needed, pushed, sorry for the delay.
Thanks!
Roland
>
>
> On 08/20/2018 02:44 PM,
Is there anything else I need to do on this? This is my first mesa patch
so I'm not entirely clear what next steps are for getting it committed.
On 08/20/2018 02:44 PM, Roland Scheidegger wrote:
Alright, I guess it's ok then.
In theory the u_cpu_detect bits could be used in different places,
Alright, I guess it's ok then.
In theory the u_cpu_detect bits could be used in different places, for
instance the translate code emits its own sse code, and as long as a
feature was detected properly it may make sense to disable it only for
some users. Albeit llvm setup and the gallivm code need
I was mostly following what was done earlier in the file for Altivec. I
can move it but then ideally the Alitvec check should also be moved.
Vicki
On 08/20/2018 08:53 AM, Roland Scheidegger wrote:
u_cpu_detect should detect what's really available, not what is used
(though indeed we
u_cpu_detect should detect what's really available, not what is used
(though indeed we actually disable u_cpu bits explicitly in gallivm for
some sse features, but this is a hack).
So I think it would be better if u_cpu_detect sets the has_vsx bit
regardless what the env var is and then enable it
Previously gallivm would attempt to use VSX instructions on all systems
where it detected that Altivec is supported; however, VSX was added to
POWER long after Altivec, causing lots of crashes on older POWER/PPC
hardware, e.g. PPC Macs. By detecting VSX separately from Altivec we can
automatically
