Enable huge pages for jemalloc. This requests the Linux kernel to use
huge (2 MB) pages for large allocations. This has the effect of speeding
up first accesses to those allocations, and possibly also speeds up future
accesses by reducing TLB faults.
By default, 4 KB pages are used unless the user enables huge pages through
a kernel parameter or an obscure sysfs setting.
For Cycles benchmarks, this gives about a 5% CPU rendering performance
improvement. It likely also improves performance in other areas of Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/116663
For default GetWindowUnderCursor (when there is not a platform-specific
version), search windows in reverse order. This is because in most
cases with overlapping windows the one that is on top was created after
those that are below it.
Pull Request: https://projects.blender.org/blender/blender/pulls/111489
Caused by e968b4197b / 67e23b4b29
Since culprit commits, we are not running `MANTA::initGuiding` /
`fluid_alloc_guiding` if guiding is meant to be pulled from other
domains (it does work with effectors though). This is because atm. only
the `FLUID_DOMAIN_ACTIVE_GUIDE` flag sets `mUsingGuiding` to true
(activated in `update_obstacleflags`, so only for effectors).
So to fix this, we have to ensure that `MANTA::initGuiding` runs (also
if guiding is pulled from domains), but also make sure we dont run into
the crashes from T102257.
It seems that the real reason we were getting crashes in T102257 is that
67e23b4b29 made it so that resetting the cache (including a call to
`fluid_modifier_reset_ex`) in `fluid_modifier_processDomain` happens
**after** `FluidDomainSettings.active_fields` have been updated (this
happens in `update_flowsflags` & `update_obstacleflags`).
But `fluid_modifier_reset_ex` also resets
`FluidDomainSettings.active_fields`. If we then update pointers later in
`fluid_modifier_processDomain`, we never get anything in the guiding
related pointers for the new `mCurrentID` (specifically `mPhiGuideIn`
will be a nullptr). This is the real reason `initGuiding()` runs a
second time (it does once for `fluid_modifier_init` then again as a
consequence of the call to `manta_guiding`).
This patch proposes to move the resetting process from 67e23b4b29
**above** the refreshing of the `FluidDomainSettings.active_fields`,
this way these field stay intact, we do get the first run of
`initGuiding()` from `fluid_modifier_init`, manta pointers get updated
with intact fields afterwards (so we then get a valid `mPhiGuideIn`),
which then prevents the second run from `manta_guiding` to actually call
the python script again.
The fix from e968b4197b is then not needed and reverted in this patch.
This should be good for LTS I think.
Pull Request: https://projects.blender.org/blender/blender/pulls/117067
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Fixes an issue where CPU specific render settings (e.g. path guiding)
would be hidden when GPU Compute has been selected for rendering,
but a GPU hasn't been selected in preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/116123
In this case the object transform can use more motion steps, but the
geometry needs to have its motion steps fixed since the velocity
attribute completely overrides them.
There was one functional issue with the previous API which was its
use in `VolumeGrid<T>::grid_for_write(tree_token)`. The issue was
that the tree token had to be received before the grid is accessed.
However, this `grid_for_write` method might create a copy of the
`VolumeGridData` internally and if it does, the passed in `tree_token`
corresponds to the wrong tree.
The solution is to output the token as part of the method. This has two
additional benefits:
* The API is more safe, because one can't pass an r-value into the methods
anymore. This generally shouldn't be done, because the token should
live at least as long as the OpenVDB tree is used and shouldn't be freed
immediatly.
* The API is a bit simpler, because it's not necessary to call the
`VolumeGrid.tree_access_token()` method anymore.
Regression from [0] based on the incorrect assumption that X11's
Time was a uint64. Despite the `Time` type being 8 bytes,
the value wraps at UINT32_MAX.
Details:
- GHOST_SystemX11::m_start_time now uses CLOCK_MONOTONIC instead of
gettimeofday(..) since event times should always increase.
- Event timestamps now accumulate uint32 rollover.
[0]: efef709ec73ce95817a82e4e26cf7ec0bad8eca0
When a mesh light is shadow-linked to something with a specific
shader network it was possible that the emission_sd_storage was
not bit enough for sampling.
The shade_dedicate_light kernel only evaluates emission of either
light or mesh emitter and then resumes the regular path tracer.
There is no need to store closures.
This change makes it so a smaller storage is used, and also
passes flag to the shader evaluation function indicating that
closures are not to be stored.
Pull Request: https://projects.blender.org/blender/blender/pulls/116907
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
ROCm 6 brings some changes to the HIP API. This pull request is meant to be
backward and forward compatible.
That is Blender could be compiled with either ROCM 6 or 5 and run on either.
The main change is the hipMemoryType enum, which we check based on the
runtime version to use the correct enum values.
Without this, HIP will not work on Windows with upcoming 23.40 driver.
Pull Request: https://projects.blender.org/blender/blender/pulls/116713
The IES parser in Cycles would lead to heap buffer overflow error
when non-supported or invalid data is provided to it.
The error was caused by the way how stirng is copied to vector
skipping the last null-terminator. Later C-style string utilities
are used for parsing, and they expect the data to be null-terminated.
It is unclear why data needs to be stored as vector: storing it as
string simplifies initialization.
Easiest to reproduce the issue is to use Blender build with address
sanitizer enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/116752
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
The use-after-free is triggered when the GHOST system is created
multiple timers during the application timelife which happens in
the integration tests.
The solution is to release the application delegate and set it
to nil when the GHOST system is being destroyed. This ensures that
all subsequent GHOST systems properly initialize application
delegate, and that there is no application delegate which points
to a freed system.
The original issue was noticed by a flackey behavior of the
bf_gpu_tests test which was failing at random. The issue could
be reliably reproduced by running this test with ASAN enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/116717
Fix issues related to NaN normals in some situations by trying
to detect when these cases might occur and just reverting back
to default normals.
As a side effect of these changes, OSL now behaves correctly
when given a non-normalized normal.
Pull Request: https://projects.blender.org/blender/blender/pulls/114960
Fixes an issue where triangles (and possibly lights) would not be added
to the light tree if the only visibility option it has enabled is volumetric
scattering.
This would lead to an assert during forward sampling because the light
would be treated as if it was in the light tree, and a light index
outside the light tree array would be sampled, which would trigger
the assert.
Pull Request: https://projects.blender.org/blender/blender/pulls/116703
Using a non-null background brush does remove an initial white flash
while the program is loading and before we start painting. But this
results in some extra and unnecessary redraws. Default WM_ERASEBKGND
behaviour is to do nothing if this is brush is null, so if non-null we
get erased and must redraw. Suppressing WM_ERASEBKGND will not give us
that initial paint, so no benefit in keeping the brush added in #115968.
Pull Request: https://projects.blender.org/blender/blender/pulls/116642
There are some tragic design flaws with the Microsoft STL
implementation of `std::dequeue`. Unless we implement our
own similar data structure or use an implementation from
another library, the change isn't worth it.
This reverts commit b26cd6a4b9008836f9d764489b4aac5e143ad611.
This reverts commit cc11ba33d90e5a541e8263f7d365d6eeda9d984c.
This reverts commit c929d750541bc25131dec63c9c9e126a1370daf0.
This reverts commit bd3d5a750d2d0f5f72ed7ae262cd69abec4b0143.
Some common headers were including this. Separating the includes
will ideally lead to better conceptual separation between CustomData
and the attribute API too. Mostly the change is adding the file to
places where it was included indirectly before. But some code is
shuffled around to hopefully better places as well.
GSQueue dates back over 21 years, past the initial git commit. Nowadays
we generally prefer to use data structures from the C++ standard library
or our own C++ data structures. Previous commits replaced this container
with `std::queue` in a few areas. Now it is unused and can be removed.
Remove most includes of this header inside other headers, to remove unnecessary
indirect includes which can have a impact on compile times. In the future we may
want more dedicated "_fwd.hh" headers, but until then, this sticks with the
solution in existing code.
Unfortunately it isn't yet possible to remove the include from `BKE_geometry_set.hh`.
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
This refactors how volume grids are stored with the following new goals in mind:
* Get a **stand-alone volume grid** data structure that can be used by geometry nodes.
Previously, the `VolumeGrid` data structure was tightly coupled with the `Volume` data block.
* Support **implicit sharing of grids and trees**. Previously, it was possible to share data
when multiple `Volume` data blocks loaded grids from the same `.vdb` files but this was
not flexible enough.
* Get a safe API for **lazy-loading and unloading** of grids without requiring explicit calls
to some "load" function all the time.
* Get a safe API for **caching grids from files** that is not coupled to the `Volume` data block.
* Get a **tiered API** for different levels of `openvdb` involvement:
* No `OpenVDB`: Since `WITH_OPENVDB` is optional, it's helpful to have parts of the API that
still work in this case. This makes it possible to write high level code for volumes that does
not require `#ifdef WITH_OPENVDB` checks everywhere. This is in `BKE_volume_grid_fwd.hh`.
* Shallow `OpenVDB`: Code using this API requires `WITH_OPENVDB` checks. However, care
is taken to not include the expensive parts of `OpenVDB` and to use forward declarations as
much as possible. This is in `BKE_volume_grid.hh` and uses `openvdb_fwd.hh`.
* "Full" `OpenVDB`: This API requires more heavy `OpenVDB` includes. Fortunately, it turned
out to be not necessary for the common API. So this is only used for task specific APIs.
At the core of the new API is the `VolumeGridData` type. It's a wrapper around an
`openvdb::Grid` and adds some features on top like implicit sharing, lazy-loading and unloading.
Then there are `GVolumeGrid` and `VolumeGrid` which are containers for a volume grid.
Semantically, each `VolumeGrid` has its own independent grid, but this is cheap due to implicit
sharing. At highest level we currently have the `Volume` data-block which contains a list of
`VolumeGrid`.
```mermaid
flowchart LR
Volume --> VolumeGrid --> VolumeGridData --> openvdb::Grid
```
The loading of `.vdb` files is abstracted away behind the volume file cache API. This API makes
it easy to load and reuse entire files and individual grids from disk. It also supports caching
simplify levels for grids on disk.
An important new concept are the "tree access tokens". Whenever some code wants to work
with an openvdb tree, it has to retrieve an access token from the corresponding `VolumeGridData`.
This access token has to be kept alive for as long as the code works with the grid data. The same
token is valid for read and write access. The purpose of these access tokens is to make it possible
to detect when some code is currently working with the openvdb tree. This allows freeing it if it's
possible to reload it later on (e.g. from disk). It's possible to free a tree that is referenced by
multiple owners, but only no one is actively working with. In some sense, this is similar to the
existing `ImageUser` concept.
The most important new files to read are `BKE_volume_grid.hh` and `BKE_volume_grid_file_cache.hh`.
Most other changes are updates to existing code to use the new API.
Pull Request: https://projects.blender.org/blender/blender/pulls/116315
Use the standard "elements_num" naming, and use the "corner" name rather
than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`.
This matches the existing `faces_num` field which was already renamed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116350
With the popularity of dark themes, and the fact that our default theme
is dark, make the initial background color (before the program fully
loads) a darker shade of grey. {0.25f, 0.25f, 0.25f} versus current
{0.55f, 0.55f, 0.55f}. Also set Windows class background brush to the
same color to remove a potential flash.
Pull Request: https://projects.blender.org/blender/blender/pulls/115968
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.
- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)
If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.
I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116238
