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
The stencil value was also considered and could lead to out of range
depth values. These were ignored by operators and could lead to
printing errors, canceling operators, or inaccurate depth
selection.
This is a NVIDIA only issue as these GPU support DEPTH24S8 textures.
We should consider defaulting to DEPTH32FS8.
Pull Request: https://projects.blender.org/blender/blender/pulls/139272
Add back the deprecated format to avoid asserts.
GPU backends should still have the code to support them.
Also add deprecation warnings as these types will be
removed for 5.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/139213
This promotes any INT_TO_FLOAT attribute to F32 and
to the float promotion inside python `attr_fill`.
We issue a deprecation warning when hitting this path.
Raise an error is the component type is not integer.
Pull Request: https://projects.blender.org/blender/blender/pulls/139206
It can happen that the previous context drew with a different
colorspace. In the case where the new context is drawing with
the same shader that was previously bound (shader binding
optimization), the uniform would not be set again because the
dirty flag would not have been set (since the color space of
this new context never changed). The shader would reuse the same
colorspace as the previous context framebuffer (see #137855).
Fix#137855
Pull Request: https://projects.blender.org/blender/blender/pulls/139226
This was caused by the removal of some compatibility code
in the metal backend.
This patch reintroduce this compatibility code in a cleaner
way than before.
This should be followed up by a documentation commit that
explains what is supported and what is not.
Pull Request: https://projects.blender.org/blender/blender/pulls/139185
This caused UB in the tests now that tests are all ran
inside the same context.
A shader could be free but its pointer would be dangling
inside the `Context`. A new shader could have the same
address and generate UB after binding.
This is not the best way to solve this issue but at least
we prevent the use of the UB.
Pull Request: https://projects.blender.org/blender/blender/pulls/139109
This allows multiple threads to request different specializations without
locking usage of all specialized shaders program when a new specialization
is being compiled.
The specialization constants are bundled in a structure that is being
passed to the `Shader::bind()` method. The structure is owned by the
calling thread and only used by the `Shader::bind()`.
Only querying for the specialized shader (Map lookup) is locking the shader
usage.
The variant compilation is now also locking and ensured that
multiple thread trying to compile the same variant will never result
in race condition.
Note that this removes the `is_dirty` optimization. This can be added
back if this becomes a bottleneck in the future. Otherwise, the
performance impact is not noticeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/136991
This feature greatly increase depth buffer precision.
This is very noticeable in large view distance scenes.
This is enabled by default on GPUs that supports it (most of the hardware we
support already supports this). This makes rendering different on the GPUs
that do not support that feature (`glClipControl`).
While this give much better depth precision as before, we also have a lot of
imprecision caused by our vertex transformations. This can be improved in
another task.
Pull Request: https://projects.blender.org/blender/blender/pulls/138898
When using float2/int2/uint2 arrays the elements could be incorrectly
alligned. This wasn't noticable when using Blender as it isn't used,
However python addons and forks can use it.
Fixes an issue with UPBGE
Pull Request: https://projects.blender.org/blender/blender/pulls/139082
Importing memory is done to often. when memory doens't change the
previous imported memory can be used.
The idea is to keep track of the last used buffer and keep reusing
it until the view/resolution has changed. This should not happen during
a session.
Pull Request: https://projects.blender.org/blender/blender/pulls/138984
This adds support for the extension and always
set the clip state value to 0..1 to align with vulkan
and metal. Moreover this is needed for the Reverse Z
implementation.
Note that this is a OpenGL 4.5 feature and is not
required to start Blender. So there must still be
a fallback path for now.
Rel #138898
Pull Request: https://projects.blender.org/blender/blender/pulls/138941
This commit finishes removing the uses of the integer to float
vertex buffer fetch mode. Previous commits noted below already started
that process. The last usage was geometry attributes. Now integers are
converted to floats as part of the existing upload process.
The change makes the Vulkan vertex buffer type conversion unused, so
it's removed. That's nice because Vulkan vertex buffers go from 1040 to
568 bytes in size and have significantly less overhead on creation.
Related:
- 153abc372e
- 1e1ac2bb9b
- 617858e453
Pull Request: https://projects.blender.org/blender/blender/pulls/138873
- Reduce artifacts during resizing to also recreate the swapchain
when acquire image is suboptimal
- Do not stretch when backbuffer and swapchain have a different size
Pull Request: https://projects.blender.org/blender/blender/pulls/138925
Always discard the context discard pile even when not submitted
When rendering animation it is not guaranteed that the submission
flag will ever be set.
The conversion from int to float is not supported natively
so it ends up happening beforehand on the CPU or as a
step before the vertex buffer can be used. It's better to just
upload floats in the first place.
Related to:
- 1e1ac2bb9b
- 617858e453
Pull Request: https://projects.blender.org/blender/blender/pulls/138855
These tests were hitting an assert about
invalid format. They were testing for this
legacy format we don't support anymore.
# Conflicts:
# source/blender/gpu/vulkan/tests/vk_data_conversion_test.cc
Caused by 617858e453.
These formats should use types aligned to 4 bytes. That's generally
required by modern GPUs. Uploading with these types also avoids
automatic conversion by the Vulkan backend which is something
we're hoping to remove fully.
In the end this PR removes a bunch of code related to supporting
the older single-byte formats.
Pull Request: https://projects.blender.org/blender/blender/pulls/138836
This unifies vertex and texture data formats
into a single base enum class.
`TextureFormat` and `VertexFormat` then mask
the invalid format for their respective usage.
Having a base enum allows casting between
`TextureFormat` and `VertexFormat` possible
(needed for Buffer Textures).
It also makes it easier to write and read data
to buffers/textures as each format will have an
associated host type.
These enum is generated from MACRO expansion.
This allow to centralize all information about
the formats in one place. This avoid duplicating
the list of enums for each backend.
This only creates the new enum. Porting older enums will
be done in other PRs.
Normalized integer CPU format are missing and waiting for #130640
Rel #130632
Pull Request: https://projects.blender.org/blender/blender/pulls/138069
Fixes a few render synchronization soundness issues I discovered when investigating
why resetting the pools after the submission fence in #137305 ended up causing #137395.
1. Ensure the number of submission fences in GHOST_ContextVK is the same
as the number of resource pools in VKThreadData. Otherwise, the
fences might get misaligned, making it difficult to predict which
submission a fence's signal corresponds to.
2. In swapBuffers, pass the current m_frame_data's fence and semaphores
to the Vulkan backend callbacks, rather than the following
m_frame_data. This fixes an observed soundness issue where the fences
were off-by-one. Now, the backend callbacks can be sure that both the
next frame is ready for construction (and it's resources can be
cleaned), and will use the correctly aligned fences and semaphores
during command buffer submission.
3. Do not recreate the m_frame_data's fences during recreateSwapchain.
This would lead to unsoundness immediately following
recreateSwapchain where all the fences are signaled but those frames
might still be in flight.
Pull Request: https://projects.blender.org/blender/blender/pulls/137580
When using motion blur GPU materials and its resources can be freed when
still in use. This fix adds a workaround to store these resources
temporarily in a render discard pile. When rendering is finished (or
between frames) the resources are moved to the regular discard pile.
Pull Request: https://projects.blender.org/blender/blender/pulls/138809
Due to an oversight in the pipeline pool/shader, pipelines that were
invalid (as subresources where destroyed) could still be selected for
reused. This happened more often when using the compositor as it
recreates shaders a lot. It also depended on how handles are reuses by
driver implementation.
This is fixed by discarded any associated pipeline when the pipeline
layout is discarded.
Pull Request: https://projects.blender.org/blender/blender/pulls/138800
Fix the recently implemented ShaderCompiler::batch_cancel.
Expose it with GPU_shader_batch_cancel and
GPU_shader_specialization_batch_cancel.
Use them in the EEVEE ShaderModule destructor, to prevent blocking on
destruction when there are in-flight compilations.
Pull Request: https://projects.blender.org/blender/blender/pulls/138774
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
