GPUViewport is creating a bunch of framebuffer textures for itself, but
some space types never initialize/use them. E.g. Sequencer, Nodes etc.
only ever use the "overlay" texture. Eventually when viewport is
"drawn", it combines this uninitialized texture data and then only by
luck it happens that most of the time it is black. But not always!
The textures were only cleared (right now) on Metal backend, under
GPU_clear_viewport_workaround as if it was some driver workaround. Stop
doing that, and just clear them always.
However, there was seemingly a performance issue on OpenGL, when this
clear was being done. At least on my machine (Win10, Geforce RTX
3080Ti), the overhead of doing the clears is measurable, and is caused
by usage of GL4.4 glClearTexImage instead of a framebuffer clear. As if
glClearTexImage makes "pixel data to exist" on the CPU side and then
later on binding this framebuffer sends off that data to the GPU, or
somesuch.
More details in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/131518
This happened because NVidia GPUs require higher alignment
for SSBO binds than for vertex inputs.
This is related to #131103 which fixed it for vulkan.
Add a common capability option for that.
Adding a dummy storage buffer to the classification shader
seems to fix the issue on Qualcomm drivers (WoA).
The workaround is added to the force workaround option to
allow other platforms to test the fix.
Rel #122837
Pull Request: https://projects.blender.org/blender/blender/pulls/129857
Move most of the string preprocessing used for MSL
compatibility to `glsl_preprocess`.
Enforce some changes like matrix constructor and
array constructor to the GLSL codebase. This is
for C++ compatibility.
Additionally reduce the amount of code duplication
inside the compatibility code.
Pull Request: https://projects.blender.org/blender/blender/pulls/128634
This rare GPU has z-fighting issues in editor mode. Might be fixable by
changing the bias, but would decrease precision on other platforms as
well. Better to move this GPU to limited support. It is working, just
has some drawing artifacts.
See #128179
Pull Request: https://projects.blender.org/blender/blender/pulls/128351
This works around an issue where eevee was rendering a pure black cube in certain shader configurations in the default scene (#122837). This only affects X Elite devices (8cx Gen3 is unaffected).
Pull Request: https://projects.blender.org/blender/blender/pulls/127148
Workaround for RDNA2 shadow rendering when the geometry it needs
to render is to tiny. In this case the rasterizer can skip triangles
leading to incorrect shadow.
This issue has been forwarded to AMD, but this is a temp workaround
for the current drivers. Note that this workaround adds a performance
penalty of around 50% in selected scenes.
Pull Request: https://projects.blender.org/blender/blender/pulls/126693
On Legacy AMD devices EEVEE doesn't render any geometry. During testing
we found that it was based on reading normal attribute. Further testing
it was detected that enabling the high quality normals would solve the
rendering.
This is a known issue on legacy AMD drivers. This PR updates the check
to enable the high quality normals workaround for the latest known AMD
legacy drivers (22.6.1/21.Q1.2). Both drivers still have this issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/126483
When performing framebuffer transition on legacy opengl platforms, some
state was uninitialized. Resulting in incorrect behavior and crashes.
Note that this doens't fix the black cube on legacy platforms. With this PR we
might be able to reproduce the issue on modern HW.
Pull Request: https://projects.blender.org/blender/blender/pulls/123989
This is the first commit of the several required to support
subprocess-based parallel compilation on OpenGL.
This provides the base API and implementation, and exposes the max
subprocesses setting on the UI, but it's not used by any code yet.
More information and the rest of the code can be found in #121925.
This one includes:
- A new `GPU_shader_batch` API that allows requesting the compilation
of multiple shaders at once, allowing GPU backed to compile them in
parallel and asynchronously without blocking the Blender UI.
- A virtual `ShaderCompiler` class that backends can use to add their
own implementation.
- A `ShaderCompilerGeneric` class that implements synchronous/blocking
compilation of batches for backends that don't have their own
implementation yet.
- A `GLShaderCompiler` that supports parallel compilation using
subprocesses.
- A new `BLI_subprocess` API, including IPC (required for the
`GLShaderCompiler` implementation).
- The implementation of the subprocess program in
`GPU_compilation_subprocess`.
- A new `Max Shader Compilation Subprocesses` option in
`Preferences > System > Memory & Limits` to enable parallel shader
compilation and the max number of subprocesses to allocate (each
subprocess has a relatively high memory footprint).
Implementation Overview:
There's a single `GLShaderCompiler` shared by all OpenGL contexts.
This class stores a pool of up to `GCaps.max_parallel_compilations`
subprocesses that can be used for compilation.
Each subprocess has a shared memory pool used for sending the shader
source code from the main Blender process and for receiving the already
compiled shader binary from the subprocess. This is synchronized using
a series of shared semaphores.
The subprocesses maintain a shader cache on disk inside a
`BLENDER_SHADER_CACHE` folder at the OS temporary folder.
Shaders that fail to compile are tried to be compiled again locally for
proper error reports.
Hanged subprocesses are currently detected using a timeout of 30s.
Pull Request: https://projects.blender.org/blender/blender/pulls/122232
Multiple generations of Intel GPU have the same issue where multi
texture binding results in invalid operations where the driver
reports that the internal texture format isn't supported.
Previously this was only enabled for UHD devices, but this PR
enables it for any Intel GPU. It was detected to be faulty on
UHD600 and Iris.
Pull Request: https://projects.blender.org/blender/blender/pulls/121479
On windows the OpenGL backend of the UHD630 driver (but could also be other
GPUs that use the same driver) reports of supporting `GL_ARB_multi_bind`.
But when enabling it can result in incorrect bindings and report errors
about unsupported internal texture formats. These are internal driver issues.
Might also fix#107642 as it shows the same error message. EEVEE-Next
relies more on using the same binding slot for the same texture in order
to reduce actual bindings which makes this more prominent.
Pull Request: https://projects.blender.org/blender/blender/pulls/121062
Compute shaders are required since 4.0. There was one occasion where
an older AMD driver failed and support was turned off. This driver
is now marked unsupported.
This PR includes:
- removing the check in viewport compositing
- remove properties from system info
- always construct draw manager.
- remove unused pass logic in draw hair/curves
- add deprecation warning when accessed from python
Pull Request: https://projects.blender.org/blender/blender/pulls/120909
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
This patch adds the maximum number of supported image units to the GPU
capabilities module. Currently, the GPU module assume a maximum of 8
units, so the patch is not currently particularly useful, but we can
consider committing it for the future anyways.
Pull Request: https://projects.blender.org/blender/blender/pulls/119057
This avoid the cost of creating the tiles themselves which uses a lot
texture write. This was a bottleneck on Apple GPUs.
Also the per pixel classification allows us to remove certain checks in
the deferred lighting shader making it faster.
### TODO
- [x] Add gl_FragStencilRefARB support on other backend
- [x] Add workaround for when gl_FragStencilRefARB isnt supported
Pull Request: https://projects.blender.org/blender/blender/pulls/116704
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.
According to the issue not all legacy AMD platforms that required the
high quality normals workaround where enabled. I have not been able to
reproduce the issue due hardware availability.
This PR will enable the workaround for all HD ATI GPUs.
Pull Request: https://projects.blender.org/blender/blender/pulls/116340
These drivers crash on startup caused by a driver bug. This include the
latest drivers for legacy Intel CPUs with a HD 4000/HD 5000 series GPU.
To be on the safe side all drivers with version 20.19.15.51* will be marked
unsupported as we don't have the platforms to identify the precise driver
versions that fail.
See #113124 for more information.
Pull Request: https://projects.blender.org/blender/blender/pulls/115228
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
The OpenGL extension `GL_ARB_shader_viewport_layer_array` wasn't turned
off when starting blender with `--debug-gpu-force-workarounds`. Although
all known supported platforms support this extension and we haven't seen
any failures with it, it was mentioned to be phased out as we consider
it to be a core extension, which it isn't.
This PR will enable the workaround for this extension and remove the
extension from the phase out list.
Pull Request: https://projects.blender.org/blender/blender/pulls/113572
We don't ship with OpenGL anymore on Mac platform.
The build option is not even available anymore.
This removes any reference to Apple or Mac in the
Opengl module.
Note that I left the depth_blitting_workaround
even if it originaly meant for Mac because it
might be still useful for other hardware.
Pull Request: https://projects.blender.org/blender/blender/pulls/113126
This adds basic emulation of the subpass input feature
of vulkan and to a lower extend Raster Order Group on Metal.
This help test paths that might use this feature in the future
(like shadow rendering) on all platform and or simplify higher
level code for supporting older hardware.
This add clear description to the load/store ops and to the
new `GPUAttachementState`.
The OpenGL backend will correctly mask un-writable
attachments and will bind as texture readable attachments.
Even if possible by the vulkan standard, the GPU API prohibit
the read and write to the same attachment inside the same
subpass.
In the GL backend, this is implemented using `glTextureBarrier`
and `texelFetch` as it is described in the ARB_texture_barrier
extension.
https://registry.khronos.org/OpenGL/extensions/ARB/ARB_texture_barrier.txt
Pull Request: https://projects.blender.org/blender/blender/pulls/112051
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
Blender has the option to disable SSBO support. This was accessible
as a command line option `--debug-gpu-disable-ssbo`.
Blender 4.0 has a hard requirement for OpenGL 4.3 which includes
SSBO support by default.
This PR removes the command line option as it makes no sense to
have it anymore.
Related to #112224
Pull Request: https://projects.blender.org/blender/blender/pulls/112571
Extract a mask from the stencil buffer and use that texture instead
when texture views are not available.
Needed for supporting the Windows ARM software driver.
The workaround is isolated on its own class so it's easy to remove once
it's no longer needed.
Note that while this adds a function to check if texture views are available
(`GPU_texture_view_support`), at the moment this always returns true in
practice, since OpenGL 4.3 is the minimum supported version.
A separate patch will be needed to allow Blender to run using
OpenGL 4.2 + extensions.
Pull Request: https://projects.blender.org/blender/blender/pulls/111402
