<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 11:26 AM Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">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-31 12:39 a.m., Gustaw Smolarczyk wrote:<br>
> śr., 31 paź 2018 o 00:23 Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> napisał(a):<br>
>> On Tue, Oct 30, 2018 at 7:11 PM Gustaw Smolarczyk <<a href="mailto:wielkiegie@gmail.com" target="_blank">wielkiegie@gmail.com</a>> wrote:<br>
>>> wt., 30 paź 2018 o 23:55 Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> napisał(a):<br>
>>>> On Tue, Oct 30, 2018 at 6:32 PM Gustaw Smolarczyk <<a href="mailto:wielkiegie@gmail.com" target="_blank">wielkiegie@gmail.com</a>> wrote:<br>
>>>>> wt., 30 paź 2018, 23:01 Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>>:<br>
>>>>>> On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote:<br>
>>>>>>> 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>
>>>>>>>>> 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>
>>>>>><br>
>>>>>><br>
>>>>>> So you are saying that gallium multithreading show be slower than singlethreading by default.<br>
<br>
I'm saying we cannot risk tanking performance by a factor of 2-8, under<br>
any circumstances.<br>
<br>
<br>
>>>>> The Ryzen optimization helps a lot of applications (mostly games) and improves their performance, <br>
<br>
How much is "a lot" though? Surely it's less than a factor of 2-8?<br>
<br>
<br>
>>>> Multithreading is slower than singlethreading. You are pretty much saying that Mesa shouldn't use multithreading by default. Just think about that. NVIDIA would destroy us at all price points. I'm not that insane to disable the thread pinning by default.<br>
>>><br>
>>> I have no idea what you are saying. The current implementation of<br>
>>> multithreading doesn't work well with all applications on Ryzen, due<br>
>>> to kernel scheduling application and gallium/winsys threads on<br>
>>> different CCXs. However, thread pinning is not a universal solution<br>
>>> for this problem. We can't express what we want at the moment (i.e.<br>
>>> schedule a couple of threads next to each other, regardless of where<br>
>>> they really are) and the current work-around of using thread<br>
>>> affinities hurts reals applications (like Blender).<br>
>><br>
>> As far as we know, it hurts *only* Blender.<br>
<br>
Why are you still saying that in the light of<br>
<a href="https://bugs.freedesktop.org/108330" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/108330</a> ?<br></blockquote><div><br></div><div>Another candidate for a drirc setting.</div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
>> Don't say "real applications" if you don't have a good list of applications.<br>
> <br>
> Is that an excuse to hurt applications you don't know about? Should we<br>
> ban all applications that use OpenGL and not adhere to the Safe<br>
> Threading Behavior == use OpenGL from one thread and spawn more<br>
> threads from this thread afterwards?<br>
<br>
Yeah, that's just being mean to application developers (which can be<br>
affected even if the application doesn't use OpenGL directly, but via<br>
another library it uses). Let's not compete with other drivers on that.<br>
<br>
<br>
>>> Also, what is the most important, Blender is just a single<br>
>>> application. Any application can have a similarly bad behavior<br>
>>> regarding thread affinity fixing of mesa. Do you expect any<br>
>>> application to "fix itself" for thread affinity shenanigans of the GL<br>
>>> library?<br>
>>><br>
>>> The answer is that libraries shouldn't really mess with thread<br>
>>> affinities. If they do, there should better be a mechanism for<br>
>>> disabling such a behavior for applications that, justifiably, expect a<br>
>>> system-default behavior.<br>
>><br>
>><br>
>> Applications can change the thread affinity. Applications can also call setenv() to disable the Mesa behavior. Users can also disable the Mesa behavior by setting an environment variable or adding a new entry into /usr/share/drirc.d/.<br>
<br>
Mesa isn't the centre of the universe that everything else has to adapt<br>
to. I'm honestly worried that this kind of attitude could damage the<br>
reputation of Mesa (and AMD).<br></blockquote><div><br></div><div>Instead of saying that, you should say "Mesa should be slower with most apps, so that we don't decrease perf for 2 apps too much", because that's what you are saying. It seems like you have some limited belief that only allows you to see the problem on one side (2 apps significantly slower) and prevents you from seeing the problem on the other side (most apps slower), so for some twisted reason or because you just wanna have the feeling of "being right", you would rather see most apps slower than 2 apps significantly slower. I don't give a damn if I'm right. I could be wrong all day and learn. And you shouldn't give a damn if you are right either, because if you do, it shows a fragile ego. I'm looking for objectively the best solution with the least maintenance. The patch on the mailing list gives me the least maintenance as far as I can tell. If you have another solution that needs just as little maintenance, I'm all ears.<br></div><div></div><br><div>Marek<br></div></div></div>