Fractal noise is the idea of evaluating the same noise function multiple times with
different input parameters on each layer and then mixing the results. The individual
layers are usually called octaves.
The number of layers is controlled with a "Detail" slider.
The "Lacunarity" input controls a factor by which each successive layer gets scaled.
The existing Noise node already supports fractal noise. Now the Voronoi Noise node
supports it as well. The node also has a new "Normalize" property that ensures that
the output values stay in a [0.0, 1.0] range. That is except for the F2 feature where
in rare cases the output may be outside that range even with "Normalize" turned on.
How the individual octaves are mixed depends on the feature and output socket:
- F1/Smooth F1/F2:
- Distance/Color output:
The individual Distance/Color octaves are first multiplied by a factor of
`Roughness ^ (#layers - 1.0)` then added together to create the final output.
- Position output:
Each Position octave gets linearly interpolated with the combined output of the
previous octaves. The Roughness input serves as an interpolation factor with
0.0 resutling in only using the combined output of the previous octaves and
1.0 resulting in only using the current highest octave.
- Distance to Edge:
- Distance output:
The Distance octaves are mixed exactly like the Position octaves for F1/Smooth F1/F2.
It should be noted that Voronoi Noise is a relatively slow noise function, especially
at higher dimensions. Increasing the "Detail" makes it even slower. Therefore, when
optimizing a scene one should consider trying to use simpler noise functions instead
of Voronoi if the final result is close enough.
Pull Request: https://projects.blender.org/blender/blender/pulls/106827
This PR adds support for indirect compute.
Indirect compute is almost the same as regular compute. The
only difference is that the parameters for the compute dispatch
isn't passed as a parameter, but that these parameters are part
of a buffer.
Pull Request: https://projects.blender.org/blender/blender/pulls/108879
Resolves failing unit tests where missing texture read support for
1D/3D textures was required. Also resolves a number of missing
format support cases when determining texture component
count and byte size for reading/writing.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108751
Math tests failing in Metal due to non-zero-initialized values
and shader compilation error caused by mutli-component
boolean being implicitly evaluated.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108758
Bug in Metal when gl_FragDepth is used but not written to by a shader
causing depth-based navigation to fail. Patch ensures gl_FragDepth
is assigned a default value at the current depth from the vertex
shader to catch all edge-cases of this.
Authored by Apple: Michael Parkin-White
Co-authored-by: Michael Parkin-White <mparkinwhite@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/108453
This PR adds initial cube (array) support. Depending on how the texture
is used a different image view is created. When used as a framebuffer
attachment only a single side of the cubemap is attached. The image
view is attached as a 2d texture array. When used as a shader resource
the image view is a cubemap.
Also adds test cases to test both scenarios.
Pull Request: https://projects.blender.org/blender/blender/pulls/108794
Workbench normals where inverted resulting to drawing artifacts like:
- Black pixels during matcaps (normals contained NAN values)
- Studio light inverted
The root cause for this was that Vulkan default to determine if a
primitive is facing the camera should be switched. The default was still
incorrect.
Although this fixes it, a better solution is to determine the front
facing based on if the viewport should be switched. As all rendering
occurs when the viewport is inverted it doesn't matter at this moment.
Pull Request: https://projects.blender.org/blender/blender/pulls/108797
Ensure buffer read operations wait for pending GPU work to
complete. This is only required for unit tests, but required to
ensure correct results in all cases. Also adds support for staging
buffer if GPU memory type is private.
Buffer clearing routine added to support values above 1 byte.
The previous buffer clearing functionality using fillBuffer writes
values to each byte, rather than the full 32 bit uint used by the
GPU API.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108757
Addressing a number of small issues and OOB reads/writes occuring in
EEVEE Next shadows + lighting passes. Improving correctness for unit
tests. Shadows are not yet working overall, but this unblocks progress
towards unit tests.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108768
The ownership of image views depends on how they are used. When used as
an framebuffer attachment the image view is owned by the framebuffer.
When used as a image/texture in a shader the ownership of the image view
is the texture itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/108765
* opengl_context -> system_gpu_context. This is the operating system OpenGL,
Metal or Vulkan context provided by GHOST.
* gpu_context -> blender_gpu_context. This is the GPUContext provided by
the Blender GPU module, which wraps the GHOST context and adds some state.
* Various functions create/destroy/enable/disable both contexts, these have
just gpu_context in the name now.
Pull Request: https://projects.blender.org/blender/blender/pulls/108723
This makes tracking shaders easier across the pipeline. Durring logging
and debugging the vulkan driver now remembers the shader associate to
the descriptor and provides this information in its messages.
Pull Request: https://projects.blender.org/blender/blender/pulls/108743
Adds support to create SRGBA8 textures using UBYTE as input data.
It is assumed that the UBYTE are already converted to SRGB and no
conversion actually needs to happen.
Pull Request: https://projects.blender.org/blender/blender/pulls/108741
Some vulkan platforms don't support 24bit depth components. In this
case we will allocate float depth component. During readback the data
should be converted back to what is expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/108698
This PR adds conversion template to convert between Low Precision float
formats. These include Binary32 floats and lower. It also adds support
to convert between unsigned and signed float formats and float formats
with different mantissa and exponents.
Additionally overflows (values that don't fit in the target float
format) will be clamped to the maximum value.
**Reasoning**:
Up to now the Vulkan backend only supported float and half float
formats, but to support workbench, 11 and 10 unsigned floats have to be
supported as well. The available libraries that support those float
formats targets scientific applications. Where the final code couldn't
be optimized that well by the compiler.
Data conversion for color pixels have different requirements about
clamping and sign, what could eliminate some clamping code in other
areas in Blender as well. Also could fix some undesired overflow when
using pixels with high intensity that didn't fit in the texture format
leading to known artifects in Eevee and slow-down in the image editor.
**Future**
In the future we might want to move this to the public part of the GPU
module so we can use this as well in other areas (Metal backend), Imbuf clamping
See 3c658d2c2e69e9cf97dfaa7a3c164262aefb9e76 for a commit that uses
this and improves image editor massively as it doesn't need to reiterate over
the image buffer to clamp the values into a known range.
Pull Request: https://projects.blender.org/blender/blender/pulls/108168
There produce unneeded empty lines in the
console. They are just relic from the time
these message were using printf.
Also remove some redundant informations in
the messages themselves.
This PR silences console output during statup phase of blender. During
startup logging isn't yet initialized and print statements where used.
Logging is initialized during the first construction of a Metal Context.
The console prints are now hidden by behind the '--debug-gpu' command
line option.
Pull Request: https://projects.blender.org/blender/blender/pulls/108593
In the specification of validation layers it is mentioned that
the messenger should always return VK_FALSE. When this isn't the
case VK_ERROR_VALIDATION_FAILED_EXT will be returned and the
API command will fail.
This PR will always return false.
Pull Request: https://projects.blender.org/blender/blender/pulls/108545
This change will register a callback to Vulkan debug messaging
allowing us to filter out messages and log them using CLog.
This change only provides the initial changes, and more tweaks
are expected to on formatting and filtering.
Pull Request: https://projects.blender.org/blender/blender/pulls/107635
Excessive memory pool bloating could occur for certain workloads in
Metal. Particularly those which continuously allocate increasingly
large buffers with minimal re-use of existing buffers.
New logic added to the memory pool flushes old buffers if they
have not been used for a set period of time. Timing is calibrated
against system resources and overall memory pressure.
Metal memory pressure will run higher than OpenGL, however,
this is an active decision to provide significant performance
improvements for scenarios which allocate lots of memory and
for keeping frames queued in flight without stalling on pending
GPU work.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108083
Certain textures require explicit HOST READ support for reading
data back to CPU. Given the compute based texture read path may
be used for this, if format conversion is required, this flag should
also imply general texture read support.
This resolves a bug with GreasePencil fill which relies on this.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108463
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
