Tweaked scheduling so it survives this situation by scattering
"extra" threads uniformly over all the NUMA nodes.
There are still tweaks possible to make some specific hardware
configurations work better.
(Part 1 was 00963afc14978b)
Does the following changes visible to users:
* Use panels and sub-panels for more structured & logical grouping
* Re-organized options more logically than before (see images in D4148)
* Use flow layout (single column by default).
* New layout uses horizontal margin if there's enough space.
* Change size of Preferences window to suit new layout.
* Move keymap related options from "Input" into own section.
* Own, left-bottom aligned region for Save Preferences button.
* Adjustments of names, tooltips & icons.
* Move buttons from header into the main region (except editor switch).
* Hide Preferences header when opened in temporary window.
* Use full area width for header.
* Don't use slider but regular number widget for UI scale.
* Gray out animation player path option if player isn't "Custom"
Internal changes:
* Rearrange RNA properties to match changed UI structure.
* Introduces new "EXECUTE" region type, see reasoning in D3982.
* Changes to panel layout and AZone code for dynamic panel region.
* Bumps subversion and does versioning for new regions.
RNA changes are documented in the release notes:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Preferences_API
Design & implementation mostly done by @billreynish and myself.
I recommend checking out the screenshots posted by William:
https://developer.blender.org/D4148#93787
Reviewed By: brecht
Maniphest Tasks: T54115
Differential Revision: https://developer.blender.org/D4148
Please always build tests when messing with build system/libs, am tired
of fixing that kind of issues...
Also, that fix is probably not working for standalone, no idea where's
the numaapi lib then, but committing since I need a building blender
here (with the tests, yes).
Please always build tests when messing with build system/libs, am tired
of fixing that kind of issues...
Also, that fix is probably not working for standalone, no idea where's
the numaapi lib then, but committing since I need a building blender
here (with the tests, yes).
The issue was introduced by a Threadripper2 commit back in
ce927e15e0. This boils down to threads inheriting affinity
from the parent thread. It is a question how this slipped
through the review (we definitely run benchmark round).
Quick fix could have been to always set CPU group affinity
in Cycles, and it would work for Windows. On other platforms
we did not have CPU groups API finished.
Ended up making Cycles aware of NUMA topology, so now we
bound threads to a specific NUMA node. This required adding
an external dependency to Cycles, but made some code there
shorter.
Previously we would try to guess what the main tablet device is, but this is
error prone. Now we keep a list of X11 devices and try to match events to
them. On the Blender side there are still some limitations in regards to using
multiple devices at the same time, but this should improve things already.
Fixes T59645.
Previously we would try to guess what the main tablet device is, but this is
error prone. Now we keep a list of X11 devices and try to match events to
them. On the Blender side there are still some limitations in regards to using
multiple devices at the same time, but this should improve things already.
Fixes T59645.
Object visibility is now handled by the depsgraph iterator, but this API
was incomplete as it made no distinction for visibility of the object itself,
particles and generated instances.
The depsgraph iterator API now includes information about which part of the
object is visible, and this is used by Cycles to replace the old custom logic.
Cycles and EEVEE visibility should now be consistent, which unfortunately does
means some subtle compatibility breakage for both.
Fixes T58956, T58202, T59284.
Differential Revision: https://developer.blender.org/D4109
The key indices were wrong: need to offset curve key index
by first curve key index. Also corrected calculation of the
interpolation step.
Annoyingly, can not reproduce this on a simple file, need
production rig. For the possible future look the following
file from Spring was used: 03_005_A.lighting.debug.blend
