Subdivision shaders currently fail to compile using Metal as it doesn't recognize
packed_float3 as an internal data type. This PR includes packed_float3 as an
internal data type.
Without this `blender --debug-gpu-compile-shaders` will fail as it includes a namespace.
```
ERROR (gpu.shader): subdiv_normals_accumulate Compute Shader:
|
| source/blender/gpu/metal/mtl_shader_generator.mm:971:9: Error: no type named 'packed_float3' in 'MTLShaderComputeImpl'; did you mean simply 'packed_float3'?
|
| device MTLShaderComputeImpl::packed_float3* normals[[buffer(MTL_storage_buffer_base_index+4)]],
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| packed_float3
|
| /System/Library/PrivateFrameworks/GPUCompiler.framework/Versions/32023/Libraries/lib/clang/32023.196/include/metal/metal_packed_vector:145:58: Note: 'packed_float3' declared here
|
| typedef __attribute__((__packed_vector_type__(3))) float packed_float3;
| ^
```
Pull Request: https://projects.blender.org/blender/blender/pulls/134925
There seems to be a pattern where this commonly failed.
This patch adds the async flush (which is effectively not async)
when there were no previous call to `async_flush_to_host`.
This is only done on Intel Macs (or any mac that has non
unified memory arch).
Pull Request: https://projects.blender.org/blender/blender/pulls/134216
Native tile input wasn't part of the MTLCapability struct, but stored locally
in the shader generator and checked in MTLFramebuffer. This PR moves it
to the MTLCapability struct and disables it when workarounds are forced.
Pull Request: https://projects.blender.org/blender/blender/pulls/133818
This allows to run with the --debug-gpu option (which
does NAN and 0xF0F0F0F0 clearing) without asserts
even when the texture atomic workaround is enabled.
This was caused by the subpass input workaround for non-tilebased
GPU using `texelFetch` on an `image`. This was supported before
the cleanup 9c0321ae9b.
But is against the GLSL specification and was removed inside the
cleanup.
Using `imageLoad` instead of `texelFetch` fixes the crash.
However rendering seems to be broken for other reasons.
Recently it came to out attention that macOs13 doesn't always work due
to texture atomics not supported by that version of the OS.
Development happens most of the time on newer versions of the OS without
ability to check if it still works on the older versions.
This PR enables to disable some Metal capabilities to better check how
Blender works on those OS's. The capabilities that will be disabled
are texture gathering and texture atomics. It doesn't disable the
capabilities that are required to start Blender, which are still
part of the `MTLCapabilities` struct.
This allows us to reproduce issues like #129571
Pull Request: https://projects.blender.org/blender/blender/pulls/133636
Framebuffers are getting freed in the GPUContext base class destructor. But
the framebuffer destructors use the MTL/VK/GLContext derived class, whose
destructor has already completed at this point. So these contexts are no
longer valid to use.
Now free the framebuffers earlier.
This caused ASAN warnings, it's not known to cause actual bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/132504
Rendering animations from Python scripts via `bpy.ops.render.opengl()`
did not trigger any of the notifications in the Metal back-end to
indicate a frame had been rendered and that the associated resources
could be released. This adds a call to GPU_render_step() after each
render. For the original asset in the bug report this reduces the high
memory watermark from 30gb to 13gb for 500 frames. 13gb is likely
still too high and therefore it is likely there are additional leaks
that need to be addressed so this should only be considered a partial
fix.
Authored by Apple: James McCarthy
Co-authored-by: James McCarthy <jamesmccarthy@apple.com>
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/131085
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
The string `msl_patch_default` can have been read
partially uninitialized or initialized multiple
time and read uncomplete during multithreaded
compilation.
This should fix the GPU tests randomly failing on mac.
While this would never fail when blender runs from the UI (since
UI shaders are init in single threaded manner and always compile
before EEVEE shaders), this race condition could happen when running
EEVEE through background rendering or running tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/131580
The new buffer size could have been non aligned when using the
fractional growing heuristic. This non aligned allocation
would then trigger an assert at the SSBO constructor.
Aligning the alocation size fixes the issue.
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.
This port is not so straightforward.
This shader is used in different configurations and is
available to python bindings. So we need to keep
compatibility with different attributes configurations.
This is why attributes are loaded per component and a
uniform sets the length of the component.
Since this shader can be used from both the imm and batch
API, we need to inject some workarounds to bind the buffers
correctly.
The end result is still less versatile than the previous
metal workaround (i.e.: more attribute fetch mode supported),
but it is also way less code.
### Limitations:
The new shader has some limitation:
- Both `color` and `pos` attributes need to be `F32`.
- Each attribute needs to be 4byte aligned.
- Fetch type needs to be `GPU_FETCH_FLOAT`.
- Primitive type needs to be `GPU_PRIM_LINES`, `GPU_PRIM_LINE_STRIP` or `GPU_PRIM_LINE_LOOP`.
- If drawing using an index buffer, it must contain no primitive restart.
Rel #127493
Co-authored-by: Jeroen Bakker <jeroen@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/129315
In some cases the MTLContext was being destroyed before all GPU work was completed causing the (outstanding) command buffer completion event handler to update a command buffer that had already been freed. This behaviour was introduced by [this](https://projects.blender.org/blender/blender/commit/6da42e9c951b) change which updated the event handler to track the number of outstanding command buffers per context as well as system-wide.
Reproduced the issue with ASAN enabled and confirmed that waiting for the GPU to complete fixes the issue.
Also contains a minor fix for unitiiliased values in MTLAttachments identified by ASAN.
Authored by Apple: James McCarthy"
Co-authored-by: James McCarthy <jamesmccarthy@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/129686
For Metal we can change the texture usage flags to get more optimal
behaviour - one example is adding the attachment flag so we can utilise
renders to do texture clears. However these usage flags are used as the
part of the match-criteria when trying to reuse released textures in
the texture pool.
The modifications means a request for the same type of texture will
fail causing a cache miss. When we render to an
image-view the texture pool is not released until the final sample has
been rendered as we consider the entire render to be a single frame
(as opposed to normal viewport rendering when we are presenting the
intermediate results).
This causes the texture pool to grow and grow and grow hence the large
memory usage. This fix splits the usage flags
into two sets, the internal ones we use to create the MTLTexture (which
we may modify) and the originally requested ones. The originally requested
ones are used for the texture pool matching.
This fix also improves memory efficiency for normal viewport rendering.
Mr Elephant Scene
Before -> After
Load scene in viewport: 13.04Gb -> 9.15 Gb
Viewport Render Image: 78.69Gb -> 16.61Gb
Authored by Apple: James McCarthy
Pull Request: https://projects.blender.org/blender/blender/pulls/129951
Crash manifested after the inclusion of #128877.
The very tall 3D texture tested by the new code
were not supported / tested by the Metal Backend.
Simply adding the appropriate upfront checks fixes
the issue.
Needs to be backported to 4.2
Avoid measuring the length of strings repeatedly by passing their
length along with their data with `StringRefNull`. Null termination
seems to be necessary still for passing the shader sources to OpenGL.
Though I doubt this is a bottleneck, it's still nice to avoid overhead from
string operations and this helps move in that direction.
Pull Request: https://projects.blender.org/blender/blender/pulls/127702
Running Xcode memory graphs and the Instruments tools revealed
memory leaks caused, in the main, by over-retained objects.
This removes the unnecessary 'retains' and adds some asserts
to guard against over-retaining in the future.
There are a few memory leaks remaining involving PyUnicode_DecodeUTF8
but I am unable to identify the cause of these at this time.
Authored by Apple: James McCarthy
Pull Request: https://projects.blender.org/blender/blender/pulls/129117
