Closed sconybeare closed 1 year ago
Hmm, I've seen this exact same problem after updating to macOS 13.x around the end of 2022:
https://github.com/floooh/sokol/issues/762
...but this issue was fixed by this MR:
https://github.com/floooh/sokol/pull/763
I'll try to reproduce the problem in the evening (it's strange because my Mac is my main development platform, and I should have noticed such an obvious issue).
In the meantime, can you check if the problem still happens when you change the commandBufferWithUnretainedReferences
call here:
...to:
_sg.mtl.cmd_buffer = [_sg.mtl.cmd_queue commandBuffer];
(so that it looks like in the line below where the separate present_cmd_buffer
is created.
...cannot reproduce on my Mac with some furious resizing btw (so far I just enabled .high_dpi in the triangle sample in sokol-samples), neither when running from the Xcode debugger (this enables the validation layer by default), or running from the command line with MTL_DEBUG_LAYER enabled.
I'm on an M1 14" MBP with macOS Ventura 13.4.1 (c) (22F770820d), Xcode version is 14.2
PS: do you compile with ARC enabled or disabled? (it shouldn't matter but since it is some sort of lifetime issue it could be related)
...let me update to the latest xcode version...
Ok, I finally got the error too... took a long while of wildly resizing though, and I can't seem to reproduce it reliably.
I also updated to the latest Xcode version, but it's probably not related.
I'll try to investigate later today. I was hoping that just doing the present call in a separate command buffer with retained references would be enough to fix the issue, but looks like that's not enough.
It's also complicated by the fact the resource in question is created and managed by MTKView, which I don't have access to. Worst case would be to do all rendering in a command buffer with retained references, but maybe there's another solution (e.g. maybe I can extract the depth-stencil-surface from the MTLRenderPassDescriptor I'm getting from MTKView, and add a manual retain/release call somewhere in sokol-gfx - but that doesn't sound like a robust solution, I would expect that MTKView takes care of the lifetimes of the objects is manages).
-[MTLDebugDevice notifyExternalReferencesNonZeroOnDealloc:]:2885: failed assertion `The following Metal object is being destroyed while still required to be alive by the command buffer 0x101059800 (label: <no label set>):
<MTLToolsObject: 0x100e49500> -> <AGXG13XFamilyTexture: 0x100e4eab0>
label = MTKView Depth Stencil
textureType = MTLTextureType2D
pixelFormat = MTLPixelFormatDepth32Float_Stencil8
width = 2892
height = 44
depth = 1
arrayLength = 1
mipmapLevelCount = 1
sampleCount = 1
cpuCacheMode = MTLCPUCacheModeDefaultCache
storageMode = MTLStorageModePrivate
hazardTrackingMode = MTLHazardTrackingModeTracked
resourceOptions = MTLResourceCPUCacheModeDefaultCache MTLResourceStorageModePrivate MTLResourceHazardTrackingModeTracked
usage = MTLTextureUsageRenderTarget
shareable = 0
framebufferOnly = 0
purgeableState = MTLPurgeableStateNonVolatile
swizzle = [MTLTextureSwizzleRed, MTLTextureSwizzleGreen, MTLTextureSwizzleBlue, MTLTextureSwizzleAlpha]
isCompressed = 1
parentTexture = <null>
parentRelativeLevel = 0
parentRelativeSlice = 0
buffer = <null>
bufferOffset = 0
bufferBytesPerRow = 0
iosurface = 0x0
iosurfacePlane = 0
allowGPUOptimizedContents = YES'
Can you give the attempted fix in the branch issue872-metal-validation-error
a try? This reverts the previous solution to use a separate command buffer with retained references only for the present call, and instead pins the swapchain resources into memory via the regular 'deferred release queue' which I'm already using for all other Metal resource objects.
See this change: https://github.com/floooh/sokol/compare/master...issue872-metal-validation-error
This means there's no refcounting overhead (because the command buffer is stil created with unretained-references), but slightly increases memory usage during window resize (but that's expected to happen, because swapchain resources which had been released by MTKView during the window resize need to stick around a few frames before it's safe to delete them).
That seems to fix it for me, too. Thank you!
Ok, I think I'll merge the fix into master some time over the weekend (or latest on Monday). Will close this issue when the fix is merged.
Closing this because PR https://github.com/floooh/sokol/pull/873 has been merged. Thanks for the bug report!
Hi, thanks for the excellent graphics library!
I noticed that when using the xcode metal debugging tools, my program was crashing on resize. Here's the most minimal reproduction I could find (basically the triangle example with extra stuff removed and high_dpi=true in sokol_main):
with this shader code:
Running this with MTL_DEBUG_LAYER=1 set and then resizing the window results in a crash with the following text printed out:
sokol headers used were from sokol commit
47d92ff86298fc96b3b84d93d0ee8c8533d3a2d2
, which is the tip of master at the time of posting