This improves the existing scene specialisation mechanism by replacing "kernel_data.kernel_features" with a function constant. It doesn't cause any additional compilation requests, but allows the backend compiler to eliminate more dead code. An additional compiler hint is provided for dead-stripping "volume_stack_enter_exit" which results in slightly faster rendering of non-volumetric scenes.
Pull Request: https://projects.blender.org/blender/blender/pulls/142235
- Cursors in wayland are expected to use pre-multiplied alpha.
Note that cursor generators create straight alpha,
pre multiplier in the wayland backend.
- Invert cursor colors on Wayland since dark cursors are often default,
this could use dark theme settings in the future.
Support showing vector cursors at the appropriate size based on each
monitors DPI.
This solves incorrectly sized cursors with Hi-DPI outputs as well as
supporting outputs with different DPI's.
Instead of passing pixel data, pass an object that can generate cursors,
GHOST/Wayland can then ensure the correct size is used based on the
display the cursor is shown on.
While may sound overly complicated it actually simplifies displaying
cursors on Wayland, especially for multiple monitors at different DPI's.
Showing cursors at higher or lower resolutions than the monitor's DPI
also behaves differently on GNOME & Plasma, resulting in situations
where the cursor would show larger/smaller than expected.
Details:
- Take advantage of the recently added SVG cursors & BLF time cursor
!140990 & !141367.
- Setting bitmap cursors via GHOST_SetCustomCursorShape is now a no-op
for Wayland since it's no longer used. This was supported in an
earlier version of this PR and could be restored if needed.
- While fractional scaling works it relies on the compositor downscaling
the cursors. Ideally they would be rendered at the target size but
this isn't a priority as the difference isn't noticeable.
Ref !141597
When having a checkbox and a value both in one row together with an
animation decorator it is questionable whether the decorator should act
on animating the checkbox or the corresponding value.
We had similar cases before (e.g. 7c04ef210e)
In this case as well, one would think it is more desirable to animate
the actual Temperature **value** (instead of the checkbox), so this is
what this PR does.
Pull Request: https://projects.blender.org/blender/blender/pulls/142192
Cycles automatically tries to decide if the camera ray should be a
surface or a volume + surface camera ray by checking to see if the
scene contains a volumetric material, and if it does, is it near
where the camera rays are expected to spawn. This step is done
during scene intialization.
With the OSL camera, it is impratical to predict where the
camera rays will spawn during scene intialization, which makes it
impratical to predict if the OSL camera ray will spawn near a
volumetric object. So this commit marks all OSL cameras as
"inside a volume", leading to the spawning of volume + surface camera
rays for OSL cameras while the scene contains a volumetric material.
This leads to increased render times ranging between 1% - 5% in scenes
that use a OSL camera, has a volumetric object in it, and the
volumetric object is far away from the camera. Every other scene should
see no performance impact.
Testing was done on a AMD Ryzen 9 5950X and a NVIDIA GeForce RTX 4090.
Pull Request: https://projects.blender.org/blender/blender/pulls/142036
This is not an actual solution, it falls back to a perspective camera instead
of crashing. Note full_rastertocamera exists specifically for computing raster
size for adaptive subdivision, and changing it should not affect anything else.
Pull Request: https://projects.blender.org/blender/blender/pulls/141905
These changes introduce modifications to the SYCL queue creation
in OneapiDevice::create_queue. In case several DPC++ devices are
detected by Blender and exposed through it, we are now creating
a new SYCL context for each device, which allows us to prevent
execution failures due to some known issues in the DPC++ runtime
regarding multi GPU support. As this would have some small
performance impact, few percents, it is only applied to
multi GPU configurations, while the behavior for a single
GPU configuration remains the same.
Pull Request: https://projects.blender.org/blender/blender/pulls/141834
The Windows and Wayland platforms can both create antialiased mouse
cursors from SVG sources. Platforms with WM_CAPABILITY_CURSOR_RGBA
can therefore show a better version of "WM_cursor_time". Instead of
four blocky digits in two rows this displays beautiful digits in a
single row.
Pull Request: https://projects.blender.org/blender/blender/pulls/141367
Some Wintab drivers can randomly crash while loading. Guard against this
by catching such exceptions using SEH. Also save and restore the current
unhandled exception filter as some drivers replace it with their own for
some reason.
Pull Request: https://projects.blender.org/blender/blender/pulls/141685
Windows.h, otherwise we can get errors about the use of std::min
and std:max because of a conflict with macro definitions of "min"
and "max" in Windows.h. The reason for this being needed now and
not earlier is because of changes to an updated windows SDK
installed by a recent security update.
Pull Request: https://projects.blender.org/blender/blender/pulls/141696
On systems with multiple Intel GPUs with a mix of recent and old
unsupported drivers (such as 101.3302), the Level-Zero stack may have
troubles initializing, leading to a crash while enumerating devices.
Luckily this condition actually leads to an exception we can catch,
as implemented here in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/141674
Previously, we used precomputed Gaussian fits to the XYZ CMFs, performed
the spectral integration in that space, and then converted the result
to the RGB working space.
That worked because we're only supporting dielectric base layers for
the thin film code, so the inputs to the spectral integration
(reflectivity and phase) are both constant w.r.t. wavelength.
However, this will no longer work for conductive base layers.
We could handle reflectivity by converting to XYZ, but that won't work
for phase since its effect on the output is nonlinear.
Therefore, it's time to do this properly by performing the spectral
integration directly in the RGB primaries. To do this, we need to:
- Compute the RGB CMFs from the XYZ CMFs and XYZ-to-RGB matrix
- Resample the RGB CMFs to be parametrized by frequency instead of wavelength
- Compute the FFT of the CMFs
- Store it as a LUT to be used by the kernel code
However, there's two optimizations we can make:
- Both the resampling and the FFT are linear operations, as is the
XYZ-to-RGB conversion. Therefore, we can resample and Fourier-transform
the XYZ CMFs once, store the result in a precomputed table, and then just
multiply the entries by the XYZ-to-RGB matrix at runtime.
- I've included the Python script used to compute the table under
`intern/cycles/doc/precompute`.
- The reference implementation by the paper authors [1] simply stores the
real and imaginary parts in the LUT, and then computes
`cos(shift)*real + sin(shift)*imag`. However, the real and imaginary parts
are oscillating, so the LUT with linear interpolation is not particularly
good at representing them. Instead, we can convert the table to
Magnitude/Phase representation, which is much smoother, and do
`mag * cos(phase - shift)` in the kernel.
- Phase needs to be unwrapped to handle the interpolation decently,
but that's easy.
- This requires an extra trig operation in the kernel in the dielectric case,
but for the conductive case we'll actually save three.
Rendered output is mostly the same, just slightly different because we're
no longer using the Gaussian approximation.
[1] "A Practical Extension to Microfacet Theory for the Modeling of
Varying Iridescence" by Laurent Belcour and Pascal Barla,
https://belcour.github.io/blog/research/publication/2017/05/01/brdf-thin-film.html
Pull Request: https://projects.blender.org/blender/blender/pulls/140944
Supporting this on the Metallic BSDF will require some extra work,
and on the Glossy BSDF it doesn't make much sense conceptually
(for that kind of shader setup, we'll want to support layering in SVM),
but Glass BSDF just needs to be hooked up so might as well do that.
Pull Request: https://projects.blender.org/blender/blender/pulls/140832
Detect which volume attributes nodes have a linear mapping to their usage
as density / color / temperature in volume shader nodes, and use stochastic
sampling for them.
Pull Request: https://projects.blender.org/blender/blender/pulls/132908
Stochastically turn a tricubic filter into a trilinear one. This
reduces the number of taps from 64 to 8. It combines ideas from
the "Stochastic Texture Filtering" paper and our previous GPU
sampling of 3D textures.
This is currently only used in a few places where we know stochastic
interpolation is valid or close enough in practice.
* Principled volume density, color and temperature
* Motion blur velocity
On an Macbook Pro M3 with the openvdb_smoke.blend regression test
and cubic sampling, this gives a ~2x speedup for CPU and ~4x speedup
for GPU. However it also increases noise, usually only a little. Equal
time renders for this scene show a clear reduction in noise for both
CPU and GPU.
Note we can probably get a bigger speedup with acceptable noise trade-off
using full stochastic sampling, but will investigate that separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132908
All GPU backends now support NanoVDB, using our own kernel side code
that is easily portable. This simplifies kernel and device code.
Volume bounds are now built from the NanoVDB grid instead of OpenVDB,
to avoid having to keep around the OpenVDB grid after loading.
While this reduces memory usage, it does have a performance impact,
particularly for the Cubic filter. That will be addressed by
another commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/132908
