Hi Emil, Greg,
> > (Needs CPU topology detection to actually work)
>
Does it? Or does it just need the topology detection for the current
"default" behavior for thread placement? The default behavior for swr is
to use the cpu topology info to place one thread per core and pin it to
that core.
Quoting Emil Velikov (2018-01-18 10:50:05)
> On 18 January 2018 at 18:09, Greg V wrote:
> > On 01/18/2018 21:01, Emil Velikov wrote:
> >>
> >> On 31 December 2017 at 16:55, Greg V wrote:
> >>>
> >>> (Needs CPU topology detection to actually work)
> >>
> >> IMHO it might be better to drop the patc
On 18 January 2018 at 18:09, Greg V wrote:
> On 01/18/2018 21:01, Emil Velikov wrote:
>>
>> On 31 December 2017 at 16:55, Greg V wrote:
>>>
>>> (Needs CPU topology detection to actually work)
>>
>> IMHO it might be better to drop the patch, until its actually working.
>> There's little point in b
On 01/18/2018 21:01, Emil Velikov wrote:
On 31 December 2017 at 16:55, Greg V wrote:
(Needs CPU topology detection to actually work)
IMHO it might be better to drop the patch, until its actually working.
There's little point in building it if one cannot use it.
What do you think?
Yeah, I gues
On 31 December 2017 at 16:55, Greg V wrote:
> (Needs CPU topology detection to actually work)
IMHO it might be better to drop the patch, until its actually working.
There's little point in building it if one cannot use it.
What do you think?
-Emil
___
(Needs CPU topology detection to actually work)
---
src/gallium/drivers/swr/rasterizer/common/os.h | 3 ++-
src/gallium/drivers/swr/rasterizer/core/threads.cpp | 4 ++--
src/gallium/drivers/swr/swr_fence.cpp | 2 ++
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/
