Reported by @fclem. On Metal GPU_finish enacts a CPU<-> GPU sync by
submitting a command buffer and waiting on the completion event.
However if there was no command buffer to submit then the call was
returning immediately, regardless of any outstanding GPU work.
This fixes that case by keeping track of all outstanding work and
blocking on that.
Authored by Apple: James McCarthy
Co-authored-by: James McCarthy <jamesmccarthy@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/128987
VK_EXT_dynamic_rendering_unused_attachments is required for correct working.
Renderdoc hides this extension, but most platforms do work. However the
Windows Intel driver crashes when using iGPUs; they don't support this
extension at all.
This change does a more strict extension test so drivers that do not
support this extension will fallback to OpenGL. When using renderdoc it
is now allowed to compile blender with `WITH_RENDERDOC=On`.
Future developments are needed to add support for Intel iGPUs on
Windows.
Pull Request: https://projects.blender.org/blender/blender/pulls/128986
Resources are shared, when running multiple contexts on the same thread.
Cycles uses the same context on multiple threads and expected same resources.
This change will introduce a single render graph per context and an updated
resource management. Render graphs are not shared anymore; Resource pools
are still shared, but garbage collection depends on the thread and if
background rendering is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/128983
Cycles uses multiple threads to send commands to the GPU. The current
command buffer structure assumed that all commands from the same context
were send via the same thread. This wasn't the case and could lead to
recording commands to command buffers that are still pending (preparing
commands to send to GPU).
This is fixed by creating a command buffer each time a render graph
submits its work.
Detected when researching #128608
Pull Request: https://projects.blender.org/blender/blender/pulls/128978
When allocating a host visible buffer it could be that the returned
buffer was not host visible and access to the buffer would write to
unallocated memory.
Detected when researching #128608
Pull Request: https://projects.blender.org/blender/blender/pulls/128977
When using cycles in the viewport there it uses render threads and
workers to update the viewport. All threads can record commands to the
queue and needs to be synchronized. This didn't happen leading to
incorrect renders.
Detected when researching #128608
Pull Request: https://projects.blender.org/blender/blender/pulls/128975
Multiple threads can access the same device queue from different
threads. This could happen when doing a cycles preview render, baking
eevee volume probes or generating material previews.
This PR adds a mutex around access to the device queues.
Detected when researching #128608
Pull Request: https://projects.blender.org/blender/blender/pulls/128974
When using vertex displacement EEVEE didn't compile the generated
functions into the vertex shader. This could result in errors when
compiling materials.
**Notes**
- Should be back-ported to Blender 4.2
Pull Request: https://projects.blender.org/blender/blender/pulls/128525
Adds an additional precheck to identify if the app cache dir is correct.
Reduces placing cache files all over the place when the app dir isn't
correct.
Adds a SPIR-V cache that skips frontend compilation for shaders
that are already compiled in a previous run of Blender.
Initially this was postponed to 4.4 but it was observed that
the vulkan backend didn't perform well on Windows in debug
builds. The reason is that the compiler would also be a debug
build which makes compiling a shader really slow. Starting
Blender on a debug build could take minutes.
So the decision was made to give this task a higher priority so
the vulkan backend would become more usable to developers
as well.
The cache is stored in the application cache dir. The SPIR-V
binaries can be used by different Blender versions so there
is no version specific cache folder.
**Sidecar**: SPIR-V files are a stream of bytes. There is no
header information that allow us to validate the stream. To
add basic validations we could add our custom header or
a sidecar. It was chosen to use a sidecar as having the SPIR-V
files unmodified allows us to load them directly in
debug tools for analyzing.
**Retention**: Shaders that are not used are automatically
removed with a retention period of 30 days.
**Shader builder**: Shader builder cannot use the SPIR-V
cache as it uses stubs that returns invalid cache directories.
This would load/save the cache to the location where you
started the build.
Pull Request: https://projects.blender.org/blender/blender/pulls/128741
Between 0bfd5e3536
and b1cbd9c889
the main branch is incorrectly processing the file
`draw_debug_info.hh` as GLSL and does some string
preprocessing on it. But the output filename matches
the name of the header source file used for compiling
the gpu module. This file not having been updated
since a long time doesn't get copied from the source
folder when switching to other branch and make compilation
fail.
In order to avoid breaking the buildbot longer, we
rename the incriminating file to force recreate it
when building the release branch.
Move most of the string preprocessing used for MSL
compatibility to `glsl_preprocess`.
Enforce some changes like matrix constructor and
array constructor to the GLSL codebase. This is
for C++ compatibility.
Additionally reduce the amount of code duplication
inside the compatibility code.
Pull Request: https://projects.blender.org/blender/blender/pulls/128634
This changes the include directive to use the standard C preprocessor
`#include` directive.
The regex to applied to all glsl sources is:
`pragma BLENDER_REQUIRE\((\w+\.glsl)\)`
`include "$1"`
This allow C++ linter to parse the code and allow easier codebase
traversal.
However there is a small catch. While it does work like a standard
include directive when the code is treated as C++, it doesn't when
compiled by our shader backends. In this case, we still use our
dependency concatenation approach instead of file injection.
This means that included files will always be prepended when compiled
to GLSL and a file cannot be appended more than once.
This is why all GLSL lib file should have the `#pragma once` directive
and always be included at the start of the file.
These requirements are actually already enforced by our code-style
in practice.
On the implementation, the source needed to be mutated to comment
the `#pragma once` and `#include`. This is needed to avoid GLSL
compiler error out as this is an extension that not all vendor
supports.
Rel #127983
Pull Request: https://projects.blender.org/blender/blender/pulls/128076
When attaching a layered image with offset, the size of the attached
layers should be decreased. Otherwise an image view is created that can
access incorrect data.
Pull Request: https://projects.blender.org/blender/blender/pulls/128583
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
