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