Related to #126974, which removed command reordering due to some
EEVEE/framebuffer requirements. However buffer can still be reordered
without any artifacts.
Update buffers are common operations and are often isolated; safe to
move them outside the rendering scope.
Pull Request: https://projects.blender.org/blender/blender/pulls/128538
This adds feature parity with Cycles regarding light and shadow liking.
Technically, this extends the GBuffer header to 32 bits, and uses
the top bits to store the object's light set membership index.
The same index is also added to `ObjectInfo` in place of padding bytes.
For shadow linking, the shadow blocker sets bitmask is stored per
tilemap. It is then used during the GPU culling phase to cull objects
that do not belong to the shadow's sets.
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/127514
The metal backend assumes that textures can always be allocated. When
metal later detects that the texture cannot be 'baked' it leads to
undesired behavior as Blender think it has a texture with memory
allocated.
This PR only changes the GPU_TEXTURE_3D case as that leads to issues
when loading large voluetric data. Arrayed textures will still fail
as that requires different checks to be added. I rather re-view the
current implementation in the future.
> NOTE: The max depth is hardcoded to 2048
Change should be backported to 4.2
Pull Request: https://projects.blender.org/blender/blender/pulls/128365
When using AMD pro-drivers the limits reported of the device can be
`UINT_MAX` but are stored in int fields. In this case the limits would
become negative and GPU materials validation failed resulting into errors.
This is fixed by clamping the value to `INT_MAX`.
Pull Request: https://projects.blender.org/blender/blender/pulls/128437
Previously, Cycles only supported the Henyey-Greenstein phase function for volume scattering.
While HG is flexible and works for a wide range of effects, sometimes a more physically accurate
phase function may be needed for realism.
Therefore, this adds three new phase functions to the code:
Rayleigh: For particles with a size below the wavelength of light, mostly athmospheric scattering.
Fournier-Forand: For realistic underwater scattering.
Draine: Fairly specific on its own (mostly for interstellar dust), but useful for the next entry.
Mie: Approximates Mie scattering in water droplets using a mix of Draine and HG phase functions.
These phase functions can be combined using Mix nodes as usual.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/123532
We can have deferred and non-deferred shaders (so, different threads)
with the same `additonal_info` dependencies trying to finalize the same
`ShaderCreateInfo`.
This ensures `finalize` always runs from the main thread to avoid race
conditions.
Pull Request: https://projects.blender.org/blender/blender/pulls/128281
This change adds the option to update a buffer via the render
graph via `vkCmdUpdateBuffer`. This is only enabled for
uniform buffers as they are small and aligned/sized correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/128416
This PR introduces support for the extension `VK_KHR_fragment_shader_barycentric`,
and includes a few miscellaneous improvements related to it.
1. Add support for `VK_KHR_fragment_shader_barycentric`, if the physical device
supports it. Otherwise, gpu_BaryCoord is generated through an injected geom
shader, like it was previously.
2. Simplify the logic of checking has_geometry_stage in vert shader.
3. Fix a potential issue of location mismatch in an injected geom shader.
Related to #127687Resolves#126228
Pull Request: https://projects.blender.org/blender/blender/pulls/127995
When performing preview job rendering the memory wasn't recycled leading
to a memory leak. For background rendering we already recycled memory in
a correct way. This change enables the same branch during preview
rendering.
Also adds a better `VKDevice::debug_print` to see the resources being
tracked by the different threads and resource pools.
Pull Request: https://projects.blender.org/blender/blender/pulls/128377
Pipeline pool could log to much information that confused developers who
are not up to date what pipelines are. This PR will hide the confusing
messages. When working on Vulkan these messages can still be shown by
raising the log level.
See !128254
Pull Request: https://projects.blender.org/blender/blender/pulls/128352
This rare GPU has z-fighting issues in editor mode. Might be fixable by
changing the bias, but would decrease precision on other platforms as
well. Better to move this GPU to limited support. It is working, just
has some drawing artifacts.
See #128179
Pull Request: https://projects.blender.org/blender/blender/pulls/128351
When exiting the immediate buffers are discarded, but where not
destroyed making the buffers still leak.
Detected when looking into descriptor set freeze issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/128249
A driver (package) installed by the user can have many different drivers
and they can all report a different version. For AMD the version we
reported was from their Vulkan driver. This version isn't useful during
bug triaging.
This PR will use the driver info and driver name from the driver
properties to construct a driver version string that will be used for
reporting.
Pull Request: https://projects.blender.org/blender/blender/pulls/128232
Immediate mode uses the old 'resource tracker' which has been replaced
by swap chain resource pools. This PR optimizes immediate mode buffers
by utilizing resource pools.
Pull Request: https://projects.blender.org/blender/blender/pulls/128188
Currently the log only contained the first compatible device. It is
more important to the user to know which device is used.
This PR increases the level of the first compatible device so it is only
visible when increasing the log level. It reports the device, driver and
vendor when starting blender with `--debug-gpu`.
Pull Request: https://projects.blender.org/blender/blender/pulls/128168
Resource binding was over-complicated as I didn't understood the state
manager and vulkan to make the correct decisions at that time. This
refactor will remove a lot of the complexity and improves the performance.
**Performance**
The performance improvement is noticeable in complex grease pencil
scenes.
Grease pencil benchmark file picknick:
- `NVIDIA Quadro RTX 6000` 17 fps -> 24 fps
- `Intel(R) Arc(tm) A750 Graphics (DG2)` 6 -> 21 fps
**Bottle-neck**
The performance improvements originates from moving the update entry
point from state manager to shader interface. The previous implementation
(state manager) had to loop over all the bound resources and find in the
shader interface where it was located in the descriptor set. Ignoring
resources that were not used by the shader. But also making it hard
to determine if descriptor sets actually changed. Previous implementation
assumed descriptor sets always changed.
When descriptor set changed a new descriptor set needed to be allocated.
Most drivers this is a fast operation, but on Intel/Mesa this was measurable
slow. Using an allocation pool doesn't fit the Vulkan API as you are only
able to reuse when the layout matches exactly. Of course doable, but requires
another structure to keep track of the actual layouts.
**Solution**
By using the shader interface as entry point we can:
1. Keep track if there are any changes in the state manager. If not and the
layout is the same, the previous shader can be reused.
2. In stead of looping over each bound resource, we loop over bind points.
**Future extensions**
Bundle all descriptor set uploads just before use. This would be more
in line with how 'modern' Vulkan should be implemented. This PR already
separates the uploading from the updating and technically allows to upload
more than one descriptor set.
Instead of looking 1 set back we should measure if we can handle multiple
or keep track of the different layouts resources to improve the performance
even further.
Optional use `VK_KHR_descriptor_buffer` when available.
Pull Request: https://projects.blender.org/blender/blender/pulls/128068
Takes into account any offset that must be added to the vertex index
(usually supplied as baseVertex or startVertex in the Metal draw call)
in the code that emulates the SSBO vertex fetch.
Authored by Apple: James McCarthy
Pull Request: https://projects.blender.org/blender/blender/pulls/127864
Adds antialiasing to curve's handles and thickness to active ones.
Also handles now react to
`Preferences > Interface > Display > Resolution Scale` and
`Preferences > Themes > 3D Viewport > Edge Width` as they do in
legacy curves.
Pull Request: https://projects.blender.org/blender/blender/pulls/122910
GPU resources created during Light probe bake job were added to discard pool, but the pool itself was never notified by worker thread to release resources.
Bake job creates dedicated `GPUContext` for its needs and later deletes it within the same thread.
Pull Request: https://projects.blender.org/blender/blender/pulls/127977
Removes two levels of indirection when updating descriptor sets.
These are the easy ones to remove. Others will be removed in
a future PR.
This is part of reworking of how descriptor sets are used.
This PR Mostly reduces complexity.
Pull Request: https://projects.blender.org/blender/blender/pulls/127915
De-interleaved vertex buffers offsets the attribute in the buffer to
the de-interleaved position. The vertex attribute offset is limited by a
constrained and would raise an error when the buffers just a bit larger.
*VUID-VkVertexInputAttributeDescription-offset-00622*: offset must
be less than or equal to `VkPhysicalDeviceLimits::maxVertexInputAttributeOffset`
This PR fixes this by offsetting the buffer in stead of the attribute.
Offsetting buffers is limited by the amount of memory.
Pull Request: https://projects.blender.org/blender/blender/pulls/128031
Allows users to override the auto detection for GPU
selection. Normally the GPU selection is done by looping
over the order Vulkan provides and finding the highest
performing device based on its type (discrete, integrated,
software).
However users might have multiple discrete cards and want
to switch between them. Or developers want to validate other
GPUs without rebooting.
This PR adds the ability to override the auto detection
for the vulkan backend.
**Future improvements**:
- This PR does not include a command line option. This can be added
later for render farms.
Pull Request: https://projects.blender.org/blender/blender/pulls/127860
Since parallel compilations was introduced, a validation error
was signalling that push constants for compute shaders didn't have
the correct pipeline binding. The root cause was that the pipeline
binding was determined, before the type of shader was known.
This PR fixes this by detemining if a shader is a compute shader up
front. It also removes some code that could lead to issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/128010
In addition to float<->half functions to convert one number (#127708), add
float_to_half_array and half_to_float_array functions:
- On x64, this uses SSE2 4-wide implementation to do the conversion
(2x faster half->float, 4x faster float->half compared to scalar),
- There's also an AVX2 codepath that uses CPU hardware F16C instructions
(8-wide), to be used when/if blender codebase will start to be built
for AVX2 (today it is not yet).
- On arm64, this uses NEON VCVT instructions to do the conversion.
Use these functions in Vulkan buffer/texture conversion code. Time taken to
convert float->half texture while viewing EXR file in image space (22M
numbers to convert): 39.7ms -> 10.1ms (would be 6.9ms if building for AVX2)
Pull Request: https://projects.blender.org/blender/blender/pulls/127838
This PR introduces parallel shader compilation for Vulkan shader
modules. This will improve shader compilation when switching to material
preview or EEVEE render preview. It also improves material compilation.
However in order to measure the differences shaderc needs to be updated.
PR has been created so we can already start with the code review. This
PR doesn't include SPIR-V caching, what will land in a separate PR as
it needs more validation.
Parallel shader compilation has been tested on AMD/NVIDIA on Linux.
Testing on other platforms is planned in the upcoming days.
**Performance**
```
AMD Ryzen™ 9 7950X × 32, 64GB Ram
Operating system: Linux-6.8.0-44-generic-x86_64-with-glibc2.39 64 Bits, X11 UI
Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 550.107.02
```
*Test*: Start blender, open barbershop_interior.blend and wait until the viewport
has fully settled.
| Backend | Test | Duration |
| ------- | ------------------------- | -------- |
| OpenGL | Coldstart/No subprocesses | 1:52 |
| OpenGL | Coldstart/8 Subprocesses | 0:54 |
| OpenGL | Warmstart/8 Subprocesses | 0:06 |
| Vulkan | Coldstart Without PR | 0:59 |
| Vulkan | Warmstart Without PR | 0:58 |
| Vulkan | Coldstart With PR | 0:33 |
| Vulkan | Warmstart With PR | 0:08 |
The difference in time (why OpenGL is faster in a warm start is that all
shaders are cached). Vulkan in this case doesn't cache anything and all
shaders are recompiled each time. Caching the shaders will be part of
a future PR. Main reason not to add it to this PR directly is that SPIR-V
cannot easily be validated and would require a sidecar to keep SPIR-V
compatible with external tools..
**NOTE**:
- This PR was extracted from #127418
- This PR requires #127564 to land and libraries to update. Linux lib
is available as attachment in this PR. It works without, but is as slow as
single threaded compilation.
Pull Request: https://projects.blender.org/blender/blender/pulls/127698
Windows/Intel and Apple drivers do not support dynamic
rendering unused attachments. Due to mistakes we made
this extension partly optional. Eg. the extension was
optional, but its settings were not.
This PR makes the extension fully optional. However
without the extension some drivers might make incorrect
assumptions. This should be solved when it is more clear
why some drivers are still crashing when using dynamic
rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/127839
Blender codebase had two ways to convert half (FP16) to float (FP32):
- BLI_math_bits.h half_to_float. Out of 64k possible half values, it converts
4096 of them incorrectly. Mostly denormals and NaNs, which is perhaps not too
relevant. But more importantly, it converts half zero to float 0.000030517578
which does not sound ideal.
- Functions in Vulkan vk_data_conversion.hh. This one converts 2046 possible
half values incorrectly.
Function to convert float (FP32) to half (FP16) was in Vulkan
vk_data_conversion.hh, and it got a bunch of possible inputs wrong. I guess it
did not do proper "round to nearest even" that CPU/GPU hardware does.
This PR:
- Adds BLI_math_half.hh with float_to_half and half_to_float functions.
- Documentation and test coverage.
- When compiling on ARM NEON, use hardware VCVT instructions.
- Removes the incorrect half_to_float from BLI_math_bits.h and replaces single
usage of it in View3D color picking to use the new function.
- Changes Vulkan FP32<->FP16 conversion code to use the new functions, to fix
correctness issues (makes eevee_next_bsdf_vulkan test pass). This makes it
faster too.
Pull Request: https://projects.blender.org/blender/blender/pulls/127708
ShaderC compiler was cached on the Vulkan backend. The compiler itself
is light-weight and doesn't require any caching. This PR removes the
cached instance from the backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/127693
This uses the path that metal was using.
This doesn't seems to create any difference in render
tests. This simplify the backend code and avoid
specific path for metal.
Idea suggested by Kevin Chuang
Pull Request: https://projects.blender.org/blender/blender/pulls/127687
Parallel shader compilation introduced `GPU_shader_cache_dir_clear_old`.
The implementation was specific to OpenGL and could not be overwritten
by other backends. This PR improves the implementation so the backend
can have its own implementation.
This is needed for upcoming changes to the Vulkan backend where we
want to use similar mechanisms to speed up shader compilation and caching.
Pull Request: https://projects.blender.org/blender/blender/pulls/127680
This class allows to define capture scopes
that can be chosen during gpu work capture.
This reduces the amount of command captured
and allow for faster replay and easier
navigation inside the debug tools like Xcode
or RenderDoc.
