On 31.10.18 21:41, Marek Olšák wrote: > 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.
So, on a personal level, I feel like maybe your phrasing was a bit harsh and could be toned down. On the technical level, the problem is that while yes, only a small number of apps are negatively affected, the negative effect as reported is *absolutely massive*. The positive effect of the affinity hack, on the other hand, is obviously decent and very welcome, but unfortunately nowhere near as big. The reality of users is that most of them don't complain when they're confronted with sucky software. Or they complain within their circles, slowly contributing to a negative reputation of the software in a way that doesn't reach us. (That's a general pattern which causes most software to suck more than necessary.) We (and really mostly you of all people) have worked very hard to improve our reputation for producing great drivers. We shouldn't squander that. So I think on the technical merits, the others on this thread are right. The explicit affinity setting was a good initiative and turned out to be very useful, but unfortunately we really need to go with a whitelisting approach at this point, while making sure that the whitelist option gets good exposure on Phoronix et al. The real long-term solution would be anyway to figure out why the kernel doesn't do a good job of placing the Gallium driver thread on the right CCX, and then fixing that. To be honest, I've always thought that the explicit affinity approach is more of a hack. And the proper long-term approach is quite likely to help improve the performance of Ryzen / Threadripper / EPYC in general, not just for Mesa. But my educated guess is that that's not something any of us can do in a week (though I'd be happy for you to prove me wrong :)), and in any case, it takes a long time for kernel improvements like that to filter through to end users, so going with a whitelist seems the right thing to do either way. Cheers, Nicolai > > Marek > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
