"Haehnle, Nicolai" <nicolai.haeh...@amd.com> writes: > 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.
I completely agree.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
