The root cause is still unknown. But replacing the
use of the depth texture by the hiz buffer fixes the
issue.
The issue was apparent on Linux + Mesa + AMD.
* For materials with UDIM tiles support, get array and mapping in one call
* For viewers that can use render results, add a dedicated function
* Fix potential use of render results in stencil overlay and grease pencil
Pull Request: https://projects.blender.org/blender/blender/pulls/117563
`GLBatch::draw_indirect` has additional overhead compared to
`GLBatch::draw`, and can become a bottleneck in scenes that require
many draw calls (ie. with too many unique meshes).
The performance difference is almost exclusively caused by the
`GL_COMMAND_BARRIER_BIT` barrier that happens on every call.
This PR adds a `GPU_storagebuf_sync_as_indirect_buffer` function that
can be used to place the barrier only once after filling the indirect
buffer content.
This function is a no-op in Vulkan and Metal since they don't need the
barrier.
Pull Request: https://projects.blender.org/blender/blender/pulls/117561
The test uses a none points shader to draw points, which is incorrect
and asserts when using Vulkan. It also didn't test the gpu part of the
pipeline (PassMain).
When using PassMain the order of the resources are expected to be
different as the draw calls are ordered based on the primitive type and
handles.
Pull Request: https://projects.blender.org/blender/blender/pulls/117714
When drawing curves or particle hair, the hair is refined using GPU
shaders. See eParticleRefineShaderType. OpenGL since Blender 4.0
always uses compute shaders. Metal since Blender 4.1 always uses
compute shaders. Vulkan will only uses compute shaders.
The transform feedback isn't used and not supported by our vulkan backend.
Transform feedback workaround was a Apple specific solution as they didn't
support transform feedback. Metal didn't use Compute shaders in
EEVEE-Legacy for performance reasons. Since EEVEE-Next/Workbench-Next
Metal uses compute shaders.
Fixes: #117497
Pull Request: https://projects.blender.org/blender/blender/pulls/117507
Remove transparency weight from other closure weights.
Since closure weights take transparency into account,
scaling closure colors by their weight applies alpha pre-multiplication to them,
causing dithered transparency materials to be darker than they should be.
Pull Request: https://projects.blender.org/blender/blender/pulls/117675
This avoid the following error
`Unknown NIR alu instr: div 32 %17 = ineg %16`
This is a debug shader so cost isn't important.
A bug report will be done upstream.
Part of overall "improve filtering situation" (#116980): replace Subsampled3x3
(added for blender 3.5 in f210842a72 et al.) strip scaling filter with a
general Box filter.
Subsampled3x3 is really a Box filter ("average pixel values over NxM region"),
hardcoded to 3x3 size. As such, it works pretty well when downscaling images by
3x on each axis. But starts to break down and introduce aliasing at other
scaling factors. Also when scaling up or scaling down by less than 3x, using
total of 9 samples is a bit of overkill and hurts performance.
So instead, calculate the amount of NxM samples needed by looking at scaling
factors on X/Y axes. Note: use at least 2 samples on each axis, so that when
rotation is present, the result edges will get some anti-aliasing, just like it
was happening in previous filter implementation.
Images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117584
The problem was that `grease_pencil_edit_batch_ensure` would not return early if the buffers already exist, meaning that multiple buffers could be create but only the last ones would be freed.
Pull Request: https://projects.blender.org/blender/blender/pulls/117580
Fixes issue where motion blur would not display for
certain objects intermittently due to uninitialized
parameters in the ObjectKey struct causing the
motion object map look-up to fail and for motion
parameters to be reset to default, disabling the
effect for the given objects.
Authored by Apple: Michael Parkin-White
Co-authored-by: Michael Parkin-White <mparkinwhite@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/117560
EEVEE uses an HiZ buffer. The size of the HiZ buffer is based on the render extent.
Probes assume that the render extent is always bigger than needed for rendering
probes. This assumption is incorrect.
Although this PR fixes this by allocating the required size, it is still renders with
artifacts. These artifacts originate from the lighting module and also needs to be
fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/117502
There exist a bunch of "give me a (filtered) image pixel at this location"
functions, some with duplicated functionality, some with almost the same but
not quite, some that look similar but behave slightly differently, etc.
Some of them were in BLI, some were in ImBuf.
This commit tries to improve the situation by:
* Adding low level interpolation functions to `BLI_math_interp.hh`
- With documentation on their behavior,
- And with more unit tests.
* At `ImBuf` level, there are only convenience inline wrappers to the above BLI
functions (split off into a separate header `IMB_interp.hh`). However, since
these wrappers are inline, some things get a tiny bit faster as a side
effect. E.g. VSE image strip, scaling to 4K resolution (Windows/Ryzen5950X):
- Nearest filter: 2.33 -> 1.94ms
- Bilinear filter: 5.83 -> 5.69ms
- Subsampled3x3 filter: 28.6 -> 22.4ms
Details on the functions:
- All of them have `_byte` and `_fl` suffixes.
- They exist in 4-channel byte (uchar4) and float (float4), as well as
explicitly passed amount of channels for other float images.
- New functions in BLI `blender::math` namespace:
- `interpolate_nearest`
- `interpolate_bilinear`
- `interpolate_bilinear_wrap`. Note that unlike previous "wrap" function,
this one no longer requires the caller to do their own wrapping.
- `interpolate_cubic_bspline`. Previous similar function was called just
"bicubic" which could mean many different things.
- Same functions exist in `IMB_interp.hh`, they are just convenience that takes
ImBuf and uses data pointer, width, height from that.
Other bits:
- Renamed `mod_f_positive` to `floored_fmod` (better matches `safe_floored_modf`
and `floored_modulo` that exist elsewhere), made it branchless and added more
unit tests.
- `interpolate_bilinear_wrap_fl` no longer clamps result to 0..1 range. Instead,
moved the clamp to be outside of the call in `paint_image_proj.cc` and
`paint_utils.cc`. Though the need for clamping in there is also questionable.
Pull Request: https://projects.blender.org/blender/blender/pulls/117387
Remove divergent code paths for hair refinement. Metal
previously opted for transform-feedback based hair
refinement due to improved performance, but best
to utilise the same compute path with new engines in
mind.
Separate PRs can be made to optimize the compute
path.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/117477
The fix in the logic is similar to 5875349390. It's needed
because we now skip computing face corner (BMLoop) normals when the
BMesh is completely flat shaded. It might be completely flat shaded
just because of edge smoothness though, which wasn't taken into
account before.
This simplifies code using these functions because of RAII,
range based for loops, and the lack of output arguments.
Also pass object pointer array as a span in more cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/117482
This PR renames the UI names of EEVEE render engines, due to the decision to
postpone EEVEE-Next to Blender 4.2.
* `EEVEE` is now named `EEVEE-Next`.
* `EEVEE (Legacy)` is now named `EEVEE`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117437
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
