Previously, code related to reading/writing movie files via ffmpeg was
scattered around: some under blenkernel, some directly in generic
imbuf headers, some under intern/ffmpeg. Some of the files were named
with not exactly clear names. Some parts not directly related to movies
were including ffmpeg headers directly (rna_scene.cc).
What is in this PR:
Movie and ffmpeg related code is now under imbuf/movie:
- IMB_anim.hh: movie reading, proxy querying, various utility functions.
- IMB_movie_enums.hh: simple enum definitions,
- IMB_movie_write.hh: movie writing functions.
- intern: actual implementation and private headers.
- ffmpeg_compat.h: various ffmpeg version difference handling
utilities,
- ffmpeg_swscale.hh/cc: scaling and format conversion utilities
for ffmpeg libswscale,
- ffmpeg_util.hh/cc: misc utilities related to ffmpeg,
- movie_proxy_indexer.hh/cc: proxies and timecode indexing for movies,
- movie_read.hh/cc: decoding of movies into images,
- movie_write.cc: encoding of images into movies.
- tests: basic ffmpeg library unit tests that previously
lived under intern/ffmpeg.
Interface changes (at C++ level, no Python API changes):
- Mostly just movie related functions that were BKE_ previously, are now IMB_.
- I did one large-ish change though, and that is to remove bMovieHandle
struct that had pointers to several functions. Now that is
IMB_movie_write_begin, IMB_movie_write_append, IMB_movie_write_end
functions using a single opaque struct handle. As a result, usages
of that in pipeline.cc and render_opengl.cc have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132074
This commit introduces proper handling of ROCm 5 and ROCm 6 runtimes on
Linux, based on the version of the ROCm compiler used at build time.
Previously, HIPEW (the HIP equivalent of Cuda Wrangler) defaulted to
loading the ROCm 5 runtime. If ROCm 5 was unavailable, it would attempt
to load ROCm 6. However, ROCm 6 introduces changes in certain
structures and functions that are not backward compatible, leading to
potential issues when kernels compiled with the ROCm 6 compiler are
executed on the ROCm 5 runtime.
### Summary of Changes:
**Separation of Structures and Functions:**
Structures and functions are now separated into hipew5 and hipew6 to
accommodate the differences between ROCm versions.
**Build-Time Version Detection:**
The ROCm version is determined during build time, and the corresponding
hipew5 or hipew6 is included accordingly.
**Runtime Default to ROCm 6:**
By default, HIPEW now loads the ROCm 6 runtime and
includes hipew6 (Linux only).
**JIT Compilation Behavior:**
Since ROCm 6 is the default version, JIT compilation is supported only
when the ROCm 6 compiler is detected at runtime.
**HIP-RT Update:**
HIP-RT has been updated to load the ROCm 6 runtime by default.
These changes ensure compatibility and stability when switching
between ROCm versions, avoiding issues caused by runtime
and compiler mismatches.
Co-authored-by: Alaska <alaskayou01@gmail.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130153
Blender can be started headless. In that case GHOST will use
GHOST_SystemHeadless. This system only supported OpenGL. This change
will add support for Vulkan. For users this allows to render using
Vulkan without the need of X11 or Wayland.
This should fix the cause why Vulkan tests are crashing on build-bot. They
will not work reliable due to a threading issue which is still in investigation.
Pull Request: https://projects.blender.org/blender/blender/pulls/131682
When a scene contains distant lights and local lights, the first step
of the light tree traversal is to compute the importance of
distant lights vs local lights and pick one based on a random number.
In the specific case of when there is only one distant light,
the line of code that had been changed in this commit
effectively reduced to:
`min_importance = fast_cosf(x) < cosf(x) ? 0.0 : compute_min_importance`
And depending on the hardware, compiler, and the specific value being
tested, different configurations could take different code paths.
This commit fixes this issue by turning the comparison into
`fast_cosf(x) < fast_cosf(x)`.
---
Why does `cos_theta_plus_theta_u < cosf(bcone.theta_e - bcone.theta_o)`
reduce to `fast_cos(x) < cos(x)` in this specific case?
- `cos_theta_plus_theta_u` is computed as
`cos_theta * cos_theta_u - sin_theta * sin_theta_u`
- `cos_theta` is always 1.0 in the case of a single distant light.
- `cos_theta_u` is computed earlier as `fast_cosf(theta_e)` in
`distant_light_tree_parameters()`
- `sin_theta` is zero, and so that side of the equation doesn't matter.
This reduces `cos_theta_plus_theta_u` to `fast_cosf(theta_e)`.
`cosf(bcone.theta_e - bcone.theta_o)` reduces to `cosf(bcone.theta_e)`
because for the case of a single distant light `theta_o` is always 0.
Pull Request: https://projects.blender.org/blender/blender/pulls/131932
On Linux, Cycles HIP has a JIT compilation feature.
This feature is used when Cycles can not find a precompiled kernel
for your GPU. Which is most common when using hardware that wasn't
out at the time that a version of Blender was released.
There were various issues with this JIT compilation system, this commit
aims to solve them. The changes include:
- Enable `WITH_NANOVDB` when Blender is built with NanoVDB.
- This fixes a issue where VDB objects would not render.
- Enable some extra debug options for developers when desired
(This is so we match the CUDA implementation of the same feature).
- Reduce the optimizaiton level from -O3 to the default.
- This is to avoid any extra issues that may occur as a result
of an increase optimization level that isn't tested with
precompiled kernels.
- Reduce the optimization level even further to -O1 for Vega.
- This was done on precompiled kernels to work around some issues,
so I decided to apply it to JIT kernels as well.
- Note: Although Vega is not officially supported, this may help
people that unofficially use Vega.
- Added some previously missing compiler arguments and fixed errors that
were introduced when enabling these compiler arguments.
- Fixed a issue where JIT compilation would fail if Blener was
installed in a path that had a space in it.
Pull Request: https://projects.blender.org/blender/blender/pulls/131853
Previous implemenation of 5 < d < 50 was taken from the main paper,
fitting for smaller sizes are found in the supplemental. They are less
forward-scattering.
Pull Request: https://projects.blender.org/blender/blender/pulls/130234
`GHOST_kUserSpecialDirCaches` was using `xdg-user-dir` to get home dir,
however in some linux distributions `xdg-user-dir` may not be available
by default. Thus use `getenv("HOME")` instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/131780
`CLOSURE_WEIGHT_CUTOFF` avoids allocating a closure when its weight is
too small. It makes sense for surface closures, but for volume closures
the contribution also depends on the object size/ray length, such a
cutoff seems random and is causing problem in atmospheric scatterings.
Therefore remove the cutoff for volume, just make sure the weight is
positive.
Pull Request: https://projects.blender.org/blender/blender/pulls/131696
The original paper uses the single scattering albedo `sigma_s/sigma_t`
to pick a channel for sampling the scattering distance. However, this
only considers the situation where there is scattering inside the volume.
If some channel has an extinction coefficient of zero, the light passes
through without attenuation for that channel. We assign such channel
with a weight of 1 instead of 0 to make sure it can be sampled.
Pull Request: https://projects.blender.org/blender/blender/pulls/131741
When processing volume names for the File Browser sidebar lists we are
properly handling Windows "wide" characters (UTF-16) as long as they
are single wide characters, so below U+FFFF. For characters above this
value we get a pair of UTF-16, and end up trying to convert each to
UTF-8 as separate UTF-32 values. The result is blank output and a
console error that "surrogates not allowed." This PR just does this
conversion correctly using utfconv.
Pull Request: https://projects.blender.org/blender/blender/pulls/131763
The cause is numerical issues with `fast_sinf()`. While fixing
`fast_sinf()` would ultimately fix the problem, it involves more
complications in other code paths, and it is safer to clamp the
integration range anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/131689
The original OSL Shading System API was stateful: You'd create a shader
group, configure it, and then end it. However, this means that only one
group can be created at a time. Further, since Cycles reuses the
Shading System for multiple instances (e.g. viewport render and
material preview), a process-wide mutex is needed.
However, for years now OSL has had a better interface, where you
explicitly provide the group you refer to. With this, we can not only
get rid of the mutex, but actually multi-thread the shader setup even
within one instance.
Realistically, most time is still spent in the JIT stage, but it's
still better than nothing.
Pull Request: https://projects.blender.org/blender/blender/pulls/130133
Before, we'd just zero out the memory of the struct and then set the
defaults afterwards, but that:
- Prevents us from storing non-POD types
- Silently assumes that array<float> is safe to zero out (it currently
is, but that is still ugly and risky)
- Bloats the code since every non-zero entry now needs two lines
So, just make use of C++11 here. All the default values that were
previously unset are taken from the Blender-side defaults.
Pull Request: https://projects.blender.org/blender/blender/pulls/130870
This commit fixes a pretty long-standing bug in the X11 clipboard code
which caused selection target requests (and thus pasting) to sometimes
fail on certain softwares like Firefox.
The problem lied in the fact that the property format used when setting
the supported target list was dependent on the original request, when
it should always be XA_ATOM (a list of Atom), this can be seen in other
implementations, like GLFW.
This commit also cleans up the surrounding code, by using m_atom to
access atoms instead of redeclaring them in the function, which also
clears up a few instance where the difference between `xse->target`
(the request target) and `target` (the TARGETS Atom) was really unclear.
Pull Request: https://projects.blender.org/blender/blender/pulls/131507
In OpenGL the last vertex is the provoking vertex. In Vulkan the first
vertex is the provoking vertex. This PR uses `VK_EXT_provoking_vertex`
to use the last vertex as the provoking vertex.
Pull Request: https://projects.blender.org/blender/blender/pulls/131412
This PR fixes#130641. The bug was caused by a missing self-object constraint when performing SSS on motion blur scenes. scene_intersect_local tests were erroneously hitting other objects, and out of range primitive IDs were causing spurious downstream behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/131156
GPU and GHOST require to have identical checks to remove faulty drivers.
When not done GHOST can still select a device that isn't supported and
lead to freezing interfaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/131241
Its not standard how `Present Engines` return images for presentation, and
currently is expected that they cycle between swap-chain images with each
`vkAcquireNextImageKHR` call.
However present engines could return any available image, that can mean
to reuse the last presented one if available. (This seem to be the behavior
using `Layered on DXGI Swapchain` the default `Present Method` used
with latest NVIDIA drivers on Windows).
Since resource pools expects to images to cycle in a sequential order, if any
present engine always return the same image for presentation only a single
resource pool would be used for each rendered frame, and since resources
are only released by cycling between resource pools, this resource pool would
overflow since it never releases any resource.
This changes makes resource pools to cycle each time a image is presented.
Pull Request: https://projects.blender.org/blender/blender/pulls/131129
This logic is copied from surface shader, so that the sampled closure
does not need to be evaluated twice when summing all the closures, but
it is not used in volume.
Remove assert statement from make_update.py, making it ready for any
architecture.
Add riscv 32, 64 and 128 bit cpu architecture with little/big endian
to Blender's BLI_build_config.h and Libmv's build_config.h
Tested (to compile) on riscv64 little endian machine.
Pull Request: https://projects.blender.org/blender/blender/pulls/130920
On the Windows platform allow pasting an image into the Image Editor
based on a filepath in the clipboard. For example, selecting "copy" on
the context menu in the file system. This checks for CF_HDROP format
and should work for all image formats we support.
Pull Request: https://projects.blender.org/blender/blender/pulls/127782
Videos files recorded on most phones were coming in sideways; files
recorded on some laptop cameras were coming in upside down. In both
cases the display_matrix metadata of the video stream was not applied.
This required changing internal container format of movie proxies to
be MP4 instead of AVI, since AVI does not support rotation metadata.
File extension kept at ".avi" to not disturb existing expectations.
It might be better to "bake" rotation into proxies while building them,
but right now we do not have a trivial way of doing that.
Note that this is a potential behavior change; if someone
already had manually rotated video strips, they would have
to undo that rotation now.
Pull Request: https://projects.blender.org/blender/blender/pulls/130455
Based on #123377 by @brecht, but Gitea doesn't like the rebase these
so here's a new PR.
The purpose here is to switch to fused OptiX programs for OSL execution
on CUDA. On the one hand, this makes the code easier since, but there's
also another advantage - how memory allocation is managed.
OSL shaders need memory to store intermediate values, but how much is
needed depends on the complexity of the shader. With the split program
approach, Cycles had to provide that memory, so we had to allocate a
certain amount (2 KiB, to be precise) statically and show an error if
the shader would need more. If the shader used less (which is the case
for the vast majority), the memory was just wasted.
By switching to fused kernels, OSL knows the required amount during JIT
codegen, so it can allocate only what's required, which avoids this
waste. One still needs to set a maximum, and in theory, OSL would also
support spilling over into a Cycles-provided alternative memory region.
However, we currently don't implement that - instead, we default to the
same 2048 limit as before and let advanced users override it via the
CYCLES_OSL_GROUPDATA_ALLOC environment variable if really needed.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130149
The `poll()` function for `CYCLES_PT_context_material` was using the
legacy `GPENCIL` identifier as opposed to `GREASEPENCIL`. This caused
duplicated material templates to show in the material tab.
Pull Request: https://projects.blender.org/blender/blender/pulls/130962
When making a `headless` macOS build, linking would fail complaining
about missing `GHOST_ContextCGL` symbols, which are required by the Metal
backend. This commit fixes this issue by compiling the macOS CGL GHOST
Context if the Metal backend is enabled, instead of only depending on
`WITH_HEADLESS`, similarly to what's done on Linux/other *nix systems.
Pull Request: https://projects.blender.org/blender/blender/pulls/130847
The converter is an abstraction that takes a base mesh to be subdivided
and provides its topology information to the OpenSubdiv library. It does
this with one level of indirection: first extracting the base mesh
topology with a virtual function call per element to local arrays,
then giving the information in those arrays to OpenSubdiv.
That level of indirection also handles cache invalidation for the
intermediate data structures which optimize repeated subdivisions of a
changing base mesh with constant topology. However, these days the mesh
data is stored with simpler to compare data arrays, and we also have
implicit sharing which provides another way to detect unchanged
shared data.
As a very first step to a design where we use OpenSubdiv more directly
and don't store duplicate topology arrays for the base mesh, this PR
provides the converter with the mesh's face offsets array directly
rather than using function calls. For multires reshape the temporary
format is changed to match.
Next steps will do the same thing for face vertices ("corner verts" in
Blender lingo), edges, and creases. Then we can remove the "converter"
indirection completely, then we can work on a better cache invalidation
strategy using implicit sharing. That's a ways off though. On its own,
this PR should just reduce function call overhead a bit.
Reference #130917.
Pull Request: https://projects.blender.org/blender/blender/pulls/130241
When resizing window some platforms could freeze. The cause was that
depending on a platform the swap chain could get out of date when
acquiring the next swapchain image or when presenting the swap chain
image to the queue.
We only covered one scenario. This PR implements the scenario to
recreating the swap chain when the image could not be acquired.
Pull Request: https://projects.blender.org/blender/blender/pulls/130909
Dynamic rendering is a Vulkan 1.3 feature. Most platforms have support
for them, but there are several legacy platforms that don't support dynamic
rendering or have driver bugs that don't allow us to use it.
This change will make dynamic rendering optional allowing legacy
platforms to use Vulkan.
**Limitations**
`GPU_LOADACTION_CLEAR` is implemented as clear attachments.
Render passes do support load clear, but adding support to it would
add complexity as it required multiple pipeline variations to support
suspend/resume rendering. It isn't clear when which variation should
be used what lead to compiling to many pipelines and branches in the
codebase. Using clear attachments doesn't require the complexity
for what is expected to be only used by platforms not supported by
the GPU vendors.
Subpass inputs and dual source blending are not supported as
Subpass inputs can alter the exact binding location of attachments.
Fixing this would add code complexity that is not used.
Ref: #129063
**Current state**
Pull Request: https://projects.blender.org/blender/blender/pulls/129062
Turns out that with `-fassociative-math`, GCC turns
`(1.0f - cos_NH2) + alpha2 * cos_NH2` into
`cos_NH2 * (alpha2 - 1.0f) + 1.0f`.
Not sure why since the operation count is the same, but if alpha2 is very
small, `alpha2 - 1.0f` will be exactly -1.0f, which then causes issues.
Luckily, having one_minus_cos_NH2 as its own variable appears to be enough to
make GCC keep the original formulation.
Just to be safe, I've also used one_minus_cos_NH2 in the other branch to
hopefully reduce the chance of it being folded in again. Also turns a
division into a reciprocal, which is in theory slightly faster.
Pull Request: https://projects.blender.org/blender/blender/pulls/130469
The function table symbol declared in the headers was renamed starting
in OptiX 8.1, from `g_optixFunctionTable` to
`g_optixFunctionTable_<ABI version>`. This adds support for that by
using the new macro for the name when available (after OptiX 8.1) and
falling back to the old name when it is not (before OptiX 8.1).
Pull Request: https://projects.blender.org/blender/blender/pulls/130451
Shader draw parameters was enabled by query-ing the extension. The
feature is core in Vulkan 1.1, and our minimum requirement is Vulkan
1.2. In stead of querying the extension we should use enable the
feature via `VkPhysicalDeviceVulkan11Features`.
This was detected when working on !129062
Pull Request: https://projects.blender.org/blender/blender/pulls/130441
