MoltenVK is part of the vulkan SDK. Blender requires the vulkan SDK
to compile. This patch adds the MoltenVK includes and libraries to
the Vulkan includes and libraries.
This adds a vulkan backend to GHOST. The code was extracted from the
tmp-vulkan branch. The main difference with the original code is that
GHOST isn't responsible for fallback. For Metal backend there is already
an idea that the GPU module is responsible for the fallback, not the system.
For Blender we target Vulkan 1.2 at the time of this patch.
MoltenVK (needed to convert Vulkan calls to Metal) has been added as
a separate package.
This patch isn't useful for end-users, currently when starting blender with
`--gpu-backend vulkan` it would crash as the `VBBackend` doesn't initialize
the expected global structs in the GPU module.
Validated to be working on Windows and Apple. Linux still needs to be tested.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D13155
This resolves some issues with correlation artifacts at higher sample counts.
Fix T101356, correlation issues in new PMJ pattern.
Differential Revision: https://developer.blender.org/D16561
Commit c8dd33f5a37b6a6db0b6950d24f9a7cff5ceb799 in OSL changed behavior of
parameters that reference each other and are also overwritten with an
instance value. This is causing the "NormalIn" parameter of a few OSL nodes
in Cycles to be set to zero somehow, which should instead have received the
value from a "node_geometry" node Cycles generates and connects automatically.
I am not entirely sure why that is happening, but these parameters are
superfluous anyway, since OSL already provides the necessary data in the
global variable "N". So this patch simply removes those parameters (which
mimics SVM, where these parameters do not exist either), which also fixes
the rendering artifacts that occured with recent OSL.
While this fixes built-in shader nodes, custom OSL scripts can still have
this problem.
Ref T101222
Differential Revision: https://developer.blender.org/D16470
Regression in [0] which exposed a problem with GHOST_kGrabHide on Win32
and to some extent X11.
Prior to [0], walk mode used it's own warping logic (hiding the cursor
& recording the motion between events). Using GHOST's grabbing makes
sense in this case as it's not very convenient for operators to
implement their own cursor warping, however doing so exposed a problem
where the mouse cursor could leave the window.
This would happen because the cursor needed to be within 2px of the
screen edge before warping.
Resolve by warping within a small region in the middle of the window.
Note that warping to the window center on each motion would be ideal
but is more involved as the logic for Win32 & X11 doesn't work properly
when every motion warps, so this needs further investigation to support.
This problem doesn't apply to GHOST/Cocoa which warps every motion event
on the spot and GHOST/Wayland doesn't set the mouse position at all to
implement this functionality.
[0]: 4c4e8cc926
For some pixels with transparent surfaces, no depth value would be written
when sampling chooses a reflection/refraction BSDF instead of transparent
BSDF. Now ensure we always write at some some depth value to the pass.
This is still not ideal as the resulting depth values are noisy same as they
are for depth of field and motion blur, but at least there should be no gaps.
The issue here was that the Barbershop benchmark scene was saved with a
custom OCIO config, which leads to some textures having a unknown
colorspace when loading with a default installation.
This is automatically fixed by Blender during image loading, but since
Cycles queried the colorspace before actually loading the image, it
didn't get the updated value in the first render.
To fix this, just re-query the colorspace after the image is loaded.
Note that non-packed images still get treated as raw data if the
colorspace is unknown, but this is at least consistent and doesn't
magically change when you press F12 a second time.
Differential Revision: https://developer.blender.org/D16427
* Sort Training Samples first, since it affects both Surface and Volume guiding.
* Remove "Guiding" from Surface and Volume entries (UI only, the property
still has Guiding in the name)
Change reviewed in the render-cycles module channel.
This was previously needed due to poor compatibility between Visual Studio and
NVCC. But it has not been used for a while now as compatibility seems to have
improved.
The issue here was that the Barbershop benchmark scene was saved with a
custom OCIO config, which leads to some textures having a unknown
colorspace when loading with a default installation.
This is automatically fixed by Blender during image loading, but since
Cycles queried the colorspace before actually loading the image, it
didn't get the updated value in the first render.
To fix this, just re-query the colorspace after the image is loaded.
Note that non-packed images still get treated as raw data if the
colorspace is unknown, but this is at least consistent and doesn't
magically change when you press F12 a second time.
Differential Revision: https://developer.blender.org/D16427
Some of these functions should use locks although they didn't show up
as needing locks at runtime (using valgrind's helgrind), as some aren't
called often or aren't used at all. Add locks for correctness & to
prevent errors in the future.
- GHOST_SystemWayland::disposeContext
- GHOST_SystemWayland::getAllDisplayDimensions
- GHOST_SystemWayland::getButtons
- GHOST_SystemWayland::getMainDisplayDimensions
- GHOST_SystemWayland::getNumDisplays
- GHOST_WindowWayland::setWindowCustomCursorShape
libdecor has a workaround where creating the window would loop until
the windows configure callback ran.
Simplify this workaround by setting the initial state on the underlying
xdg_toplevel struct.
Also correct mixup between bool / GHOST_TSuccess types.
Cycles already treats denoising fairly separate in its code, with a
dedicated `Denoiser` base class used to describe denoising
behavior. That class has been fully implemented for OIDN
(`denoiser_oidn.cpp`), but for OptiX was mostly empty
(`denoiser_optix.cpp`) and denoising was instead implemented in
the OptiX device. That meant denoising code was split over various
files and directories, making it a bit awkward to work with. This
patch moves the OptiX denoising implementation into the existing
`OptiXDenoiser` class, so that everything is in one place. There are
no functional changes, code has been mostly moved as-is. To
retain support for potential other denoiser implementations based
on a GPU device in the future, the `DeviceDenoiser` base class was
kept and slightly extended (and its file renamed to
`denoiser_gpu.cpp` to follow similar naming rules as
`path_trace_work_*.cpp`).
Differential Revision: https://developer.blender.org/D16502
Avoid keeping allocated overly large events_pending vector in case of
long delays between processing events.
While in practice this isn't likely to cause problems, it's better to
avoid keeping unnecessarily large allocations.
Also remove invalid comment.
Consume events in a thread to prevent Wayland's event buffer from
overflowing Waylands internal buffer and closing the connection.
From a users perspective this seemed like a crash.
Details:
- This is a workaround for a known bug in Wayland [0].
Threaded event handling has been if-defed so it can be removed when
it's no longer needed.
- GTK & QT use threaded event handling to avoid this problem
(SDL on the other hand doesn't).
- The complexity and number of locks needed to handle events in a
separate thread is a significant down-side, but as far as I can see
this is necessary.
- Re-connecting to the Wayland server is possible but not practical as
the OpenGL context is lost and as far as I can tell it's not possible
to keep it active (see: D16492).
[0]: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
Using a single draw works in my tests and I couldn't reproduce the
issue noted in the comment.
Also apply minor cleanup, assigning a variable before calling methods to
reduce diff-noise in planned changes.
