* For materials with UDIM tiles support, get array and mapping in one call
* For viewers that can use render results, add a dedicated function
* Fix potential use of render results in stencil overlay and grease pencil
Pull Request: https://projects.blender.org/blender/blender/pulls/117563
Exceptions:
* Links to personal wiki pages
* Pages that are not in the new developer docs yet (like Human Interface Guidelines)
* tools\check_wiki\check_wiki_file_structure.py needs a refactor
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
This patch adds an alternative path for devices/OSs
which do not support native texture atomics in Metal.
Support is encapsulated within the backend, ensuring
any allocated texture with the USAGE_ATOMIC flag is
allocated with a backing buffer, upon which atomic
operations happen.
The shader generation is also changed for the atomic
case, which instructs the backend to insert additional
buffer bind-points for the buffer resource. As Metal
also only supports buffer-backed textures for
textureBuffers or 2D textures, TextureArrays and
3D textures are emulated within a 2D texture, with
sample locations being indirected.
All usage of atomic textures MUST now utilise the
correct atomic texture types in the high level shader
and GPUShaderCreateInfo declarations.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/115956
Due to changes in the build environment shader_builder wasn't able to
compile on macOs. This patch reverts several recent changes to CMake files.
* dbb2844ed9
* 94817f64b9
* 1b6cd937ff
The idea is that in the near future shader_builder will run on the buildbot as
part of any regular build to ensure that changes to the CMake doesn't break
shader_builder and we only detect it after a few days.
Pull Request: https://projects.blender.org/blender/blender/pulls/115929
Motivation: When discussing with @Jeroen-Bakker and @aras_p about how to
approach sorting when rendering Gaussian splats in Blender, we realised that
compute shaders could help there (and have many other use cases), and that also
due to Blender 4.0 being on OpenGL >= 4.3, we can now rely on compute shaders
existing.
This PR is an initial pass for that functionality. It comes with a Python example, which
runs a compute shader and saves the output to a texture, which is then rendered in the
viewport.
There is no exposed support for storage buffers yet, but I expect I'll be able to work on
them soon if this is accepted.
The newly added parts are:
1. `gpu.compute.dispatch()`
2. a way set the compute source to `GPUShaderCreateInfo`: `shader_info.compute_source()`
3. a way to set the image store for `GPUShaderCreateInfo`: `shader_info.image()`
4. a way to set the `local_group_size` for `GPUShaderCreateInfo`: `shader_info.local_group_size(x,y,z)`
5. a way to get `max_work_group_size` from capabilities: `gpu.capabilities.max_work_group_size_get(index)`
6. a way to get `max_work_group_count` from capabilities: `gpu.capabilities.max_work_group_count_get(index)`
Pull Request: https://projects.blender.org/blender/blender/pulls/114238
Some of these devices are not capable of running >=4.0, due to issues
with Mesa's Compute Shaders and their D3D drivers.
This PR marks those GPUs as unsupported, and prints info to stdout.
A driver update will be available for 8cx Gen3 on the 17th October
from here:
https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-tablets/snapdragon-8-series-mobile-compute-platforms/snapdragon-8cx-gen-3-compute-platform#Software
It will take longer via the standard MS Windows Update channels,
as there is certification, testing, etc required, but it is possible
to get the drivers, at least.
This issue applies even when using emulated x64.
If this does not get merged, all WoA devices will break with 4.0,
where older ones will just launch a grey screen and crash, and newer
ones will open, but scenes will not render correctly in Workbench.
These devices work by using Mesa's D3D12 Gallium driver ("GLOn12"),
which is why we have to read the DirectX driver version - the version
reported by OpenGL is the mesa version, which is independent of the
driver (which is the part with the bug).
Pull Request: https://projects.blender.org/blender/blender/pulls/113674
Blender 4.0 requires OpenGL 4.3 which always support SSBO's.
Platforms that don't support enough SSBO bind points will be marked
as unsupported.
Users who start Blender on those platforms will be informed via a
dialog. This PR also updates the `--debug-gpu-force-workarounds`
to match our minimum requirements. Note that some bugs are still
there that should be solved in other PRs:
* Workbench only renders the object using a unit matrix this is because
there is a bug in the workaround for shader_draw_parameters
* Navigating with middle mouse button is not working. Unsure what the
cause is, but might be a missing feature check in the OpenGL backend.
Related to #112224
Pull Request: https://projects.blender.org/blender/blender/pulls/112572
Enables performance optimizations and new rendering
features through allowing colour attachments to be
tagged with a rasterization order group. This means that
all accesses to the same pixel location are guaranteed
to happen in submission order.
This lays the ground work for tile-based architecture
optimizations, enabling additional features for
deferred rendering which allow subsequent passes
which operate on pixel data to occur in order, while
memory remains on-tile.
This patch allows fragment outputs to be tagged
with a raster order group and also adds a new
FragmentTileIn parameter to a shader, which allows
speciication of incoming parameters from a previous
draw.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/111748
- Account for new member in _PyArg_Parser.
- Many Python op-codes have been removed.
For the moment these are disabled in is_opcode_secure.
Some should be added back as intrinsics, noted in code-comments.
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Add a High Dynamic Range option in the Color Management > Display panel.
This enables display of extended color ranges above 1.0 for the 3D
viewport, image editor and render previews.
This requires a monitor that can display HDR colors, and a view
transform designed for HDR output. The Standard view transform works,
but Filmic does not as it was designed to bring values into the 0..1
range for SDR displays.
This patch is limited to allowing the display to visualize extended
colors, but does not include future looking work to better integrate HDR
into the full workflow.
It is implemented by rendering to high bit-depth texture formats for
the user interface, and uncapping the color range in color management.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/105662
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
