Defer creating events until the "frame" callback runs to ensure
the tablet state has been fully updated before the events are created.
This also avoids redundant motion events which are now only sent
when the motion/pressure or tilt callbacks run.
This commit aim at making the behaviors of `BLI_rename` and
`BLI_rename_overwrite` more consistent and coherent across all
supported platforms.
* `BLI_rename` now only succeeds in case the target `to` path does not
exists (similar to Windows `rename` behavior).
* `BLI_rename_overwrite` allows to replace an existing target `to` file
or (empty) directory (similar to Unix `rename` behavior).
NOTE: In case the target is open by some process on the system, trying
to overwrite it will still fail on Windows, while it should succeed on
Unix-like systems.
The main change for Windows is the usage of `MoveFileExW`
instead of `_wrename`, which allows for 'native support' of file
overwrite (using the `MOVEFILE_REPLACE_EXISTING` flag). Directories
still need to be explicitly removed though.
The main change for *nix systems is the use of `renamex_np` (OSX) or
`renameat2` (most Linux systems) to allow forbidding renaming to an
already existing target in an 'atomic' way.
NOTE: While this commit aims at avoiding the TOC/TOU problem as
much as possible by using available system's primitives for most
common cases, there are some situations where race conditions
(filesystem changes between checks on FS state, and actual rename
operation) remain possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/115096
When using multiple keyboard layouts, the first layout would always
be used for internal keyboard layout queries.
This meant for e.g. with English layouts QWERTY & DVORAK both active
Control-C always used the QWERTY location for C even when DVORAK was
active.
Resolve by detecting layout changes & run xkb_state_update_mask
on all xkb_state's so internal queries always use the active layout.
Based on !115161, extended to detect layout changes & account for all
internal states.
Co-authored-by: Eugene Kuznetsov <eugene.kuznetsov@amd.com>
While this code is suspect, better to go back to the old state for now,
as there is no simple fix that doesn't introduce other issues.
Fix#115022Fix#115414
This reverts commit 063a9e8964.
This change adds timeline semaphores to track submissions. The previous
implementation used a fence.
Timeline semaphores can be tracked in more detail as it is an counter.
For each submission the counter can be stored locally and when waiting
for completion the counter can be retrieved again and checked if is
known to be succeeded by a higher value.
The timeline semaphore is stored next to the queue and can also be used
to synchronize between multiple contexts.
Pull Request: https://projects.blender.org/blender/blender/pulls/115357
Currently all buffer types were stored in host memory, which is visible to the GPU as well.
This is typically slow as the data would be transferred over the PCI bus when used.
Most of the time Index and Vertex buffers are written once and read many times so it makes
more sense to locate them on the GPU. Storage buffers typically require quick access as they
are created for shading/compute purposes.
This PR will try to store vertex buffers, index buffers and storage buffers on device memory
to improve the performance.
Uniform buffers are still located on host memory as they can be uploaded during binding process.
This can (will) reset the graphics pipeline triggering draw calls using unattached resources.
In future this could be optimized further as in:
* using different pools for allocating specific buffers, with a fallback when buffers cannot be
stored on the GPU anymore.
* store uniform buffers in device memory
Pull Request: https://projects.blender.org/blender/blender/pulls/115343
The side effect which wasn't that obvious from the documentation
is that tasks in the console pool are executed sequentially. This
made the compile-gpu step to take a long time, because the parallel
compilation got disabled.
That was unintended change, so reverting the change.
Instead, for the buildbot, increase the time limit for the step.
This reverts commit 4b891b4afe.
This add the displacement option to EEVEE materials.
This unifies the option for Cycles and EEVEE.
The displacement only option is not matching cycles
and not particularly useful. So we decided to not
support it and revert to displacement + bump.
Pull Request: https://projects.blender.org/blender/blender/pulls/113979
This PR shows the memory footprint in the statusbar when activated.
Only memory allocated on the VRAM is counted. Memory allocated on host
memory is not counted.
Pull Request: https://projects.blender.org/blender/blender/pulls/115184
OpenImageDenoise V2 comes with GPU support for various backends. This adds a new class, OIDNDenoiserGPU, in order to add this functionality into the existing Cycles post processing pipeline without having to change it much. OptiX and OIDN CPU denoising remain as they are. Rendering on a supported Intel GPU will automatically select the GPU denoiser.
Device support is initially limited to the oneAPI devices that are supported by Cycles, but can be extended.
Ref #115045
Co-authored-by: Stefan Werner <stefan.werner@intel.com>
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/108314
The current code ran afoul of various arithmetic overflow conditions
when attempting to either Copy out or Paste in large images that would
overflow either the naive `w * h * 4` expression or the size of what the
DibV5 header allowed (DWORD, uint32_t).
Pull Request: https://projects.blender.org/blender/blender/pulls/115018
This path merges the Musgrave and Noise Texture nodes into a single
combined Noise Texture node. The reasoning is that both nodes
intrinsically do the same thing, which is the layering of Perlin noise
derivatives to produce fractal noise. So the patch de-duplicates code
and unifies the use of fractal noise for the end use.
Since the Noise node had a Distortion input and a Color output, while
the Musgrave node did not, those are now available to the Musgrave types
as new functionalities.
The Dimension input of the Musgrave node is analogous to the Roughness
input of the Noise node, so both inputs were unified to follow the same
behavior of the Roughness input, which is arguable more intuitive to
control. Similarly, the Detail input was slightly different across both
nodes, since the Noise node evaluated one extra layer of noise. This was
also unified to follow the behavior of the Noise node.
The patch, coincidentally fixes an unreported bug causing repeated
output for certain noise types and another floating precision bug
#112180.
The versioning code implemented with this patch ensures backward
compatibility for both the Musgrave and Noise Texture nodes. When
opening older Blender files in Blender 4.1 the output of both nodes are
guaranteed to always be exactly identical to that of Blender files
created before the nodes were merged in all cases.
Forward compatibility with Blender 4.0 is implemented by #114236.
Forward compatibility with Blender 3.6 LTS is implemented by #115015.
Pull Request: #111187
Empty hair geometry in Cycles may still report having one curve, even when
there are no actual segments in that curve. This caused an attempt to build
an acceleration structure with zero primitives, which due to other setup
OptiX rejected with an error. Fix that by checking the number of segments
rather than the number of curves in the hair geometry, since the former will
always be zero for empty geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/115044
Different from most layouts. The Turkish keyboard layout treats the `i` as the lowercase `İ` and the `ı` as the lowercase `I`.
So we have 2 different types of i: `ı` and `İ`. And two different I key positions on the keyboard.
This key with a different position is mapped as special and returns the corresponding `event->type` of the US keyboard `"` (`EVT_QUOTEKEY`).
The apparently most appropriate event for this key would be `EVT_IKEY`.
This type of change needs to be treated with care, as it may alter other shortcuts that are already common to Turkish users.
Pull Request: https://projects.blender.org/blender/blender/pulls/114917
