On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer <mic...@daenzer.net> wrote:
> On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote: > > pon., 17 wrz 2018 o 18:24 Michel Dänzer <mic...@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 <mic...@daenzer.net> > wrote: > >>>> > >>>> Last but not least, this doesn't solve the issue of apps such as > >>>> blender, which spawn their own worker threads after initializing > OpenGL > >>>> (possibly not themselves directly, but via the toolkit or another > >>>> library; e.g. GTK+4 uses OpenGL by default), inheriting the thread > affinity. > >>>> > >>>> > >>>> Due to these issues, setting the thread affinity needs to be disabled > by > >>>> 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 [1]. > > 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. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
