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
This PR moves the ownership of vulkan memory allocator from gpu/device
to GHOST/context/device. This will allow in the future a cleaner control
flow between OpenXR and Vulkan. Currently as the ownership is in the gpu
module many objects would need to pass from GHOST to the GPU module to be
shared between the 2 allocators. Moving both (OpenXR/Context) allocator
to GHOST would reduce the complexity.
Pull Request: https://projects.blender.org/blender/blender/pulls/146819
For wide line rendering it is preferred to use polyline shaders. However
creating a custom shader is complicated and a stone to far for many
scriptors.
This PR allows using line_width_set when wide line rendering is
supported by the platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/146762
This is the first step of moving the create infos
back inside shader sources.
All info files are now treated as source files.
However, they are not considered in the include tree
yet. This will come in another following PR.
Each shader source file now generate a `.info` file
containing only the create info declarations.
This renames all info files so that they do not
conflict with their previous versions that were
copied (non-generated).
Pull Request: https://projects.blender.org/blender/blender/pulls/146676
This allows to share the parsed structure between each
preprocessing step if no mutation occurs.
Also remove `matrix_constructor_linting` as this is
now enforced by the C++ compilation. Same thing for
`array_constructor_linting`.
Pull Request: https://projects.blender.org/blender/blender/pulls/146666
This patch reorders the inputs of some of the compositor nodes
accordingly to their importance. The importance is already quantified
internally using the domain priority of the input, so we needn't make
any subjective judgement and just order by the priority.
This breaks forward and backward compatibility if input indices were
used as opposed to input identifiers due to the different order.
Handling compatibility is not impossible, but is difficult, and it was
already ignored in many past node changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/146311
Due to an incorrect assumption float buffers were converted to sRGB
values when uploading to an sRGBA8 texture. This is done when rendering
flames in workbench and resulted in to bright renders.
This PR removes sRGB encoding when uploading float values to sRGBA8 textures.
Fixes:
- render/openvdb/fire
- render/openvdb/principled_blackbody
- render/openvdb/smoke_fire
Pull Request: https://projects.blender.org/blender/blender/pulls/146636
Before the render graph was introduced we relied on a submission
resource tracker that allowed to resuse resources in the next frame.
With the introduction of the render graph we slowly migrated the
resource tracking to the render graph and eventually also moved the
whole discard pools to the submission runner.
There was still one part that 'used' the legacy resource tracker, but
actually didn't as it never reused resources. This PR removes the
resource tracker and migrate the push constants to use the render graph
to update a single buffer per shader.
Pull Request: https://projects.blender.org/blender/blender/pulls/146627
On its own, the main functionality of the Radial Tiling node
is the ability to divide a 2D Cartesian coordinate system into
as many radial segments as specified by the "Segments" input.
Each segment has its own affinely transformed coordinate system,
provided through the "Segment Coordinates" output, which can be
used to tile textures in a radially symmetric manner.
Additionally, a unique index is provided for every segment through
the "Segment ID" output, the width of each segment at Y-coordinate
of the "Segment Coordinates" output without normalization = 0 is
provided through the "Segment Width" output and the rotation value
of the affine transformation of the coordinate system of each segment
is provided through the "Segment Rotation" output.
The roundness of the coordinate lines of the "Segment Coordinates"
output can be controlled through the "Roundness" inputs.
This can be used to make the coordinate systems of the segments
a mix of Cartesian and polar coordinates.
Lastly, the lines of points of the "Segment Coordinates" output with
constant Y-coordinates have the shape of polygon with rounded corners,
which can be used to procedurally create rounded polygons.
Pull Request: https://projects.blender.org/blender/blender/pulls/127711
This simplifies the GBuffer packing code in a lot
of common use cases. This improves compilation
speed.
The trivial case is either a single closure (already handled)
or 2 closures with no second data layer.
We detect if reflection and refractions can
be assumed colorless depending on the nodetree config.
Colorless reflection or refraction are only using one
data layer.
Pull Request: https://projects.blender.org/blender/blender/pulls/146455
A compiler/driver bug makes so that we can't rely on image atomics.
Adding a write that is never executed after the atomics tricks
the compiler to issue the correct synchronisation instruction.
This fixes a bunch of our render tests differences.
We will keep this workaround until this is fixed upstream.
Pull Request: https://projects.blender.org/blender/blender/pulls/146442
This allows to reduce the number of includes for each
tree graph (surface, volume, displacement) and
reduce the code size significantly for most vertex
shaders, speeding up compile time.
Rel #145347
Pull Request: https://projects.blender.org/blender/blender/pulls/146419
These are causing quite a big difference in existing files, which is not
easy to address in versioning. Since the goal of removing this was to
simplify things for us and that's not the case, just revert this change.
This reverts commit ab21755aaf.
Ref #139923
Pull Request: https://projects.blender.org/blender/blender/pulls/146336
This removes unused closure branches in the principled BSDF
code using the Material flags.
On top of this, use constants for weights to use compiler
dead code eliminitation for unused branches when there
is different variants of the principled BSDF node used.
Finally, remove Gbuffer packing cases that are not present
inside the nodetree.
Testing with the same setup as #145347:
| | main (ms) | PR (ms) | Delta (ms) |
| -------- | ----------- | ------------ |------------ |
| Nvidia | 174 | 132 (1.31x) | 42 |
| Mesa AMD | 191 | 170 (1.12x) | 21 |
Barbershop compilation time is almost equal because it is not using
the principled BSDF.
Rel #145347
Pull Request: https://projects.blender.org/blender/blender/pulls/146324