BLI code for enums that are meant to be used as "bit flags" defined
an ENUM_OPERATORS macro in BLI_utildefines.h. This cleans up things
related to said macro:
- Move it out into a separate BLI_enum_flags.hh header, instead of
"random bag of things" that is the current place,
- Update it to no longer need manual indication of highest individual
bit value. This originally was added in a31a87f89 (2020 Oct), in
order to silence some UBSan warnings that were coming
from GPU related structures (looking at current GPU code, I don't
think this is happening anymore). However, that caused actual
user-visible bugs due to incorrectly specified max. enum bit value,
and today 14% of all usages have incorrect highest individual
bit value spelled out.
- I have reviewed all usages of operator ~ and none of them are
used for directly producing a DNA-serialized value; all the
usages are for masking out other bits for which the new ~
behavior that just flips all bits is fine.
- Make the macro define flag_is_set() function to ease check of bits
that are set in C++ enum class cases; update existing cases to use
that instead of three other ways that were used.
Pull Request: https://projects.blender.org/blender/blender/pulls/148230
644fb2b679 fixed a long standing issue
that offscreen example showed the wrong colors. However the fix assumes
that input texture color space is always sRGB.
This adds a shader variation that draws textures that are stored in scene referred
linear color space (like all of our Image data-block).
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/147788
This patch adds support for the dimensions property of vector sockets,
support 2D and 4D sockets in addition to the currently supported 3D one.
This just involves assigning the correct GPU type when constructing the
GPU materials from nodes.
The only node that uses 2D sockets for now is the Radial Tilling node,
so we just need to update its interface.
Pull Request: https://projects.blender.org/blender/blender/pulls/148034
This patch adjusts the implicit conversion rules involving float2 to
match other parts of Blender, like BKE Conversions, Geometry Nodes, and
the Compositor. The new rules also make much more sense to me on their
own.
The GPU_VEC2 is no currently used for GPU materials as far as I can see,
so this should not be a breaking change.
Pull Request: https://projects.blender.org/blender/blender/pulls/148033
This seems like an out of memory issue where the storage
buffer could not be allocated but still used as a destination
for a copy. After an out of memory issue memory can be fragmented
and any allocation can still fail.
On `AMD Radeon(TM) 890M Graphics Advanced Micro Devices AMD`
`24.30.58` I got to multires subdivision level 2+6 using the steps
described in the report. 2+7 is failing for me. 2+6 already requires 16GB
of memory using large chunks.
OpenGL and Vulkan work with other limits and memory models and can
have different behavior. This PR only improves the mentioned issue, but
can still fail in other areas.
Pull Request: https://projects.blender.org/blender/blender/pulls/147713
On certain platforms Blender can crash on startup after the update of
VMA. This was because we want to select the correct memory area based on
requirements/preferences, but the overall flag was set to auto.
These options are mutual exclusive. This PR changes the flags to use the
requirements/preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/147781
This patch mixes the alpha channel of the color in the Mix mode of the
Mix node. This has no effect on EEVEE/Cycles since they do not support
alpha, but affects the Compositor, Geometry Nodes, and Texture Nodes.
Previously, the alpha of the first color was assumed, which meant mixing
two images with transparency using a mask in the compositor resulted in
part of the image having bad alpha and required manually mixing of the
alpha channel. And this is the main motivation of this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/146461
Support loops at the GLSL level instead of relying on
NOD_shader_nodes_inline.
This improves compilation and runtime performance, avoids causing
recompilations on iteration count changes, and allows supporting
dynamic iteration counts.
(EEVEE-only)
Pull Request: https://projects.blender.org/blender/blender/pulls/145269
This avoid putting too much work in only one thread for building very long surfel lists.
Instead of insertion sort, we use a prefix sum where all surfel scan the whole ray
list to know their position. Only the coplanar surfel patching is dispatched as
one thread per list.
This is currently a bruteforce approach and could be optimized further.
On top of this, we add a heuristic to scale the amount of work from the baking
depending on the scene complexity. Complex scene will have more overhead but
will remain responsive during baking, while simple scene will be faster to bake.
This avoids hitting TDR in most cases.
The update refresh is now limited to 1 per second to avoid the readback overhead.
Fix#142988
Pull Request: https://projects.blender.org/blender/blender/pulls/146848
Qualcomm driver team found an issue how Blender uses dynamic rendering.
The issue is that between suspend/resume of rendering only a limited
commands are possible. However we add commands that shouldn't be added
there. It is a violation of the Vulkan spec
VUID-VkSubmitInfo-pCommandBuffers-06015
It went unnoticed as it is mere a single line in the 5000+pages spec
and wasn't covered by the validation layers. This has been reported
upstream.
To fix this issue we remove the usage of suspending/resuming render
passes and fix any issue that used this together with clearops. Most
likely the fix will require a second dynamic rendering pass when
clearops are used.
Pull Request: https://projects.blender.org/blender/blender/pulls/147425
b2eaf812b1 made sure that the min offset alignment for text rendering
was used to calculate the correct offset. However the change didn't
update the region to be uploaded to the GPU. The artifacts are caused by
reading from allocated, but uninitialized memory.
This PR fixes this by calculating the correct region to copy to the GPU.
The artifact didn't appear on AMD/NVIDIA GPUs as their alignment are
4 bytes. Intel GPU is 64 bytes.
Pull Request: https://projects.blender.org/blender/blender/pulls/147265
VSE doesn support pure emissive colors when rendering, but weren't
showed inside the preview. This was a limitation when the background
checkerbord is draw. It renders the alpha of the overlay to 1.0 making
the background be drawn on top of the image, hiding the pure emissive
colors.
This PR fixes this by clearing the alpha. This will render the
checkerboard below the image.
Another solution would be to set the alpha to zero in the theme, but that
adds confusion as theme colors will still be able to alter the support of
pure emissive colors.
Pull Request: https://projects.blender.org/blender/blender/pulls/146562
Subimage tracking is done per layer, but workbench depth of field
required to track per mipmap level. This PR refactors sub image tracking
and implements tracking the state per mipmap level to ensure that
the correct pipeline barriers can be generated.
Most platforms wouldn't show any artifacts as the pixel layouts are the
same, but there it is a violation of the spec.
Pull Request: https://projects.blender.org/blender/blender/pulls/147207
!146956 introduced buffer streaming and is used to improve the
performance of text rendering. However the solution didn't check the
minimum allowed offset for storage buffers.
This PR will use the correct offset. This was only visible on Qualcomm
devices as other systems don't limit this offset.
Detected when looking into: #147023
Pull Request: https://projects.blender.org/blender/blender/pulls/147192
Includes the following changes to the existing Locomotion system for VR Scene Inspection:
* new VR Navigation Preferences and VR Session Settings
* changes to XR raycast logic and its visualization
* new XR vignette that appears when moving
* snap turning
Pull Request: https://projects.blender.org/blender/blender/pulls/144241
Check whether creating GPU textures succeeds before using them.
However, currently when that happens there is no indication to the user
that "hey the resolution is maybe too big". Not sure what is the best
way to do that however; e.g. Workbench rendering also does not
indicate that in a similar scenario.
While at it, add GPU_is_safe_texture_size instead of duplicating
the same logic in two places.
Pull Request: https://projects.blender.org/blender/blender/pulls/147043
This PR introduces grouping of the unit tests inside debug groups.
Previously a capture would contain a single test. But for performance
reasons multiple tests are run in a single process, making it unclear
which commands belong to which test.
This PR will add a debug group for each test that is run.
Pull Request: https://projects.blender.org/blender/blender/pulls/147046
Step by step debugging of unit tests inside renderdoc didn't work as the
debug information wasn't included when running unit tests. This should
have been the case, but was broken when introducing
`--debug_gpu_compile_shaders` startup parameter.
Pull Request: https://projects.blender.org/blender/blender/pulls/147040
OpenGL has the concept of streaming buffers these buffers are marked to be
rewritten and used a small number of times. Vulkan (being low-level API)
doesn't have this concept. When performing font rendering Blender uses
streaming buffers and can slow down Vulkan as GPU barriers are added
between uploading and using the buffer.
Using a different approach could reduce the GPU barriers. The overall
idea is:
Altering render graph nodes
During font rendering the streaming buffer is rewritten from start with
the data to render the next part. This could only cover a part of the fully
allocated buffer. And would introduce a barrier before and after rewritting
the next part.
The allocated buffer on the GPU can fit more data but that data needs to be
passed along the first update to reduce the barriers. Allowing access to an
existing node in the render graph would allow to change the initial upload to
upload more data, without additional barriers.
VKStreamingBuffer
A new buffer type is introduced that will keep track of the streaming buffer
on the current render graph. A streaming buffer can be shared between multiple
threads and requires state manager to be done per context.
Pull Request: https://projects.blender.org/blender/blender/pulls/146956
7becc38a3c introduced new text rendering.
In the refactoring the vertex buffer was replaced by a more shallow
storage buffer. However the refactoring removed one optimization that
the vulkan backend uses, namely the actual amount of bytes that is being
used by the draw call. This resulted in overly large data transfers.
For example in the text editor the texts are rendered one glyph at a
time. But the storage buffer would always upload the data for 1024
glyphs.
This PR allows the usage size of a storage buffer to be set to ensure
that the data transfers are limited.
The implementation wasn't added to OpenGL as it draws incorrectly.
Issue detected during the research of !146956 That PR will implement
better data streaming inside the Vulkan backend and also requires
to know the actual usage size of the buffer to detect what data can
be grouped together.
Pull Request: https://projects.blender.org/blender/blender/pulls/146958
Applies thin film iridescence to metals in Metallic BSDF and Principled BSDF.
To get the complex IOR values for each spectral band from F82 Tint colors,
the code uses the parametrization from "Artist Friendly Metallic Fresnel",
where the g parameter is set to F82. This IOR is used to find the phase shift,
but reflectance is still calculated with the F82 Tint formula after adjusting
F0 for the film's IOR.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Co-authored-by: Weizhen Huang <weizhen@blender.org>
Co-authored-by: RobertMoerland <rmoerlandrj@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/141131
In Render properties > Color Management > Display.
* Off: Directly output image as produced by OpenColorIO. This is not correct
in general, but may be used when the system configuration and actual display
device is known to match the chosen display.
* Automatic: Display images consistent with most other applications, to preview
images and video for export. A best effort is made to emulate the chosen
display on the actual display device.
The option is grayed out when the current OpenColorIO config and display/view
does not support emulation.
Ref #145022, #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/146808
