BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
The idea is to make main thread and job threads to be scheduled
on CPU dies which has direct access to memory (those are NUMA
nodes 0 and 2).
We also do this for new EPYC CPUs since their NUMA nodes 1 and 3
do have access but only to a higher range DDR slots. By preferring
nodes 0 and 2 on EPYC we make it so users with partially filled
DDR slots has fast memory access.
One thing which is not really solved yet is localization of
memory allocation: we do not guarantee that memory is allocated
on the closest to the NUMA node DDR slot and hope that memory
manager of OS is acting in favor of us.
- Use BLI_threadpool_ prefix for (deprecated)
thread/listbase API.
- Use BLI_thread as prefix for other functions.
See P614 to apply instead of manually resolving conflicts.
Not sure why I made the logic so complicated before, this change should solve
the deadlock when the render thread tries to acquire the main thread lock while
the main thread is waiting for threads to finish.
The scene pointer used for looking up the appropriate source of render result images in the image editor was always taken from context. This means that render results for a different scene would never be
displayed in the image editor.
To give feedback on running renders, try to get the running render job's scene pointer in the image editor for render result type images. This only happens during rendering, apart from that the regular
context scene result is displayed.
Now the viewport rendering thread will lock the main thread while it is exporting
objects to render data. This is not ideal if you have big scenes that might block
the UI, but Cycles does the same, and it's fairly quick because the same evaluated
mesh can be used as for viewport drawing. It's the only way to get things stable
until the thread safe dependency graph is here.
This adds a mechanism to the job system for jobs to lock the main thread, using a
new 'ticket mutex lock' which is a mutex lock that gives priority to the first
thread that tries to lock the mutex.
Still to solve: undo/redo crashes.
- reverted fix for bug 32537 (error report drawing after thread job didn't show)
This solves very bad 3d view render updates while using transform, it was
getting into an eternal feedback loop for dependencies. (jobs sending mousemoves
causing jobs to end, causing mousemoves, causing etc).
- The render-update code was not going over all windows, but over every screen to
send signals (also the invisble ones)
This commit basically implements frames prefetching for
movie clip datablock.
Number of frames to be prefetched is controlled in User
Preferences, System tab, Prefetch Frames option.
Currently prefetching is destructive-less for movie cache,
meaning mo frames will be removed from the cache when while
prefetching. This is because it's half of simplier to
implement, but it also makes sense from tracking point of
view -- we could want to playback in both directions and
removing frames from behind time cursor is not always a
good idea.
Anyway, smarter prefetching strategy could be developed
later.
Some implementation notes:
- Added MEM_CacheLimiter_get_memory_in_use function to get
memory usage of specified memory limiter.
- Fixed prototype of MEM_CacheLimiter_get_maximum which
was simply wrong (used wrong data type for output).
- Added some utility functions to movie clip and movie
cache for direct cache interaction and obtaining cache
statistics.
- Prefetching is implemented using general jobs system.
which is invoking from clip draw function.
- Prefetcing will stop as soon other job or playback starts.
This is done from performance point of view. Jobs will
likely require lots of CPU power and better to provide
whole CPU to it.
Playback is a bit more complicated case. For jpeg sequence
playback prefetching while paying back is nice. But trying
to prefetch heavy exr images and doing color space
conversion slows down both playback and prefetching.
TODO:
- Think of better policy of dealing with already cached frames
(like when cached frames from other clips prevents frames
from current clip to be prefetched)
- Currently a bit funky redraw notification happens from
prefetch job. Perhaps own ND_ is better to have here.
- Hiding clip while prefetch is active in theory shall stop
prefetching job.
- Having multiple clips opened on file load will prefetch
frames for only one of them.
Was own regression when was solving conflict between sequencer preview
and compositor jobs. Made it so now only compositor jobs are being
killed from sequencer preview.
- remove double promotions
- use UI_DPI_ICON_FAC macro rather then dpi/72
- add assert to prevent creating jobs with WM_JOB_TYPE_ANY, which should only be used for finding jobs.
Fluid sim would stop or crash with node editor.
Bug was a real bad one - the code for giving out WM jobs was messed up for long.
It was giving a running fluid job to the compositer even... tsk!
I will go over jobs code carefully next days to see if it all behaves. Now it
allows per owner multiple jobs, provided it has different job_type set.
Also fixed: preview renders (material) were deadslow once a while - caused
by icon render setting miniature tile render sizes. Now it's fast again,
but there are still 3 icon jobs running per UI change... need to check what.
Screencast recording stopped on a undo/redo. This was because all thread jobs
were killed then. Now it leaves screen jobs (screen cast) running, that's
data that doesn't change on undos.
Also renamed jobs_stop_all() to jobs_kill_all() - it terminates threads.
