This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
21.Q4 is required, older version should not show devices in the preferences.
This adds a check for the file version of amdhip64.dll file during hipew
initialization.
Differential Revision: https://developer.blender.org/D13324
Use the correct device function (hipDeviceGet) for multi GPU setups, instead
of hipGetDevice which just returns the default device.
Differential Revision: https://developer.blender.org/D13323
This fixes the the app crash happening when trying to render smoke as a dense
3D texture. The changes are related to matching up hipew with the actual HIP
headers.
Differential Revision: https://developer.blender.org/D13296
Fixes several notable mistakes and missing information
regarding the API documentation (*.rst).
This will allow API stub generators like bpystubgen or
fake-bpy-module to produce more accurate result.
Differential Revision: https://developer.blender.org/D12639
* Additional structs added to the hipew loader for device props
* Adds hipRTC functions to the loader for future usage
* Enables CPU+GPU usage for HIP
* Cleanup to the adaptive kernel compilation process
* Fix for kernel compilation failures with HIP with latest master
Ref T92393, D12958
This patch cleans up code for HIP device and makes it more consistent with the CUDA code.
It also fixes the issue with high VRAM usage on AMD cards using HIP allowing better performance and usage on cards like 6600XT.
Added a check in intern/cycles/kernel/bvh/bvh_util.h to prevent compiler error with hipcc
Reviewed By: brecht, leesonw
Maniphest Tasks: T92124
Differential Revision: https://developer.blender.org/D12834
This is required for Cycles to report a meaningful error message when it fails to load a PTX module
created with a newer CUDA toolkit version than the driver supports.
Ref T91879
NOTE: this feature is not ready for user testing, and not yet enabled in daily
builds. It is being merged now for easier collaboration on development.
HIP is a heterogenous compute interface allowing C++ code to be executed on
GPUs similar to CUDA. It is intended to bring back AMD GPU rendering support
on Windows and Linux.
https://github.com/ROCm-Developer-Tools/HIP.
As of the time of writing, it should compile and run on Linux with existing
HIP compilers and driver runtimes. Publicly available compilers and drivers
for Windows will come later.
See task T91571 for more details on the current status and work remaining
to be done.
Credits:
Sayak Biswas (AMD)
Arya Rafii (AMD)
Brian Savery (AMD)
Differential Revision: https://developer.blender.org/D12578
Several areas within blender can benefit a JSON reader/writer library.
Areas like the asset browser, XR and grease pencil.
After looking at the available options we selected nlohmann's JSON for
modern C++ library. It is actively maintained for over 10 years and
flexible.
This patch only adds the header only implementation of the library so it
can be used by different areas. The asset browser project is planning to
add a small abstraction layer so it will be easier to switch between
several different serialization formats. This is currently in
development in D12544.
In cases the abstraction layer can be an overhead and undesired to be used.
In this case the header file can be directly included.
Reviewed By: Severin
Maniphest Tasks: T91430
Differential Revision: https://developer.blender.org/D12567
The XR_MSFT_controller_model OpenXR extension provides a glTF
controller model that can be displayed to users during a VR session.
There are plans to support this in D10948, which will greatly improve
VR immersion when using a compatible OpenXR runtime.
TinyGLTF (https://github.com/syoyo/tinygltf) was agreed upon as a
simple and sufficient solution for loading this glTF controller model,
which will be performed at the GHOST abstraction layer. Although by
default it has two additional dependencies, stb and json, stb can be
excluded by defining TINYGLTF_NO_STB_IMAGE and
TINYGLTF_NO_STB_IMAGE_WRITE whereas json will be added as a separate
extern lib in D12567.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D12344
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycleshttps://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
On the blender side this commit fixes importing video files with audio
and video streams that do not share the same start time and duration.
Differential Revision: https://developer.blender.org/D12353
Refactor and improve waveform drawing.
Drawing now can use line strips to draw waveforms instead of only
triangle strips. This makes us able to properly visualize thin waveforms
as they would not be visible before. We now also draw the RMS value of
the waveform.
The waveform drawing is now also properly aligned to the screen pixels
to avoid flickering when transforming the strip.
Reviewed By: Richard Antalik
Differential Revision: https://developer.blender.org/D11184
The duration and start time for audio strips were not correctly read in
audaspace.
Some video files have a "lead in" section of audio that plays before the
video starts playing back. Before this patch, we would play this lead in
audio at the same time as the video started and thus the audio would not
be in sync anymore.
Now the lead in audio is cut off and the duration should be correctly
calculated with this in mind.
If the audio starts after the video, the audio strip is shifted to
account for this, but it will also lead to cut off audio which might not
be wanted. However we don't have a simple way to solve this at this
point.
Differential Revision: http://developer.blender.org/D11917
The library has some modifications and it has been included in a diff.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D12142
(Some minor changes done in the patch)
Contributed by @erik85 in D11400. The idea from this patch was placed in
a more generic context: A new FOR macro has been added that loops
over the neighbors of a cell within a given radius.
Includes update for OpenVDB file IO, i.e. fixes an issue with
compression flag combination that resulted in random segfaults.
Other changes: Cleanup and formatting.
This is an implementation of Enhanced Subpixel Morphological Antialiasing (SMAA)
The algorithm was proposed by:
Jorge Jimenez, Jose I. Echevarria, Tiago Sousa, Diego Gutierrez
This node provides only SMAA 1x mode, so the operation will be done with no spatial
multisampling nor temporal supersampling. See Patch for comparisons.
The existing AA operation seems to be used only for binary images by some other nodes.
Using SMAA for binary images needs no important parameter such as "threshold", so we
perhaps can switch the operation to SMAA, though that changes existing behavior.
Notes:
1. The program code assumes the screen coordinates are DirectX style that the
vertical direction is upside-down, so "top" and "bottom" actually represent bottom
and top, respectively.
Thanks for Habib Gahbiche (zazizizou) to polish and finalize this patch.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D2411
Clément Foucault
Clment Foucault
Ray Molenkamp
Brecht Van Lommel
Dalai Felinto
Sayak Biswas
Xavier Cho
Peter Kim
Patrick Mours
Jeroen Bakker
Brian Savery
Jörg Müller
Jeroen Bakker
Erik Abrahamsson
Sebastián Barschkis
Sebastian Parborg
Antonio Vazquez
Campbell Barton
Ankit Meel
Habib Gahbiche