This change migrates the first 2 subdiv shaders to use the ShaderCreateInfo.
Other shaders will follow in separate PRs.
- Should compile when using `WITH_GPU_SHADER_CPP_COMPILATION`
- A `subdiv_` prefix is added only to the functions related to `PosNorLoop`.
But eventually the prefix should also be added to other lib functions.
- Due to Metal restrictions `subdiv_set_vertex_*` is implemented using a
functional paradigma. Our Metal backend only supports `inout` qualifier
on thead local data structures.
Pull Request: https://projects.blender.org/blender/blender/pulls/134218
EEVEE crashes when it is not able to allocate buffers. Previously we had a
message showing to the user that it tries to allocate a texture larger than
supported by the GPU. But was not implemented for EEVEE-next. This fix will
add back this error message.
Pull Request: https://projects.blender.org/blender/blender/pulls/134725
The main goal of these changes are to improve static (i.e. build-time)
checks on whether a given data can be allocated and freed with `malloc`
and `free` (C-style), or requires proper C++-style construction and
destruction (`new` and `delete`).
* Add new `MEM_malloc_arrayN_aligned` API.
* Make `MEM_freeN` a template function in C++, which does static assert on
type triviality.
* Add `MEM_SAFE_DELETE`, similar to `MEM_SAFE_FREE` but calling
`MEM_delete`.
The changes to `MEM_freeN` was painful and useful, as it allowed to fix a bunch
of invalid calls in existing codebase already.
It also highlighted a fair amount of places where it is called to free incomplete
type pointers, which is likely a sign of badly designed code (there should
rather be an API to destroy and free these data then, if the data type is not fully
publicly exposed). For now, these are 'worked around' by explicitly casting the
freed pointers to `void *` in these cases - which also makes them easy to search for.
Some of these will be addressed separately (see blender/blender!134765).
Finally, MSVC seems to consider structs defining new/delete operators (e.g. by
using the `MEM_CXX_CLASS_ALLOC_FUNCS` macro) as non-trivial. This does not
seem to follow the definition of type triviality, so for now static type checking in
`MEM_freeN` has been disabled for Windows. We'll likely have to do the same
with type-safe `MEM_[cm]allocN` API being worked on in blender/blender!134771
Based on ideas from Brecht in blender/blender!134452
Pull Request: https://projects.blender.org/blender/blender/pulls/134463
With the brush assets project, brushes were moved from being local to
the working blendfile to being linked from asset libraries. This breaks
the Image Paint 'Clone' brush, as it has a brush property that links to
other Image datablocks.
To support this functionality, this commit adds the corresponding
properties into the `ImagePaintSettings` struct so that it is stored
locally with the images that will be used by the tool, inside the main
blendfile.
The source image property is shared with the 3D version of the 'Clone'
brush instead of adding a separate field to preserve old behavior.
Notably, this has the following limitations:
* If clone brush assets have been made and shared with external packs,
they would not work out of the box with linked image assets.
* Despite these settings being stored on the scene, they are populated
inside the tool window under "Brush Settings" which is potentially
misleading. However, this is already the case for the 3D version of
the brush, so further UI refinement will happen outside of this PR.
* Users will be unable to use separate images simultaneously for the
Image editor and the 3D viewport, unlike in pre-4.3 versions. This
can be adjusted in the future if it is a critical workflow.
Because the intended design and functionality of this tool is currently
questionable, this commit opts to make these changes instead of doing
further design to support both accessing data on the brush and on the
scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/134474
Though "Point Cloud" written as two words is technically correct and should be used in the UI, as one word it's typically easier to write and parse when reading. We had a mix of both before this patch, so better to unify this as well.
This commit also renames the editor/intern/ files to remove pointcloud_ prefix.
point_cloud was only preserved on the user facing strings:
* is_type_point_cloud
* use_new_point_cloud_type
Pull Request: https://projects.blender.org/blender/blender/pulls/134803
Restriction of the nodes api to clearly define never-null function arguments.
Side effects: some assertions and null-check (with early return) were removed.
On the caller side is ensured to never derefer null to pass argument (mainly in RNA).
In addition, one pointer argument now actually a return type.
By-reference return types instead of pointers going to be separate kind of
change since also imply of cleaning up variables created from reference.
Also good future improvement would be to mark a copy-constructor as
explicit for DNA node types.
Pull Request: https://projects.blender.org/blender/blender/pulls/134627
Add a `--profile-gpu` launch argument.
When set, it generates a profile in the Trace Event Format with CPU and
GPU metrics based on GPU debug scopes.
https://profilerpedia.markhansen.co.nz/formats/trace-event-format/
The profiles are best viewed at https://ui.perfetto.dev/
Notes:
- The profiler captures everything form app start to exit.
- Being JSON based the profiles can become relatively large, but they
compress very well.
- Only OpenGL profiling is supported for now, but the report formatting
code can be shared across backends.
Pull Request: https://projects.blender.org/blender/blender/pulls/133557
Previously we generally expected CustomData layers to have implicit
sharing info, but we didn't require it. This PR clarifies that we do
require layers with non-null data to have implicit sharing info. This
generally makes code simpler because we don't have to have a separate
code path for non-shared layers. For example, it makes the "totelem"
arguments for layer freeing functions unnecessary, since shared data
knows how to free itself. Those arguments are removed in this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/134578
All 2D vectors related to image transform code were changed to float2.
Previously, it was decided, that 4x4 matrix should be used for 2D
affine transform, but this is changed to 3x3 now.
Texture painting code did rely on `IMB_transform` with 4x4 matrix.
To avoid large changes, I have added function
`BLI_rctf_transform_calc_m3_pivot_min`.
Main motivation is cleaner code - ease of use of c++ API, and avoiding
returning values by arguments.
Pull Request: https://projects.blender.org/blender/blender/pulls/133692
Avoid calling `GPU_indexbuf_add_line_verts` and the triangle
version of that function. It's faster to avoid function calls and
just write to the data arrays directly. I did some very rough tests
and observed about a 10% improvement in runtime for the
entire index buffer creation process.
This is due to hardcoded color and subdivision value. Also scale and
offset properties stored in overlay stuct was not considered. Now
multiply the transform matrix with `grid_mat` to make use of these
properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/134382
This patch removes the compositor texture pool implementation which
relies on the DRW texture pool, and replaces it with the new texture
pool implementation from the GPU module.
Since the GPU module texture pool does not rely on the global DST, we
can use it for both the viewport compositor engine and the GPU
compositor, so the virtual texture pool implementation is removed and
the GPU texture pool is used directly.
The viewport compositor engine does not need to reset the pool because
that is done by the draw manager. But the GPU compositor needs to reset
the pool every evaluation. The pool is deleted directly after rendering
using the render pipeline or through RE_FreeUnusedGPUResources for the
interactive compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/134437
In certain setups where passes are used in the viewport compositor,
blender will crash. This happens because passes may not be available
when the compositor first run but then become available in later runs.
Possibly because EEVEE is still compiling shaders. This is problematic
for the compositor because it caches the result of node tree compilation
for the specific data available, like passes, and the compositor does
not get informed when data becomes available like in the case of EEVEE
to invalidate the cached node tree compilation result.
Caching of node tree compilation was always a source of bugs but we
managed to workaround them in the past, so before we work on a fix for
this crash, we first evaluate the removal of caching to see if we can
live without it. Especially since a fix will be rather involved for the
release branch at this stage.
The time it takes to compile the node tree is:
- Small Tree (~10 nodes): 0.3ms.
- Medium Tree (~50 nodes): 0.6ms.
- Huge Tree (~300 nodes): 3ms.
The difference is not noticeable to the eye, probably since as the tree
becomes bigger, the evaluation time becomes more dominant, and small
trees are fast to compile.
It should be noted that we intended to remove caching in the future to
support things like lazy evaluation of node inputs, but we though a few
optimization needs to be done on the GPUMaterial compiler side to make
compilation faster, since it is the main bottleneck during compilation.
So considering this, I think it is acceptable to disable caching of node
tree compilations for the time being. I intend to optimize it such that
it always becomes less than 1ms, but we will have to delay that to 4.5.
Pull Request: https://projects.blender.org/blender/blender/pulls/134394
