It turns out I also needed to clear up the auto release pools for the render_step() fix to completely remove the high memory usage issues. I've added a new API to indicate that we need that to…
I have a fix pending for the complete fix so hold off merging anything.
@Jason-Fielder Please separate merge commits from the functional changes commits. It makes it easier to follow incremental changes to the PR.
Ah, apologies. Will do.
I changed the naming of the variable so it matches our style guide.
Ah sorry. Every time I think I've got the hang of the Blender coding style it turns out...
@Sergey: "The confusing part in the PR you've mentioned is that it explicitly mentions leaks identified by the instruments, so I thought those are about something much more hidden." You are…
@Brainzman sure, that's fine. We have run into complications on large projects before when mixing C++ & Objective-C which has lead us to initially develop with ARC disabled as a pragmatic starting…
heap-use-after-free)
The issue is we're tearing down the context before all GPU work has completed. I don't understand the interaction with 6da42e9c95 …
@Jason-Fielder see my edit2. The retain count is set to 2 on creation for some reason and the API documentation specify that we should not rely on
retainCountfor debugging purpose. Maybe it…
@fclem Implemented your suggested changes. Thanks for the pointers.
I had to remove this and mtl_misc.hh to make it compile.
Ah yes. Sorry missed this when I deleted the files. Will fix and update.
Thanks for the verbose explanation about how to use the…
Ah, too bad. One of the goals of batch compilation was to never block the UI. Ah no I've added it, it will now block on
specialization_batch_is_readyif we were able to pre-compile the…
I was unable to reproduce the crash in the initial comment, if anyone can offer any reliable ways of reproducing it that would be appreciated. The stack trace wasn't enough to isolate it.
_"The…
Because the Metal backend has stricter requirements about when we can actually precompile a specialisation (we effectively need to know the render state for vertex and fragment shaders) I was…
It's not strictly required because it's just adding the shader variations to the pipeline state cache which can be done asynchronously - you'll just pause when you come to use it if it's not ready…
No, but it has been useful for testing purposes. The OGL backend allows it to be adjusted via the argument --gpu-compilation-subprocesses. We should probably hook that up to the Metal backend…