When using vec3[] as push constants it selected the incorrect
branch resulting in uploading incorrect data to the shader.
This resulted in not seeing the clipping bounds in vulkan.
Ref: #131111
Since the introduction of storage buffers in Blender, the calling
code has been responsible for ensuring the buffer meets allocation
requirements. All backends require the allocation size to be divisible
by 16 bytes. Until now, this was sufficient, but with GPU subdivision
changes, an external library must also adhere to these requirements.
For OpenSubdiv (OSD), some buffers are not 16-byte aligned, leading
to potential misallocation. Currently, this is mitigated by allocating
a few extra bytes, but this approach has the drawback of potentially
reading unintended bytes beyond the source buffer.
This PR adopts a similar approach to vertex buffers: the backend handles
extra byte allocation while ensuring data uploads and downloads function
correctly without requiring those additional bytes.
No changes were needed for Metal, as its allocation size is already
aligned to 256 bytes.
**Alternative solutions considered**:
- Copying the CPU buffer to a larger buffer when needed (performance impact).
- Modifying OSD buffers to allocate extra space (requires changes to an external library).
- Implementing GPU_storagebuf_update_sub.
Ref #135873
Pull Request: https://projects.blender.org/blender/blender/pulls/135716
This patch refactors how single values are passed to MF operations by
utilizing generic pointers. This avoids boilerplate and makes it easier
to add new types.
Allow extending the DRWState on select_bind so backface culling can be used when needed.
Note: There's still a difference in behavior with Overlay Legacy, causing backface culled flat objects to still be selectable at the edges, due to the "MeshFlat" workaround.
Pull Request: https://projects.blender.org/blender/blender/pulls/135867
Resolves several int -> uint conversion warnings. Warnings like the
following will be printed otherwise:
```
|
225 | uint shadow_type = flags & 0xF;
| ^
| gpu_shader_text_vert.glsl:17:22: Warning: some implementations
may not support implicit int -> uint conversions for `&'
operators; consider casting explicitly for portability
```
Pull Request: https://projects.blender.org/blender/blender/pulls/135890
The patch strings did not have thread safe initialization.
The string might hav been returned null or incomplete
which might trigger compilation errors.
This patch provides const variants to the cpu_data accessors that
returns GSpan. This is done to better const correctness. Some code need
non-const data even for read-only data, so we have to const cast those
for the moment.
This refactor part of `draw_manager_c.cc` to make it more understandable
and less bug prone.
- Splits the context handing to `draw_gpu_context.cc`
- Rename `draw_manager_c.cc` to `draw_context.cc`
- Merge `DRWContextState` into `DRWContext`
- Merge lots of static functions into `DRWContext` to avoid global access
- Deduplicate code between entry point functions
- Move context init logic to `DRWContext` constructor
- Move resource init logic to `DRWContext::acquire_data`
- Move extraction `TaskGraph` out of `DRWContext`
- Reduce / centralize complexity of enabling draw engines
- Reduce the amount of `drw_get` calls
- Remove unused code
Pull Request: https://projects.blender.org/blender/blender/pulls/135821
Paddings were applied a bit oddly, resulting in a double padding for the
drawing. Each "tile" (the space to draw the file in) already had a padding
applied (`FileLayout.tile_border_x`), we'd apply another one to it. This second
padding should only be used for spacing of individual items *inside* the tile.
Code makes more sense too now, there are fewer arbitrary/eyeballed numbers to
make things "look good".
Pull Request: https://projects.blender.org/blender/blender/pulls/135915
Fix an issue when the NLA is used in conjunction with a directly-
assigned Action.
When the directly-assigned Action is also used in an NLA strip, that
strip would not be evaluated any more. This was even the case when
different slots were used, which entirely muted the strip when there
was no slot directly assigned. Now the "this has been handled already"
logic considers the action and the slot.
Pull Request: https://projects.blender.org/blender/blender/pulls/135911
The "Merge Animation" operator now properly tags the affected Actions
with `ID_RECALC_ANIMATION_NO_FLUSH` so that new 'evaluated copies' are
created. Because this was missing, the animation evaluation code didn't
see the moved channelbags yet, which caused animation playback to be
broken.
Pull Request: https://projects.blender.org/blender/blender/pulls/135906
Vulkan handles are currently only requested once. In the future OpenXR
also needs acces to these handles and additional handles will be needed
when introducing copy queues and async compute.
This PR will collect the handles in a struct to ensure we don't need to
alter the GHOST interface for every change.
Pull Request: https://projects.blender.org/blender/blender/pulls/135905
This patch refactors GPU implicit conversion code by generating the name
of the shaders on the fly using fmt. This reduces boilerplate and makes
it easier to add new types.
When sync select is enabled, the data layers aren't accessed
so there is no need to add them.
Also skip adding a "pin" layer when clearing pinned UV's.
Context path in the header of material properties tab always indicates
material is on object. Include object.data in context path when material
is on mesh for example.
Pull Request: https://projects.blender.org/blender/blender/pulls/134968
Similar changes done elsewhere (#116901), replace usage of the GPU API's
`GPU_indexbuf_add_generic_vert` function by simply writing the index
data that we need. This avoids a function call and min/max tests for
every index added.
Pull Request: https://projects.blender.org/blender/blender/pulls/135404
Instead of computing an index mask for all curves, then returning an
intersection with the visible curves, just use the visible curves as
a universe for the original calculation. Also add another early out
for when there are no NURBS curves.
Currently the drawing data extraction code uses the offset indices API
quite inefficiently, copying the size of every selected every curve, then
accumulating those sizes. Instead just use the existing API function that
counts the size of all selected curves. Also for the weight overlay, avoid
doing the same calculation twice.
There is no real reason to keep these read-only, they are not exposed in
the UI anyway, and being able to edit them can become necessary in a
pipeline mamangement context.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135870
This patch refactors the result class to replace proxy results with the
possibility of doing data sharing through a shared heap allocated data
reference count. This is more robust and simpler since proxy results no
longer need to be handled as a special case in a lot of the results
code. Additionally, it allows stronger const correctness since inputs to
operations can now be const.
This is somewhat similar to implicit sharing used in other parts of
Blender, so we can look into using that in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/135778
It seems that this was 'fine', as non-trivial data in `BVHTreeFromMesh`
appear to be 'safe' when simply zero-initialized instead of being
properly constructed.
Note that this 'calloced' data was already 'MEM_deleted', this is
currently considered as a valid use-case unfortunately, otherwise the
issue would have been detected earlier.
Directly use 'copy' `MEM_new` code instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/135862
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
