There is no need to initialize index buffers with zero since such
buffers always have to be filled by the caller. This change replaces
the allocation with malloc, so that GPU_indexbuf_init results in an
uninitialized buffer. In debug, and with asan, the buffer will be still
filled by something, but the caller should initialize zero indices
manually instead of relying on a default value.
For example, sometimes the cost of zeroing on allocation is similar to
the cost of filling the buffer with actual data. For a point cloud with
1'000'000 points, octahedron topology update on each frame of simulation
takes:
| | Main | PR |
| -------------------------- | ------- | ------- |
| GPU_indexbuf_init | 2.75 ms | 5233 ns |
| pointcloud_extract_indices | 6.95 ms | 4.64 ms |
Pull Request: https://projects.blender.org/blender/blender/pulls/141110
In `pygpu_shader_attrs_info_get`, it tries to check information for all
vertex attributes that are added via `VERTEX_IN`, however some drivers
will optimize compiled shaders so some vertex attributes that are not
used will be removed. This fix makes sure that the input length that
is used in `GPU_shader_get_attribute_len` does not exceed actual max
binding number.
Pull Request: https://projects.blender.org/blender/blender/pulls/137584
The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
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.
The issue was that this operator is using the same
path as the viewport display. So the colors are
clamped if the display is not HDR.
This fix is easy now that we have an HDR path for
the viewport display. We just enforce using it
when doing the viewport render preview.
GPU_DATA_UINT_24_8 isn't used anymore. We cannot phase out the data type
as it can still be used by add-ons. This PR will deprecate
`GPU_DATA_UINT_24_8`. When used in an add-on a deprecation message will
be shown.
Pull Request: https://projects.blender.org/blender/blender/pulls/140715
Metal and AMD/Intel/Vulkan don't support depth24 texture formats
natively. The backends implemented fallback to use depth32f in
stead.
Recently we removed all usages of depth24 to use depth32 and the
next step is to remove the depth24 format and the workarounds in
the backend.
Note: The removal of `GPU_DATA_UINT_24_8` isn't part of this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/140659
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
The polyline workarounds were not working as expected
since #139627 as it was not garanteed that the polylines
shader would be correctly initialized with the workaround
tag.
Adding a wrapper class to ensure the initialization fixes
the issue.
This reduces the time needed to get to the first pixel
on screen by multithreading the builtin shader compilation.
We avoid doing this if subprocess compilation is on as
the overhead of potentially partially starting all subprocess
is far greater than the benefit of paralllel compilation.
For some reasons, the compilation is much slower when
done async for these shaders (on Metal ~200ms > ~1.2ms),
so the saving might not be substantial.
Mac M1: First frame 6s > 5s.
Pull Request: https://projects.blender.org/blender/blender/pulls/139627
The Extend Bounds input has no effect when the Fast Gaussian filter is
used. Similarly, it has no effect if the Bokeh Blur node is using
variable size. This is a known limitation and was just not implemented.
So to fix this, we implement a general solution that works globally
across the node by pre-padding the inputs of the blur. This uses more
memory but also speeds up the base case when Extend Bounds is disabled,
while also reducing the binary size due to fewer blur specializations.
The variable size Bokeh Blur test was updated since it Extend Bounds was
silently ignored.
Pull Request: https://projects.blender.org/blender/blender/pulls/140192
Prevent race conditions caused by calling `GPUWorker::wake_up` when the
worker is not waiting.
Found to be an issue in #139627, since `wake_up` is likely to be called
before the thread has fully started.
Pull Request: https://projects.blender.org/blender/blender/pulls/139842
This allows to generate source file that will
be injected in a predefined source dependance tree.
This allow much cleaner shader workflow where
all sources are explicitly referenced from the
main source file.
Pull Request: https://projects.blender.org/blender/blender/pulls/140047
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
This works by wrapping the entry point call inside a
`main` function.
Since resources are still defined in global space,
function accessing these are marked with a custom
attribute. This custom attribute expands in a
`#ifdef` guard for the matching stage.
This is a temporary solution and will eventually
be lifted once we support SRD.
### TODO
- [ ] Implement `[[gpu::vertex/fragment_function]]`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139233
This allows to reduce the waiting time caused by
shader compilation on some GPU-driver combo.
A new settings in the User Preferences make it
possible to override the default amount of worker
threads and optionally use subprocesses.
We still use only one worker thread in cases where
there is no benefit with adding more workers
(like AMD pro driver and Intel windows).
It doesn't scale as much as subprocesses for material
shader compilation but that is for other reasons
explained in #139818.
Add some heuristic to avoid too much memory usage
and / or too many stalls.
Also add some heuristic to the default number of subprocess for
the platform that shows scalling.
Historically, multithreaded compilation was prevented by the
need of context per thread inside `DRWShader` module.
Also there was no good scaling at that time. But
nowadays numbers shows different results with
good scaling with reasonable amount of threads on many
platforms.
Even if we are going for vulkan in the next release
most of the legacy hardware will still use OpenGL for
a few other releases. So it is relevant to make this
easy improvement.
See pull request for measurements.
Pull Request: https://projects.blender.org/blender/blender/pulls/139821
This has limited use cases since it doesn't
profile the heavy part of the vulkan backend.
Almost 1:1 port of the metal implementation from #139551.
Doesn't cover rendergraph submission nor GPU timings.
Pull Request: https://projects.blender.org/blender/blender/pulls/139899
When drawing image scope the vulkan backend raised some asserts. After
checking them the issue was in the calling code, that could lead to
undefined behavior on other platforms as well.
It isn't allowed to have an immediate mode shader bound, when performing
batch drawing. There was also a point batch that didn't use any point
shader resulting in undefined behavior as well.
For 5.0 we should add this as a GPU module check.
Pull Request: https://projects.blender.org/blender/blender/pulls/139926
Compilation constants are constants defined in the create info.
They cannot be changed after the shader is created.
It is a replacement to macros with added type safety.
Reuse most of the logic from Specialization constants.
Pull Request: https://projects.blender.org/blender/blender/pulls/139703
Allow adding compilation batches to different priority queues.
Set priorities so static shaders are always compiled first,
then materials, and optimized materials last.
Pull Request: https://projects.blender.org/blender/blender/pulls/139456
This PR adds builtin shaders for drawing points. Using `FLAT_COLOR`,
`SMOOTH_COLOR`, `UNIFORM_COLOR` can lead to undesired behavior
on Metal and Vulkan backends. To ensure future compatibility this PR
adds `POINT_FLAT_COLOR` and `POINT_UNIFORM_COLOR`.
The point size can be set using `gpu.state.point_size_set`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139583
The GPU implementation is a bit too complex
to implement for now.
As we are improving shader loading, having the
CPU timings is already helpful.
Note that `Map<size_t, int>` does not compile
on Clang.
This is exposing the `--profile-gpu` option on
all backends as the vulkan backend should follow
shortly.
Pull Request: https://projects.blender.org/blender/blender/pulls/139551
This PR adds a clear on creation for draw region framebuffers, which
fixes issue https://projects.blender.org/blender/blender/issues/139443.
When using the "Lock Interface" option, redrawing is disabled until the
rendering process has finished. When the GPU driver does not initialize
framebuffer textures with zero, this means that visual corruption can
be perceived when resizing the main window while rendering.
This fix makes sure that framebuffer textures are initialized with zero
on all GPU platforms.
Pull Request: https://projects.blender.org/blender/blender/pulls/139445
This patch adds a new Image Coordinates node for the compositor. The
Texture Coordinates and Pixel Coordinates outputs were removed from the
Image Info node and were added to the new node instead. Additionally, a
new Normalized Coordinates output was added.
The Pixel Coordinates output now no longer includes half pixel offsets.
Pull Request: https://projects.blender.org/blender/blender/pulls/138935
Cleanup and simplification of GPUMaterial and GPUPass compilation.
See #133674 for details/goals.
- Remove the `draw_manage_shader` thread.
Deferred compilation is now handled by the gpu::ShaderCompiler
through the batch compilation API.
Batch management is handled by the `GPUPassCache`.
- Simplify `GPUMaterial` status tracking so it just queries the
`GPUPass` status.
- Split the `GPUPass` and the `GPUCodegen` code.
- Replaced the (broken) `GPU_material_recalc_flag_get` with the new
`GPU_pass_compilation_timestamp`.
- Add the `GPU_pass_cache_wait_for_all` and
`GPU_shader_batch_wait_for_all`, and remove the busy waits from
EEVEE.
- Remove many unused functions, properties, includes...
Pull Request: https://projects.blender.org/blender/blender/pulls/135637
Add back the deprecated format to avoid asserts.
GPU backends should still have the code to support them.
Also add deprecation warnings as these types will be
removed for 5.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/139213
It can happen that the previous context drew with a different
colorspace. In the case where the new context is drawing with
the same shader that was previously bound (shader binding
optimization), the uniform would not be set again because the
dirty flag would not have been set (since the color space of
this new context never changed). The shader would reuse the same
colorspace as the previous context framebuffer (see #137855).
Fix#137855
Pull Request: https://projects.blender.org/blender/blender/pulls/139226
This caused UB in the tests now that tests are all ran
inside the same context.
A shader could be free but its pointer would be dangling
inside the `Context`. A new shader could have the same
address and generate UB after binding.
This is not the best way to solve this issue but at least
we prevent the use of the UB.
Pull Request: https://projects.blender.org/blender/blender/pulls/139109
This allows multiple threads to request different specializations without
locking usage of all specialized shaders program when a new specialization
is being compiled.
The specialization constants are bundled in a structure that is being
passed to the `Shader::bind()` method. The structure is owned by the
calling thread and only used by the `Shader::bind()`.
Only querying for the specialized shader (Map lookup) is locking the shader
usage.
The variant compilation is now also locking and ensured that
multiple thread trying to compile the same variant will never result
in race condition.
Note that this removes the `is_dirty` optimization. This can be added
back if this becomes a bottleneck in the future. Otherwise, the
performance impact is not noticeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/136991
