Yeah, there's a bug opened and it's blocking 18.3. I have a series that I think
is mostly there to get it fixed, and it's very high on my list to get finished.
If I can't get it ready in time for 18.3 I'll just revert this and try again
when the MacOS stuff is worked out.
Dylan
Quoting Juan A.
On Wed, 2018-09-05 at 14:55 -0700, Dylan Baker wrote:
> Currently we have two sets of functions for bit counts, one in gallium
> and one in core mesa. The ones in core mesa are header only in many
> cases, since they reduce to "#define _mesa_bitcount popcount", but they
> provide a fallback
On 09/06/2018 10:36 AM, Dylan Baker wrote:
> Quoting Ian Romanick (2018-09-05 15:58:11)
>> After this patch, are
>>
>> grep -r '"u_math.h"'
>>
>> and
>>
>> grep -r 'auxiliary/util/u_math.h'
>>
>> empty?
>
> Yes.
Series is
Reviewed-by: Ian Romanick
> Dylan
signature.asc
Description:
Quoting Ian Romanick (2018-09-05 15:58:11)
> After this patch, are
>
> grep -r '"u_math.h"'
>
> and
>
> grep -r 'auxiliary/util/u_math.h'
>
> empty?
Yes.
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
After this patch, are
grep -r '"u_math.h"'
and
grep -r 'auxiliary/util/u_math.h'
empty?
On 09/05/2018 02:55 PM, Dylan Baker wrote:
> Currently we have two sets of functions for bit counts, one in gallium
> and one in core mesa. The ones in core mesa are header only in many
> cases,
Currently we have two sets of functions for bit counts, one in gallium
and one in core mesa. The ones in core mesa are header only in many
cases, since they reduce to "#define _mesa_bitcount popcount", but they
provide a fallback implementation. This is important because 32bit msvc
doesn't have