Age | Commit message (Collapse) | Author |
|
OSD Lists as 0, 0, 0 this is due to opensubdiv_capi.cc not actually including
the OSD version header, so it's not getting the version define, and the code
in openSubdiv_getVersionHex is really well prepared to deal with any or no
version at all of OSD, catches the problem and returns 0, 0, 0
Given this file is only build when OSD is enabled we can just blindly include
opensubdiv/version.h here
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D16398
|
|
Avoid relying on GHOST_ISystem::getSystem(), store the system instead.
|
|
|
|
wl_egl_window_resize ran when the window became active/inactive for e.g.
|
|
Nearly all Wayland window data is stored in this struct,
follow this convention so GWL_Window functions can be self contained.
|
|
Add low level gwl_window_* functions.
|
|
Regression in [0] causes LIBDECOR interactions not to be detected.
[0]: deb8ae6bd1edb0983d9ac972b2c95090f4c5e642
|
|
It wasn't so obvious which functions were part of the GHOST API
and which system functions were utilities.
This convention was already in place but not always followed.
|
|
Add a non-blocking version wrapper for wl_display_dispatch_pending.
This uses roughly the same logic as Wayland_PumpEvents in SDL.
Noticed this when investigating T100855.
Note that performing a round-trip doesn't seem necessary from looking
into QT/GTK & SDL event handling loops.
|
|
Some of the previous commits in Wayland related code added use
of this function, but did not update the dynamic loader. This
broke compilation of configurations which use dynamic loader
for Wayland (which is the official way oh how Blender is built).
|
|
Help troubleshooting T100855.
|
|
|
|
|
|
Currently only used for logging to help with debugging.
|
|
|
|
|
|
After barycentric convention changes, the differentials used for bump mapping
were wrong leading to artifacts with long thin triangles.
|
|
to scrub the timeline
rB67e23b4b2967 revealed the bug. But the bug already existed before,
it just wasn't triggered.
Apparently the problem happens because the python code generated in
`initGuiding()` cannot be executed twice.
The second time the `initGuiding()` code is executed, the local python
variables are removed to make way for the others, but the reference to
one of the grids in a `Solver` object (name='solver_guiding2') is still
being used somewhere. So an error is raised and a crash is forced.
The solution is to prevent the python code in `initGuiding()` from being
executed twice.
When `FLUID_DOMAIN_ACTIVE_GUIDE` is in `fds->active_fields` this
indicates that the pointer in `mPhiGuideIn` has been set and the guiding
is already computed (does not need to be computed again).
Maniphest Tasks: T102257
Differential Revision: https://developer.blender.org/D16416
|
|
|
|
If no OPTIX_ROOT is set, nvcc fails to compile because there is a stray "-I"
in the arguments. Detect if the include path is empty and act accordingly.
Differential Revision: https://developer.blender.org/D16308
|
|
|
|
On Ubuntu 20.04 running X11, there was this message on every Blender startup:
Unable to find 'wl_proxy_marshal_flags' in 'libwayland-client.so.0'.
The reason is that we build against Wayland protocols 1.21, which in turns requires
Wayland on the distribution to be 1.21+, which is not the case on Ubuntu 20.04.
This simply silences the warning. An improvement would be to explain the user that
their Wayland version is too old when neither X11 or Wayland can be found. Though
that's not trivial and a situation with old Wayland and no XWayland seems unlikely
to happen in practice.
Differential Revision: https://developer.blender.org/D16266
|
|
Seems to be introduced by 99e5024e97f.
The crash is caused by the difference in the expected alignment
of the `uiPopupMenu` which is 16 bytes and the actual alignment
returned by the `MEM_mallocN()` which is 8 bytes due to the memory
head.
Now made it so that `MEM_new()` can be used for types with any
alignment.
Differential Revision: https://developer.blender.org/D16375
|
|
|
|
|
|
|
|
Support layouts such as AZERTY where the shift key is held for number
keys. Text entry remains unchanged but these keys now activate shortcuts
as expected.
This matches a fix in X11 for the same problem: T47228.
|
|
|
|
Name surfaces for their use.
|
|
This isn't full multi-seat support, instead set the active seat using
pointer/tablet & keyboard enter handlers.
This means that seats beside the first aren't prevented from having
their events handled.
|
|
This can be used for example for VR video formats that use this projection
instead of perspective projection for cubemap faces.
Differential Revision: https://developer.blender.org/D13525
|
|
|
|
|
|
Missed clearing the tablet pointer after updating removing the tablet
manager.
|
|
Note issues with track-pad event handling, add some other notes too.
|
|
If opening a pipe failed, 'data_offer->dnd.in_use' wasn't cleared.
Avoid early return where it duplicates logic in an error prone way.
|
|
File level static variable names weren't well distinguished from others.
Use `ghost_wl_` prefix for static variables.
|
|
|
|
There wasn't much advantage in using C++ native types as all Wayland
API's deal with C strings.
|
|
It wasn't clear that this is only used for drag & drop,
also don't use an atomic type as all access is guarded by the
drag & drop mutex.
|
|
A copy of the clipboard was always being, changes would re-read it.
Now read the clipboard on request. This avoids having to keep a copy
of the clipboard in memory as well as the need to keep a thread
to running to read the clipboard for each data-offer.
To prevent a deadlock when pasting from Blender's own clipboard.
- Sending the clipboard (using write(..)) runs in a background thread.
- Reading the clipboard uses a thread that performs round-trips to the
Wayland server to prevent until the read is complete.
This is an update to [0] that resolves the deadlock.
[0]: c03838dbc8cc4a85cfc93914493a0f1562a53366
|
|
When the Wayland pipe can't be opened, don't leave the mutex locked.
Also skip checking wl_data_device_manager when reading from the primary
clipboard.
|
|
CYCLES_ONEAPI_ALL_DEVICES environment variable wasn't working as
intended after 305b92e05f748a0fd9cb62b9829791d717ba2d57.
|
|
wl_registry_destroy does not enjoy being fed a null pointer.
Added a null check to keep it out of trouble.
|
|
There were two issues caused by deferred registration (added by [0]),
one crash on startup (T102075), another unreported issue with the GLX/EGL
context failing to initialize. Unfortunately I'm unable to reproduce the
errors but it seems likely deferring interface registration is not well
supported so this commit uses an alternative solution to some interfaces
depending on others for initialization.
Instead of relying on the order of registration, a separate "update"
callback has been added which is called after binding interfaces.
This has the advantage that it can be called when adding/removing
interfaces at run-time to avoid the dangling pointers being left in
locally allocated structures. In practice adding/removing interfaces
happens so rarely (only with "outputs" as far as I'm aware) that this
benefit is theoretical at the moment.
This should resolve T102075.
[0]: 9fe9705bc0af9d881905d75957c8dd467f8c8cb3
|
|
Intel documentation for Ubuntu 22.04 does list all runtime components
needed by the driver and oneAPI Cycles device but end-users getting
drivers from (other) sources can easily end-up missing required
Level-Zero Loader and struggle root causing what's wrong in their
system. Calling this requirement out in the UI will hopefull help them.
oneAPI Level-Zero incl. Loader: https://github.com/oneapi-src/level-zero
Common package names: level-zero, level-zero-loader
|
|
This fixes a 15% performance regression silently introduced by
79ab76e156d4bde937335be784cdf220294600d5 that aligned the compact
float3 on 16 bytes for oneAPI.
Current change is minimalist, there are further cleanup opportunities
such as removing packed_float3 definition for oneAPI but for some
reason, it cuts the recovered speedup in half, so we're starting with
this small fix for now.
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D16340
|
|
This patch fixes T101790 by adding a macOS version check for deciding whether to show the caustics settings in the UI (MNEE kernels don't compile on macOS < 13.0)
Reviewed By: brecht
Maniphest Tasks: T101790
Differential Revision: https://developer.blender.org/D16339
|
|
This reverts commit c03838dbc8cc4a85cfc93914493a0f1562a53366.
Pasting from Blender's own clipboard locked the process.
This needs furhter investigation.
|
|
A copy of the clipboard was always being, changes would re-read it.
Now read the clipboard on request. This avoids having to keep a copy
of the clipboard in memory as well as the need to keep a thread
to running to read the clipboard for each data-offer.
|