Faster and better looking VSE scopes & "show overexposed". Waveform &
RGB Parade now can also show HDR color intensities. (Note: this is
only about VSE scopes; Image Space scopes are to be improved separately)
- Waveform, RGB Parade, Vectorscope scopes are done on the GPU now, by
drawing points for each input pixel, and placing them according to
scope logic. The point drawing is implemented in a compute shader,
with a fragment shader resolve pass; this is because drawing lots of
points in the same location is very slow on some GPUs (e.g. Apple).
The compute shader rasterizer is several times faster on regular
desktop GPU as well.
- If a non-default color management is needed (e.g. VSE colorspace is
not the same as display colorspace, or a custom look transform is used
etc. etc.), then transform the VSE preview texture into display space
RGBA 16F texture using OCIO GPU machinery, and calculate scopes
from that.
- The "show overexposed" (zebra) preview option is also done on the
GPU now.
- Waveform/Parade scopes unlock zoom X/Y aspect for viewing HDR scope,
similar to how it was done for HDR histograms recently.
- Added SEQ_preview_cache.hh that holds GPU textures of VSE preview,
this is so that when you have a preview and several scopes, each of
them does not have to create/upload their own GPU texture (that would
both waste memory, and be slow).
Screenshots and performance details in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/144867
This does a few things:
- Add support for templated struct.
- Change parsing of template scope.
Now all template scope `<..>` are parsed properly.
- Rework to support better match syntax.
- Avoid warning from scope guard processing. Now initialize
the return value to zero.
Pull Request: https://projects.blender.org/blender/blender/pulls/145132
This PR adds HDR support for Windows for `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT`
on `VK_FORMAT_R16G16B16A16_SFLOAT` swapchains .
For nonlinear surface formats (sRGB and extended sRGB) the back buffer is blit into the swapchain,
When VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT is used as surface format a compute shader
is used to flip and invert the gamma.
SDR white level is updated from a few window event changes, but actually
none of them immediately respond to SDR white level changes in the system.
That requires using the WinRT API, which we don't do so far.
Current limitations:
- Intel GPU support
- Dual GPU support
In the future we may add controls inside Blender for absolute HDR nits,
across different platforms. But this makes behavior closer to macOS.
See !144565 for details
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/144717
* Change meaning of display device to be the device that we are trying
to emulate, not the monitor configuration.
* The display transform is now:
* User specified view and display transform
* Clamp to 0 to limit colors to gamut
* Inverse untonemapped display transform
* Convert to extended sRGB
* When using the display space in the color management API, it now needs to
be specified if it's for drawing (with emulation) or file output or color
inspection (without).
Like HDR, this only works on macOS and Linux + Wayland + Vulkan currently.
Support for Windows/Vulkan is under development in #144717.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
Use the lately introduced parser for that.
This allows to use preprocessor directive inside them.
By extension, it alows having resource accessors inside
templates.
Also error report is less confusing on most shader compilers.
The counterpart is that the shader files that are shipped
with blender are inflated.
Pull Request: https://projects.blender.org/blender/blender/pulls/144588
This adds the following features:
- `class` keyword support: checked by C++, mutated to struct for shader.
- `private` and `public` keywords: checked by C++, removed for shader.
- `static` methods.
- `const` and non-const methods.
What is not supported:
- Constructors
- Destructors
- operators
- Method definition outside of class definition
- member reference without `this` keyword.
This is implemented using a very simple lexer/parser allowing semantic traversal.
Pull Request: https://projects.blender.org/blender/blender/pulls/144025
It allows to implement tricks based on a knowledge whether the path
ever cam through a portal or not, and even something more advanced
based on the number of portals.
The main current objective is for strokes shading: stroke shader
uses Ray Portal BSDF to place ray to the center of the stroke and
point it in the direction of the surface it is generated for. This
gives stroke a single color which matches shading of the original
object. For this usecase to work the ray bounced from the original
surface should ignore the strokes, which is now possible by using
Portal Depth input and mixing with the Transparent BSDF. It also
helps to make shading look better when there are multiple stroke
layers.
A solution of using portal depth is chosen over a single flag due
to various factors:
- Last time we've looked into it it was a bit tricky to implement
as a flag due to us running out of bits.
- It feels to be more flexible solution, even though it is a bit
hard to come up with 100% compelling setup for it.
- It needs to be slightly different from the current "Is Foo"
flags, and be more "Is Portal Descendant" or something.
An extra uint16 is added to the state to count the portal depth,
but it is only allocated for scenes that use Ray Portal BSDF.
Portal BSDF still increments Transparent bounce, as it is required
to have some "limiting" factor so that ray does not get infinitely
move to different place of the scene.
Ref #125213
Pull Request: https://projects.blender.org/blender/blender/pulls/143107
This includes a new list structure type and socket shape, a node
to create lists, a node to retrieve values from lists, and a node to
retrieve the length of lists. It also implements multi-function support
so that function nodes work on lists.
There are three nodes included in this PR.
- **List** Creates a list of elements with a given size. The values
are computed with a field that can use the index as an input.
- **Get List Item** A field node that retrieves an element from a
a list at a given index. The index input is dynamic, so if the input
is a list, the output will be a list too.
- **List Length** Just gives the length of a list.
When a function node is used with multiple list inputs, the shorter
lists are repeated to extend it to the length of the longest.
The list nodes and structure type are hidden behind an experimental
feature until we can be sure they're useful for an actual use case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140679
This was caused by the hardware derivatives output being affected
by render resolution. Scaling them back to the full resolution
value fixes the issue.
This also fixes the Wireframe node that also relies on derivatives.
Pull Request: https://projects.blender.org/blender/blender/pulls/142101
This initial commit properly clamps handles for video/audio strips, and
provides functionality to enable/disable the behavior for all strip types
(addresses #90280).
Toggling handle clamping is done with "C",
just like with the redesigned slip operator (#137072).
If a strip is not already clamped when you start moving its handles,
then clamping behavior is disabled starting out. This means no abrupt
clamp until you explicitly ask for it.
Transform logic was altered, fixing a few bugs:
- When initializing a transform, `createTransSeqData` would already
create some clamping data for channels. This patch replaces it with
`offset_clamp` (for unconditional clamping which cannot be disabled)
and `handle_xmin/xmax` (for hold offset clamping, which is optional).
- Collecting this data ahead of time is necessary for the double
handle tweak case -- `flushTransSeq` only works one strip at a
time, so we can't clamp post-hoc.
- In `applySeqSlideValue`, we apply `transform_convert_sequencer_clamp`
before values are printed to the header, but let the unclamped values
get flushed to the strips themselves. This is so that we can have the
data later at the individual strip level to recalculate clamps.
Otherwise, if transform values are clamped preemptively, then we have
no idea whether strips are clamped vs. merely resting at their
boundaries.
Note that currently, handle clamping is drawn identically to overlaps.
More information in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/134319
This was because the display shader never did the correct
color transformation.
This is a risky fix as it expects all input texture to be in
the correct colorspace (srgb). If they aren't this will
produce darker result.
If this is a huge issue we can introduce a global setting
(like line width) to set if the attached texture is
in srgb space or linear. This would avoid to change the
drawing code all over the place.
Pull Request: https://projects.blender.org/blender/blender/pulls/141237
In Blender 3.3 (1) the individual combine and separate color nodes were
combined together into a single combine/separate color node.
To ensure legacy addons still worked, the old nodes were left in
Blender, but hidden from the Add menus.
It has been nearly 3 years since that change was made, most if not all
addons should have been updated by now. So this commit removes these
hidden legacy nodes.
(1) blender/blender@82df48227b
Pull Request: https://projects.blender.org/blender/blender/pulls/135376
The 2D->2D, 3D->3D, 4D->4D hash functions used in Voronoi node were
using quite an expensive hash function. Switch these to dedicated
2D/3D/4D hash functions (pcg2d, pcg3d, pcg4d) -- these are still very
good quality, but the hash function itself is 3x-4x faster.
Which makes Voronoi node calculation overall be around 2x faster. In
some cases when using OSL, the speedup is even larger.
This visibly changes output of the Voronoi noise however. The actual
noise "behaves" the same, just if someone was depending on the noise
pattern being exactly like it was before, this will change the pattern.
Images, more performance results and details wrt OSL are in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/139520
This patch removes the older handle selection and transformation logic,
which was accessible through user preferences by switching off the
default "simple tweaking" mode in Editing -> Video Sequencer.
There was some initial bugginess with the new handle behavior, hence
the option to revert to legacy mode, but with recent updates this no
longer applies. With the new system, all selection workflows
are still possible -- this just drops older code to make things simpler.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/140031
This works by wrapping the entry point call inside a
`main` function.
Since resources are still defined in global space,
function accessing these are marked with a custom
attribute. This custom attribute expands in a
`#ifdef` guard for the matching stage.
This is a temporary solution and will eventually
be lifted once we support SRD.
### TODO
- [ ] Implement `[[gpu::vertex/fragment_function]]`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139233
Compilation constants are constants defined in the create info.
They cannot be changed after the shader is created.
It is a replacement to macros with added type safety.
Reuse most of the logic from Specialization constants.
Pull Request: https://projects.blender.org/blender/blender/pulls/139703
This PR adds builtin shaders for drawing points. Using `FLAT_COLOR`,
`SMOOTH_COLOR`, `UNIFORM_COLOR` can lead to undesired behavior
on Metal and Vulkan backends. To ensure future compatibility this PR
adds `POINT_FLAT_COLOR` and `POINT_UNIFORM_COLOR`.
The point size can be set using `gpu.state.point_size_set`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139583
Implementation of #127106.
This is just a visual representation of the field/single/grid
status of sockets to make the workflow more intuitive. With
a visual representation for volume grid sockets, volume features
should be unblocked for further development. The structure type
will also be used to distinguish list sockets in the interface.
Group input nodes now have a "Structure Type" option instead of
the existing "Single Value Only". Usually the auto option should be
enough, but in some cases where the inferencing cannot (yet) make
a clear determination, it can be helpful to choose a specific type.
The new visualization and the group input structure type option
are hidden behind a new experimental option for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/134811
This was caused by the removal of some compatibility code
in the metal backend.
This patch reintroduce this compatibility code in a cleaner
way than before.
This should be followed up by a documentation commit that
explains what is supported and what is not.
Pull Request: https://projects.blender.org/blender/blender/pulls/139185
This commit finishes removing the uses of the integer to float
vertex buffer fetch mode. Previous commits noted below already started
that process. The last usage was geometry attributes. Now integers are
converted to floats as part of the existing upload process.
The change makes the Vulkan vertex buffer type conversion unused, so
it's removed. That's nice because Vulkan vertex buffers go from 1040 to
568 bytes in size and have significantly less overhead on creation.
Related:
- 153abc372e
- 1e1ac2bb9b
- 617858e453
Pull Request: https://projects.blender.org/blender/blender/pulls/138873
Caused by 617858e453.
These formats should use types aligned to 4 bytes. That's generally
required by modern GPUs. Uploading with these types also avoids
automatic conversion by the Vulkan backend which is something
we're hoping to remove fully.
In the end this PR removes a bunch of code related to supporting
the older single-byte formats.
Pull Request: https://projects.blender.org/blender/blender/pulls/138836
Add a new shader node to control volume coefficients (scattering,
absorption and emission) directly, making it easier to model existing
volumes with measured data.
Pull Request: https://projects.blender.org/blender/blender/pulls/136287
Allows basic usage of templated functions.
There is no support for templated struct.
Benefit:
- More readable than macros in shader sources.
- Compatible with C++ tools.
- More sharing possible with host C++ code.
Requirements/Limitations:
- No default arguments to template parameters.
- Must use explicit instantiation for all variant needed.
- Explicit instantiation needs to **not** use argument deduction.
- Calls to template needs to have all template argument explicit
or all implicit.
- Template overload is not supported (redefining the same template
with different template argument or function argument types).
Currently implemented as Macros inside the build-time pre-pocessor,
but that could change to copy-paste to allow better error reporting.
However, the Macros keep the shader code reduced in the final binary
and allow different file to declare different instantiation.
The implementation is done by declaring overloads for each explicit
instantiation.
If a template has arguments not present in function
arguments, then all arguments **values** are appended to the
function name. The explicit template callsite is then modified to use
`TEMPLATE_GLUE` which will call the correct function. This is
why template argument deduction is not supported in this case.
Rel #137446
Pull Request: https://projects.blender.org/blender/blender/pulls/137441
This adds basic unrolling support for 2 syntax:
- `[[gpu::unroll]]` which does full loop unrolling
- `[[gpu::unroll(x)]]` which unrolls `x` iteration
Nesting is supported.
This change is motivated by the added cost in compilation
and execution time that some loops have even if they have
compile time defined iteration counts.
The syntax is inspired by `GL_EXT_control_flow_attributes`.
However, we might want to have our own prefix to show it is
a blender specific feature and that it differs from the standard.
I propose `[[gpu::unroll]]`.
In the future, we could extend this to support more directives that
can be expanded to backend specific extension / syntax. This would
avoid readability issue an error prone copy paste of large amount
of preprocessor directives.
Currently, given that GL's GLSL flavor doesn't support
any of these attributes, the preprocessor does some copy-pasting
that does the unrolling at the source level. Note that the added
`#line` allow for correct error logging.
For the `[[gpu::unroll]]` syntax, the `for` declaration
needs to follow a specific syntax to deduce the number
of loop iteration.
This variant removes the continue condition between iteration,
so all iterations are evaluated. This could be modified
using a special keyword.
For the `[[gpu::unroll(n)]]` syntax, the usercode needs
to make sure that `n` is large enough to cover all iterations
as the loop is completely removed.
We could add shader `assert` to make sure that there is
never a remaining iteration.
This behavior is usually different from what you see in other
implementation as we do not keep a loop at all. Usually, compilers
still keep the loop if it is not unrolled fully. But given we don't
have IR, this is the best we can do.
`break` and `continue` statement are forbidden at the unrolled loop
scope level. Nested loop and switch can contain these keywords.
This is accounted for by checks in the pre-processor.
Only `for` loops are supported for now. There are no real
incentive to add support for `while` given how rare it is
in the shader codebase.
Rel #137446
Pull Request: https://projects.blender.org/blender/blender/pulls/137444
This avoid having to guards functions that are
only available in fragment shader stage.
Calling the function inside another stage is still
invalid and will yield a compile error on Metal.
The vulkan and opengl glsl patch need to be modified
per stage to allow the fragment specific function
to be defined.
This is not yet widely used, but a good example is
the change in `film_display_depth_amend`.
Rel #137261
Pull Request: https://projects.blender.org/blender/blender/pulls/138280
Previously spell checker ignored text in single quotes however this
meant incorrect spelling was ignored in text where it shouldn't have
been.
In cases single quotes were used for literal strings
(such as variables, code & compiler flags),
replace these with back-ticks.
In cases they were used for UI labels,
replace these with double quotes.
In cases they were used to reference symbols,
replace them with doxygens symbol link syntax (leading hash).
Apply some spelling corrections & tweaks (for check_spelling_* targets).
This makes no sense to have in the draw namespace.
Also take the opportunity for making the coordinates
a float2 and rename them to something more descriptive.
