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
The feature to display multiple objects in the UV and Image Editor was
added in 24d08e0bae.
This commit did not account the multi-edit mode feature, where there may
be more than one object currently being edited, causing some UVs to
display with a faded opacity.
To fix this, introduce a new `eObjectInfoFlag` flag to indicate this
state, populate it when syncing the object, and use the flag inside the
relevant shaders.
Pull Request: https://projects.blender.org/blender/blender/pulls/141254
Reading from the top-right of the selection buffer could read
past the buffer bounds. Resolve by ensuring the clamped buffer
isn't empty. Relates to #141591.
As noted in [0], locking or atomics are not required for merging
requests for a single mesh, because there is no multithreaded iteration
over objects that will process the same mesh in multiple threads. This
locking was added preemptively over the years and has made code
needlessly complicated, even while the final design for parallel object
iteration isn't completely clear. This PR removes the locks to simplify
some changes necessary for mesh attribute storage refactors.
[0]: b6764e77ef
Pull Request: https://projects.blender.org/blender/blender/pulls/141405
Change `eCustomDataType` to `bke::AttrType` for uses of the attribute
API (the `AttributeAccessor` one anyway). I didn't touch any values that
might be saved in files; those should be handled on a case by case basis.
Part of #122398
Pull Request: https://projects.blender.org/blender/blender/pulls/141301
This commit moves Curves and Grease Pencil to use `AttributeStorage`
instead of `CustomData`, except for vertex groups. This PR mostly
involves extending the changes from the above commit for point clouds
to generalize to other geometry types.
This is mostly straightforward, though a couple non-trivial places of
note are the joining of Grease Pencil objects (`merge_attributes`), the
"default render fallback" UV for curves objects which was previously
unused at the UI level and just ended up being the first attribute, and
the `update_curve_types()` call in the curves versioning function.
Similar to:
- fa03c53d4a
- f74e304b00
Part of #122398.
Pull Request: https://projects.blender.org/blender/blender/pulls/140936
The crash seems to come from libepoxy GL functions pointing to null.
It seems that libepoxy "Automatically initializes as new GL functions are used."
and that to call a function without a GL context bound, the function
must have been called before with a bound context.
This just modifies the scope of the context binding from
DRW_module_exit to RE_engines_exit, which seems the safest solution
for 4.5.
Pull Request: https://projects.blender.org/blender/blender/pulls/141233
For some reason the orco vertex buffer is requested after the position
buffer, but they are computed together. In case that happens, just
discard the position buffer.
Pull Request: https://projects.blender.org/blender/blender/pulls/141043
This avoid legacy code inside the DRWContext.
Note that this change the draw order w.r.t. gizmos. Now the
gizmos will hide the text.
Moreover, streamline the condition for enabling text drawing
in order to fix#78971.
Prepare for #140378 by replacing all uses of `ResourceHandle` inside
the engine code with `ResourceHandleRange`.
Aside from the replacement, this changes `ResourceHandleRange` itself
to ensure we use them correctly:
- Prevent direct access to the first handle, to avoid not taking ranges
into account by mistake.
- Add missing functions that are safe to use for ranges
(`has_inverted_handedness` and `is_valid`).
- Add functions that aren't safe to use for ranges, but are required
for the code paths that don't support them yet (these functions assert
that the range points to a single handle, and therefore can be used
safely).
The main change is in `draw_handle.hh`, everything else is just a 1:1
port to use these new functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/140611
One obvious problem is that `mr.use_simplify_normals` was assigned after
face corner normals were retrieved. The other more complex problem is
that now the normals caches automatically mix custom normals from other
domains. This can cause the expensive "Tangent Space" normals to be
calculated even though we don't explicitly request face corner normals.
To fix this, clarify the purpose of the option to only apply to that custom
normals format and use the true normals instead in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140879
Avoid 4 function calls and computing the min and max index for every
triangle. Instead just fill the index buffer data directly. For me this
gives a 6% FPS playback improvement in the 4.3 splash screen file.
Pull Request: https://projects.blender.org/blender/blender/pulls/140684
Blender uses depth24 for legacy reasons. All backends that we support
have support for depth32f.
This PR updates all usages of depth24 with depth32f.
- depth24 are not supported on AMD/Intel/Vulkan and Metal. There depth32f
was already used to work around this limitation.
- This allows us to implement reverse depth in workbench, overlay and
grease pencil in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/140531
This was caused by a hash colision caused by an incorrect
auto conversion from `Object*` to `ObjectRef`. The `ObjectRef`
would then not contain any instancing data and would create
the same hash for the same particle system on each instance
(since only `foreach_hair_particle_handle` was constructing
`ObjectKey` from an `Object*` it did not affect the instance
itself).
Marking the incriminating constructor `explicit` to avoid
more issues. Changing the `ObjectKey` creation for psys to use
`ObjectRef` fixes the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/140544
Some functions used at least once per object/instance
when drawing are so trivial that function call overhead
becomes significant. Allowing these functions to be
inlined can remove that overhead and also give the
compiler more information it can use for optimization.
In the Erindale Flower Shop file, this change gives me
a 10% improvement in playback FPS, from 8.77 to 9.65.
Pull Request: https://projects.blender.org/blender/blender/pulls/140402
From 4b4ed8bccc
The vert to loop map is unnecessary here, we don't need information
about neighboring faces. This was just incorrectly copied from older
code where this data was mixed with normal evaluation.
Remove the last uses of `BKE_boundbox_init_from_minmax` in
favor of the newer `bounds::corners`. Besides clearer naming
and better ergonomics, it's also inline-able which seems to be a
good thing for such a simple function.
In order to get the same behavior as before I changed the
C++ bounds function to give the same vertex order as the
older function.
Pull Request: https://projects.blender.org/blender/blender/pulls/140401
For paint modes the selection and visibility were encoded in in the W
component of the normals. Separating the normals into a separate vertex
buffer, though it increases memory usage a bit in those paint modes,
means the status doesn't need to be computed outside of paint modes,
and the whole system becomes less convoluted and easier to optimize.
The particular optimization I have in mind is better caching of vertex
buffers, which gets much more complicated when the normals VBO contains
data like selection and visibility and depends on the paint mode.
Internally, a there are now three mesh draw batches that are specific to
the paint overlay. The GPU subdivision normals buffer is now just three
components rather than 4 components.
Pull Request: https://projects.blender.org/blender/blender/pulls/140156
This assert added by 321ec72c74 notes that changing the mesh
wrapper type from subdivision to normal mesh data just discards the
potentially-subdivided geometry and doesn't make sense, and possibly
breaks other assumptions.
This wrapper type change was done years ago by 0f89bcdbeb to
fix issues with shared object data during evaluation. It noted that
the mesh drawing data extraction didn't handle BMesh wrappers correctly
when the object isn't in edit mode, but that doesn't seem to be the
case after two trivial changes. The other bugs mentioned by that commit
are still solved after this change.
Pull Request: https://projects.blender.org/blender/blender/pulls/140290
Some refactors (!140156) require adding a few more batches,
but we're already at the limit for how many we can add. This
commit makes the batch flag into a 64 bit integer. It might be
worth refactoring this more to use some system besides a flag,
but for now this simple change is best.
The atomic combination of requests wasn't actually required
and isn't supported for 64 bit integers, so it's just removed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/140164
Fixed by not doing async loading and always stage correct
texture reference.
Unfortunately the code is getting a bit messy since the
texture loading is not done at the GPUMaterial level.
So we need one async and one synchronous path inside
`PassBase<T>::material_set`.
`ImageGPUTextures` now contains references to the location
of the future `GPUTexture *`.
Also fix#140001
Pull Request: https://projects.blender.org/blender/blender/pulls/140203
This is part of the short term roadmap goal of simplifying the
compositor workflow
(see https://projects.blender.org/blender/blender/issues/134214).
The problem is that many users don't know how to get started with
compositing in Blender, even when they have used Blender for other
areas, e.g. modeling.
Note: although the solution makes compositor node trees reusable
accross blend files, this is a nice side effect and not the main goal
of the PR.
This PR implements a "New" button that creates a new compositing node
tree, and manages trees as IDs. This has following advantages:
- Consistent with other node editors and other parts of Blender,
therefore making it easier to getting started with compositing if users
are familiar with shading or geometry nodes
- Give users the ability to reuse the compositing node tree by linking
or appending it.
Note: The parameter "Use Nodes" is still present in this PR, but will
be removed (in a backward compatible way) in a follow up PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135223
This prevents the use of unaligned data types in
vertex formats. These formats are not supported on many
platform.
This simplify the `GPUVertexFormat` class a lot as
we do not need packing shenanigans anymore and just
compute the vertex stride.
The old enums are kept for progressive porting of the
backends and user code.
This will break compatibility with python addons.
TODO:
- [x] Deprecation warning for PyGPU (4.5)
- [x] Deprecate matrix attributes
- [x] Error handling for PyGPU (5.0)
- [x] Backends
- [x] Metal
- [x] OpenGL
- [x] Vulkan
Pull Request: https://projects.blender.org/blender/blender/pulls/138846
