Noop is no operation, meaning it is a stub renderer that will do nothing. You need to figure out why bgfx ended up here. Sometimes this is because bgfx ended up in a bad state and switched the type to the noop renderer to prevent additional errors.
OK, Now I found malfunctioning point:
I added std::cout << "Score: " << ii << ", Type: " << renderer << ", Null? " << (renderCtx == NULL ? 0 : 1) << std::endl;
after this line, and result was:
Score: 0, Type: 6, Null? 0
Score: 1, Type: 0, Null? 1
I assume that it should had to be:
Score: 0, Type: 0, Null? 0
Score: 1, Type: 6, Null? 1
but some reason type enum value has mixed up - eventually calling RendererContextNoop
instead of RendererContextMtl
.
I tried to force-render by changing !!BGFX_CONFIG_RENDERER_METAL
to true
, but m_encoder
crashes when frameNum
is gonna hit 4. (until 3 it runs)
Any suspects?
I’m not sure. Are you able to capture with the metal debugger? Are there any errors in the output?
Sadly, Xcode does not enables capturing in this case.
something odd is frameNum
has logged until 3
, but left side of Xcode it says 1
.
I tried to continue
at console’s (lldb)
, the red line has changed to green, but still stuck on there.
I found that s_renderMtl
in mtl::rendererCreate
has made, but does not have s_renderMtl->init(_init)
, thus returning NULL
.
I tried to force return s_renderMtl
even it does not have init(_init)
, but it fell into infinite loop.
Any suspects?
I’m not sure I can be much help. You are knee deep in bgfx now and it is a matter of debugging to see what is wrong. If I can find some time, I’ll try to repro, but it might be a while before I can do it.
Feel free to do when you have some time.
Since I’m still undergraduate senior, thus I have more time than you, I’ll try deeper.
I’ve now found that g_platformData.nwh
always returns 0x0
, makes m_metalLayer
NULL
.
but cannot find where g_platformData
is being initialized. still finding the point…
It looks like there is no Metal device available. Are you running the app on a Metal enabled Mac? Or some virtualization that would set Metal as unavailable?
I’m using physical device - 2020 M1 Mac mini with macOS Ventura and I can see Metal GPU Frame Capture Enabled
and Metal API Validation Enabled
on logs.
Should I have to manually enable Metal? Internet says it is enabled by default on macOS.
Oh, I found almost same case.
He or she said “It works fine when i set PlatformData with metal context and layer(render to screen).”
How can I manually get Metal context and layer so I can set them to g_platformData
?
You can get everything from the view, get the metal layer from that.
I don’t have everything in mind but I remember the Apple documentation was very good for that.
Hmm, I tried a while but no luck.
I added g_platformData.nwh = [NSApplication sharedApplication].mainWindow.contentView;
and got this:
-[MTLDebugDevice newBufferWithBytes:length:options:]:666: failed assertion `Buffer Validation
Cannot create buffer of zero length.
newBufferWithBytes:pointer must not be nil.
seems to be banged on here, so I tried many things on there, but nothing changes anything.
Maybe the line I added is wrong.
but nwh
is window handle, so I think that line should work…
I found that mem->size
is always 0
, resulting to crash in here.
I tried while (mem == nullptr || mem->size == 0) _cmdbuf.read(mem)
, but it always crashes on mem->size == 0
part.
Maybe there’s no size
on mem
- which case we didn’t expect.
Any suspects?
Are you trying to load a .gltf? Do you have a complete callstack?
Not loading .gltf, just testing with MeshBuilder.CreateSphere
only.
And here is my call stack:
#0 0x0000000100abcf58 in bgfx::mtl::RendererContextMtl::updateDynamicIndexBuffer(bgfx::IndexBufferHandle, unsigned int, unsigned int, bgfx::Memory const*) at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Dependencies/bgfx.cmake/bgfx/src/renderer_mtl.mm:943
#1 0x0000000100a8a434 in bgfx::Context::rendererExecCommands(bgfx::CommandBuffer&) at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Dependencies/bgfx.cmake/bgfx/src/bgfx.cpp:2979
#2 0x0000000100a85a38 in bgfx::Context::renderFrame(int) at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Dependencies/bgfx.cmake/bgfx/src/bgfx.cpp:2448
#3 0x0000000100a895e4 in bgfx::Context::swap() at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Dependencies/bgfx.cmake/bgfx/src/bgfx.cpp:2365
#4 0x0000000100a87488 in bgfx::Context::frameNoRenderWait() at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Dependencies/bgfx.cmake/bgfx/src/bgfx.cpp:2330
#5 0x0000000100a869d4 in bgfx::Context::init(bgfx::Init const&) at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Dependencies/bgfx.cmake/bgfx/src/bgfx.cpp:1972
#6 0x0000000100a8c8fc in bgfx::init(bgfx::Init const&) at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Dependencies/bgfx.cmake/bgfx/src/bgfx.cpp:3554
#7 0x00000001002af3b0 in Babylon::Graphics::DeviceImpl::EnableRendering() at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Core/Graphics/Source/DeviceImpl.cpp:160
#8 0x00000001002a32c8 in Babylon::Graphics::Device::EnableRendering() at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native-macos/submodules/BabylonNative/Core/Graphics/Source/Device.cpp:75
#9 0x00000001001bc360 in BabylonNative::ReactNativeModule::UpdateGraphicsConfiguration() at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native/shared/BabylonNative.cpp:96
#10 0x00000001001bbab0 in BabylonNative::ReactNativeModule::RenderView() at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native/shared/BabylonNative.cpp:140
#11 0x00000001001bba48 in BabylonNative::RenderView() at /Users/jihoobyeon/Desktop/BabylonReactNative/Modules/@babylonjs/react-native/shared/BabylonNative.cpp:325
#12 0x0000000100bc3108 in +[BabylonNativeInterop renderView] at /Users/jihoobyeon/Desktop/foo/node_modules/@babylonjs/react-native-macos-arm64/macos/BabylonNativeInterop.mm:71
#13 0x0000000100bc6f80 in -[EngineView drawRect:] at /Users/jihoobyeon/Desktop/foo/node_modules/@babylonjs/react-native-macos-arm64/macos/EngineViewManager.mm:47
#14 0x00000001994c4c70 in -[MTKView draw] ()
Does it happen as well if you create a box?
Yes, same thing happens.
so we have to find what should be placed in g_platformData.nwh
…
Looking at BabylonReactNative, looks like MTKView* is forwarded here:
and used directly for nwh
I guess for MacOS, there is a equivalient to MTKView thatis created?
from bgfx source code on MacOS, it’s possible to provide the NSView, NSWindow or CAMetalLayer for the nwh