Alternative solution to #141392 / #141564.
As a recap, the DST global lock (which prevented running drawing code
from multiple threads concurrently) was removed for 4.5 (#134690).
One unforeseen issue is that Images (and their GPUTextures) are shared
across dependency graphs (and therefore multiple threads), meaning we
are running into data race issues with them.
@fclem did #141392 and I continued it #141564. However, this is only a
partial solution, parts of the GPUTexture API and the whole BKE_image
API are still unsafe.
Trying to solve all the possible underlying issues seems unrealistic for
4.5 given the time frame and that the extension of the code affected by
this issue is quite large.
So this PR just brings the 4.4 locking behavior instead, which, while
risky on its own, seems much safer to me than the alternative.
This effectively undoes the improvements from #134690 by disabling
concurrent rendering, but instead of reverting all the code, it just
ensures we hold the lock in the same places we did in 4.4.
This means there's some redundant code that is not technically needed
anymore, like the `submission_mutex`, but it's probably best to make as
few modifications as possible, given how close we are to release and
that this is only intended as a temporary measure.
Pull Request: https://projects.blender.org/blender/blender/pulls/141618
Cleanup and simplification of GPUMaterial and GPUPass compilation.
See #133674 for details/goals.
- Remove the `draw_manage_shader` thread.
Deferred compilation is now handled by the gpu::ShaderCompiler
through the batch compilation API.
Batch management is handled by the `GPUPassCache`.
- Simplify `GPUMaterial` status tracking so it just queries the
`GPUPass` status.
- Split the `GPUPass` and the `GPUCodegen` code.
- Replaced the (broken) `GPU_material_recalc_flag_get` with the new
`GPU_pass_compilation_timestamp`.
- Add the `GPU_pass_cache_wait_for_all` and
`GPU_shader_batch_wait_for_all`, and remove the busy waits from
EEVEE.
- Remove many unused functions, properties, includes...
Pull Request: https://projects.blender.org/blender/blender/pulls/135637
This avoid stalling the viewport when a preview job is running.
This is because both were fighting for the same GPU context.
This doesn't remove the blocking but allows to remove it using #136991.
Pull Request: https://projects.blender.org/blender/blender/pulls/138882
Tests were calling the submission mutex without
init. Adding functions to expose only setting
up the submission mutex instead of the full
DRW context (which is uneeded here).
Regression from 583e2b7240
`DRW_shader_init()` calls `GPU_context_create` before having a valid
GHOST context active (`WM_system_gpu_context_activate(system_gpu_context)`).
Swap the calling order to fix the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136270
This refactor part of `draw_manager_c.cc` to make it more understandable
and less bug prone.
- Splits the context handing to `draw_gpu_context.cc`
- Rename `draw_manager_c.cc` to `draw_context.cc`
- Merge `DRWContextState` into `DRWContext`
- Merge lots of static functions into `DRWContext` to avoid global access
- Deduplicate code between entry point functions
- Move context init logic to `DRWContext` constructor
- Move resource init logic to `DRWContext::acquire_data`
- Move extraction `TaskGraph` out of `DRWContext`
- Reduce / centralize complexity of enabling draw engines
- Reduce the amount of `drw_get` calls
- Remove unused code
Pull Request: https://projects.blender.org/blender/blender/pulls/135821
