[Mesa-dev] [PATCH 0/8] Gallium & RadeonSI optimization for Ryzen CPUs

[Marek Olšák]

On Mon, Sep 10, 2018 at 10:45 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 2018-09-07 9:01 p.m., Marek Olšák wrote:
>> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
>>>> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer <michel at daenzer.net> wrote:
>>>>> On 2018-09-06 10:56 p.m., Axel Davy wrote:
>>>>>
>>>>>> I fear if we begin to do the work manually, there won't be interest to
>>>>>> do that in the kernel,
>>>>>> and thus all applications will need to include such core pinning code to
>>>>>> have good performance when
>>>>>> multithreaded.
>>>>>
>>>>> I'm also a bit worried that this solution could result in multiple
>>>>> processes contending for the same set of CPU cores, while other cores
>>>>> might be underused, which could result in worse overall system performance.
>>>>
>>>> Any suggestion how to choose the ccx such that processes end up on a
>>>> different one?
>>>
>>> One thing you could do is use a random initial offset. That should at
>>> least avoid e.g. most applications using the same toolkit (which may do
>>> OpenGL calls, even if the application itself doesn't) choosing the same one.
>>
>> I'll update the helper function to choose the initial CCX with
>> (os_time_get_nano() % num_L3_caches). That should be random.
>
> Why not use an RNG API for getting a random number?

It depends on apps calling srand.

>
>
>>> In the worst case, all processes using OpenGL (or at least their OpenGL
>>> related threads, but that usually includes the main thread) could end up
>>> restricted to the same 4 cores, leaving up to 28 cores underused.
>>
>> 4C/4T used to be a standard and certainly enough for gaming. 4C/8T
>> used to be luxury before Ryzen, which is now the CCX. We should be
>> fine with 4 cores.
>
> Sounds like "640K of memory ought to be enough for anybody"...
>
>
> Anyway, per reports on IRC, the core pinning can hurt even individual
> applications, e.g. blender. I like your idea of a driconf option, but it
> should be disabled by default, and only enabled for apps where it's
> known safe and beneficial in practice.

Before we do anything, we can be discuss it with Blender developers or
we can add drirc entry for Blender.

I don't think we have any other option. Disabling the optimization
would make Mesa multithreading slower than singlethreading.

Marek