For Metal we can change the texture usage flags to get more optimal
behaviour - one example is adding the attachment flag so we can utilise
renders to do texture clears. However these usage flags are used as the
part of the match-criteria when trying to reuse released textures in
the texture pool.
The modifications means a request for the same type of texture will
fail causing a cache miss. When we render to an
image-view the texture pool is not released until the final sample has
been rendered as we consider the entire render to be a single frame
(as opposed to normal viewport rendering when we are presenting the
intermediate results).
This causes the texture pool to grow and grow and grow hence the large
memory usage. This fix splits the usage flags
into two sets, the internal ones we use to create the MTLTexture (which
we may modify) and the originally requested ones. The originally requested
ones are used for the texture pool matching.
This fix also improves memory efficiency for normal viewport rendering.
Mr Elephant Scene
Before -> After
Load scene in viewport: 13.04Gb -> 9.15 Gb
Viewport Render Image: 78.69Gb -> 16.61Gb
Authored by Apple: James McCarthy
Pull Request: https://projects.blender.org/blender/blender/pulls/129951
Brushes and changes done to them are preserved now when loading
different files (until Blender closes). Unpin and clear the material
assigned to the brush when loading a different file, since this material
is local to the previous file.
Pull Request: https://projects.blender.org/blender/blender/pulls/128080
GPv3 Undo loading code would not clear the active node pointer, leaving
it to point to an invalid (freed) memory, in case there is no active
node in the loaded undo step.
Pull Request: https://projects.blender.org/blender/blender/pulls/129918
Code detecting unused drawings and swapping them with a used one would
fail in a most basic case, leading to invalid state down the line:
```
[used_drawing, unused_drawing]
```
`unused_drawing` was not properly removed, as it is expected.
NOTE: Added an extra assert on (presumably) expected conditions of the
drawing indices and drawings array at the end of the process.
Co-authored-by: Lukas Tönne <lukas@blender.org>
Catch any exception from the JSON parser and handle it by returning a
null value from the deserialization function. Let the asset indexer
regenerate the index file to handle the error.
At least for the asset index case we don't care about the exact parsing
error, so this simple error handling strategy is fine. Should more
precise error reporting be necessary for other use-cases this can be
added still, but I think these errors are usually a bit too low level to
expose to users.
Pull Request: https://projects.blender.org/blender/blender/pulls/129879
When the light volume probe cannot be allocated a pool of a different
size is used. A message is displayed to the user. This PR improves the
message by adding the previous size as well.
Ref #129889
Pull Request: https://projects.blender.org/blender/blender/pulls/129963
Similar to other bugs caused by ada367a0e9 (e.g.
ff9de2f7da9dcec96692355a67a7e7e280c223a7), the issue is that the object is
tagged for changes before retrieving its evaluated state.
I can't say I fully understand the all the code path for the object conversion
already. However, the change seems to make sense based on the `/* other users
*/` comment right above the change. Also, the selected object is tagged again
further down in my test anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/129948
When running test cases
`test_texture_roundtrip__GPU_DATA_10_11_11_REV__GPU_R11F_G11F_B10F`
would read and write outside of allocated memory. This is an error in
the test case itself the GPU API doesn't have a public function to get
the desired byte and component size.
Pull Request: https://projects.blender.org/blender/blender/pulls/129958
Similar to other bugs caused by ada367a0e9 (e.g.
ff9de2f7da9dcec96692355a67a7e7e280c223a7), the issue is that the object is
tagged for changes before retrieving its evaluated state.
I can't say I fully understand the all the code path for the object conversion
already. However, the change seems to make sense based on the `/* other users
*/` comment right above the change. Also, the selected object is tagged again
further down in my test anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/129948
The `GreasePencil::update_drawing_users_for_layer` function was using an
incorrect drawing index check, skipping over drawing 0 every time.
As a consequence the first drawing may have zero users despite at least
one frame referencing it.
Pull Request: https://projects.blender.org/blender/blender/pulls/129955
When reporting "could not create instance of {class} to call callback
function {function}", put single quotes around the name of the function.
This will make it easier to understand that that word is actually a
function name, and not some verb in the sentence.
Before:
> RuntimeError: could not create instance of
> AMP_TIMELINE_TOOLS_OT_anim_lattice to call callback function execute
After:
> RuntimeError: could not create instance of
> AMP_TIMELINE_TOOLS_OT_anim_lattice to call callback function 'execute'
Pull Request: https://projects.blender.org/blender/blender/pulls/129780
First this make the wire batch use the same set of drawing that the main
gpencil batch uses (as they share the same VBO data, they need to use
the same drawings).
Then we skip drawing the onion frames by nullifying the indices in the
index buffer. A better way would be to skip these strokes or drawing
but that can be done later and seems more bug prone.
Pull Request: https://projects.blender.org/blender/blender/pulls/129920
The issue was that the masks for the current frame would be
rendered for a different frame.
Unfortunately, we can't easily render masks for the onion
skinned frames correctly at the moment.
The fix makes it so that we render the mask only for the current frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/129878
Possibly due to c13cde24cc
This commit clamps the `brush->size` value to 1 at lowest for the
Grease Pencil Draw mode. There are situations where when the brush scene
space value is set to a small enough size that the distance calculated
by `project_brush_radius` becomes 0.
When this value is set as the actual brush size, the `wm.radial_control`
operator fails to work properly as the new size is now lower than the
expected minimum value, causing incorrect clamping of the modal value.
Pull Request: https://projects.blender.org/blender/blender/pulls/129937
Possibly due to c13cde24cc
This commit clamps the `brush->size` value to 1 at lowest for the
Grease Pencil Draw mode. There are situations where when the brush scene
space value is set to a small enough size that the distance calculated
by `project_brush_radius` becomes 0.
When this value is set as the actual brush size, the `wm.radial_control`
operator fails to work properly as the new size is now lower than the
expected minimum value, causing incorrect clamping of the modal value.
Pull Request: https://projects.blender.org/blender/blender/pulls/129937
Drivers should perform a limit check when creating images and return
`VK_ERROR_OUT_OF_DEVICE_MEMORY`. However there are drivers where this
check is a pass-through and leads to `VK_ERROR_DEVICE_LOST`.
This issue was introduced !128877 and only shows up on official NVIDIA
drivers.
Pull Request: https://projects.blender.org/blender/blender/pulls/129939
There is an issue in the GPU depth picking that is only visible
in official AMD/NVIDIA drivers. AMD does pick objects that are
around the cursor. NVIDIA drivers include any overlay objects.
This PR will disable GPU pick selection for AMD/NVIDIA official
drivers. This will limit some selection functionality.
This PR will be reverted in Blender 4.4 to find the root cause.
Ref: #128624, #127768
Pull Request: https://projects.blender.org/blender/blender/pulls/129863
When using a lot of instances the requested and needed attributes
are merged. This process uses a lock even when no work needs to be
done.
By early exiting the merging process when no work needs to be done
the performance of navigating 60k cubes went from 17.5 fps to 18.3 fps.
Detected when researching #126391.
Pull Request: https://projects.blender.org/blender/blender/pulls/129791
