On the Vulkan side, ensure that unbound textures don't result in
accessing uninitialized or out of bounds memory.
On the Draw side, ensure all Hair and Curves attributes have, at least,
a dummy attribute bound.
Pull Request: https://projects.blender.org/blender/blender/pulls/142265
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
When running `make` it can happen that the target directory
was not created before the invocation of `glsl_preprocess`.
This patch copies #141404 and creates the output directory
before creating the output files.
This initial commit properly clamps handles for video/audio strips, and
provides functionality to enable/disable the behavior for all strip types
(addresses #90280).
Toggling handle clamping is done with "C",
just like with the redesigned slip operator (#137072).
If a strip is not already clamped when you start moving its handles,
then clamping behavior is disabled starting out. This means no abrupt
clamp until you explicitly ask for it.
Transform logic was altered, fixing a few bugs:
- When initializing a transform, `createTransSeqData` would already
create some clamping data for channels. This patch replaces it with
`offset_clamp` (for unconditional clamping which cannot be disabled)
and `handle_xmin/xmax` (for hold offset clamping, which is optional).
- Collecting this data ahead of time is necessary for the double
handle tweak case -- `flushTransSeq` only works one strip at a
time, so we can't clamp post-hoc.
- In `applySeqSlideValue`, we apply `transform_convert_sequencer_clamp`
before values are printed to the header, but let the unclamped values
get flushed to the strips themselves. This is so that we can have the
data later at the individual strip level to recalculate clamps.
Otherwise, if transform values are clamped preemptively, then we have
no idea whether strips are clamped vs. merely resting at their
boundaries.
Note that currently, handle clamping is drawn identically to overlaps.
More information in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/134319
This was caused by the Material Sub pass being
shared for all materials using a same texture.
This patch simply adds the sampler state inside the
Map key. This will create one unique subpass for each
texture and for each sampler state.
Pull Request: https://projects.blender.org/blender/blender/pulls/141978
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
This PR moves Wayland/HDR support out of experimental.
This allows more people to test and provide feedback. We
can always decide later to disable it for the release, but so
far we only got positive feedback.
Pull Request: https://projects.blender.org/blender/blender/pulls/141666
Windows/Intel GPU crashes when descriptor buffer cannot be allocated
anymore. This PR enables a workaround by not using descriptor buffers.
In future we should investigate how to improve the GC of descriptor
buffers and review the limits.
Pull Request: https://projects.blender.org/blender/blender/pulls/141600
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.
In case Blender was able to allocate a vertex buffer for huge geometry,
but isn't able to allocate its staging buffer it would crash. In this
case errors will be reported in the console.
This PR fixes this by clearing the data in stead of uploading.
Pull Request: https://projects.blender.org/blender/blender/pulls/141553
This was because the display shader never did the correct
color transformation.
This is a risky fix as it expects all input texture to be in
the correct colorspace (srgb). If they aren't this will
produce darker result.
If this is a huge issue we can introduce a global setting
(like line width) to set if the attached texture is
in srgb space or linear. This would avoid to change the
drawing code all over the place.
Pull Request: https://projects.blender.org/blender/blender/pulls/141237
Recently we switched from Depth24S8 to Depth32FS8. On OpenGL the read
back of depth was not working as it asked the driver to download both
the depth and stencil part of the texture. This isn't supported when using floats
and would not return any data.
This PR forces OpenGL to read back depth component when a depth/stencil
texture is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/141009
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.
This change enables HDR support for wayland as an experimental feature.
It supports both non-linear extended sRGB and un-clamped sRGB.
Windows isn't supported as the HDR settings are not accessible via an
API and would require similar settings that games use to configure the
monitor. Adding those sliders isn't what we would like to add.
Vulkan (working group) is working on new extensions that might change
the shortcomings. It isn't clear yet what the extension will do and what
the impact is for applications that want to use it. When the extension
is out we should review at the situation again.
Pull Request: https://projects.blender.org/blender/blender/pulls/133159
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
We detected that the gpu/draw tests could lead to
crashes after the tests where finished. It was
identified that the crash happened as the submission
runner wasn't exited, uses a mutex, that is being
destroyed by the main thread.
Solution is to wait until the submission runner has
finished, before destroying resources.
Pull Request: https://projects.blender.org/blender/blender/pulls/140650
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
In Blender 3.3 (1) the individual combine and separate color nodes were
combined together into a single combine/separate color node.
To ensure legacy addons still worked, the old nodes were left in
Blender, but hidden from the Add menus.
It has been nearly 3 years since that change was made, most if not all
addons should have been updated by now. So this commit removes these
hidden legacy nodes.
(1) blender/blender@82df48227b
Pull Request: https://projects.blender.org/blender/blender/pulls/135376
Depth navigation sends many small render graphs to the device. It can be
that a subsequent render graph uses the same shader as the previous one
with the same descriptor set tracker. The descriptor set tracker didn't
cleared its full state and a subsequent render graph was generating
commands assuming that the device was in a certain state.
However it wasn't and a command to bind a descriptor set was skipped
resulting in a device out of bound write. Depending on the platform this
could overwrite any data on the GPU, including shader programs as the
select shader writes to a storage buffer. This clarifies why the issue
resulted in very odd and none consistent behavior.
This PR fixes this by clearing the VKPipelineData and
VKDescriptorTracker.
Pull Request: https://projects.blender.org/blender/blender/pulls/140526
