<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote:<br>
> pon., 17 wrz 2018 o 18:24 Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> napisał(a):<br>
>><br>
>> On 2018-09-15 3:04 a.m., Marek Olšák wrote:<br>
>>> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote:<br>
>>>><br>
>>>> Last but not least, this doesn't solve the issue of apps such as<br>
>>>> blender, which spawn their own worker threads after initializing OpenGL<br>
>>>> (possibly not themselves directly, but via the toolkit or another<br>
>>>> library; e.g. GTK+4 uses OpenGL by default), inheriting the thread affinity.<br>
>>>><br>
>>>><br>
>>>> Due to these issues, setting the thread affinity needs to be disabled by<br>
>>>> default, and only white-listed for applications where it's known safe<br>
>>>> and beneficial. This sucks, but I'm afraid that's the reality until<br>
>>>> there's better API available which allows solving these issues.<br>
>>><br>
>>> We don't have the bandwidth to maintain whitelists. This will either<br>
>>> have to be always on or always off.<br>
>>><br>
>>> On the positive side, only Ryzens with multiple CCXs get all the<br>
>>> benefits and disadvantages.<br>
>><br>
>> In other words, only people who spent relatively large amounts of money<br>
>> for relatively high-end CPUs will be affected (I'm sure they'll be glad<br>
>> to know that "common people" aren't affected. ;). Affected applications<br>
>> will see their performance decreased by a factor of 2-8 (the number of<br>
>> CCXs in the CPU).<br>
>><br>
>> OTOH, only a relatively small number of games will get a significant<br>
>> benefit from the thread affinity, and the benefit will be smaller than a<br>
>> factor of 2. This cannot justify risking a performance drop of up to a<br>
>> factor of 8, no matter how small the risk.<br>
>><br>
>> Therefore, the appropriate mechanism is a whitelist.<br>
> <br>
> Hi,<br>
> <br>
> What was the conclusion of this discussion? I don't see any<br>
> whitelist/blacklist for this feature.<br>
> <br>
> I have just tested blender and it still renders on only a single CCX<br>
> on mesa from git master. Also, there is a bug report that suggests<br>
> this regressed performance in at least one game [1].<br>
<br>
I hooked up that bug report to the 18.3 blocker bug.<br>
<br>
<br>
> If you think enabling it by default is the way to go, we should also<br>
> implement a blacklist so that it can be turned off in such cases.<br>
<br>
I stand by my opinion that a white-list is appropriate, not a<br>
black-list. It's pretty much the same as mesa_glthread.<br></blockquote><div><br></div><div>So you are saying that gallium multithreading show be slower than singlethreading by default.</div><div><br></div><div>Marek</div><br></div></div>