Expose MtlCommandQueue

[ryantrem]

I have a scenario where I am doing some Metal rendering outside of bgfx, but it needs to be synchronized with bgfx rendering. Specifically, it is related to using ARKit and BGFX together, and seems quite similar to this past issue: #2043. In my case, this sequence of operations needs to happen:

1. Get camera image and pose from ARKit and draw a subset of the camera image into a render texture.
2. Have BGFX render to that render texture (e.g. render a scene on top of the camera texture).
3. Present the render texture to the display.

1 needs to be complete before 2, and 2 needs to be complete before 3. Previously I had one MtlCommandQueue for 1 and 3, and bgfx had its own MtlCommandQueue. To make things work correctly, I had to block the render thread on each step until basically the command queues were drained. This extra thread blocking is not efficient and negatively affects frame rate. To fix this in Babylon Native, I exposed BGFX's MtlCommandQueue, which I think is conceptually similar to the solution for the bgfx bug I linked, but with a very different implementation: BabylonJS/bgfx@f029e3d...837be56#diff-e21d7bf6cbe3c2c5f1e6d06dc2159ec61a27860ae4174f2899a238244bd008fa

I think it would be great to have this support in upstream bgfx (not just the Babylon Native fork), but I'm not sure my simple solution is really a good one. I had some other ideas, like maybe expanding the idea of context (for both input and output) to optionally also include a command queue (such that the caller of bgfx can optionally provide the device as well as a command queue). I think for something like this to be clean, bgfx might need platform specific headers to do platform specific operations, but personally I kind of think this should already be true even for things like initialization when a device is provided. Any thoughts on this?

[bkaradzic]

It would be better to come with proposal how this would work with all other backends (not just one/two)...

One thing I've been thinking is callback style mechanism that would invoke in specific view, and provide platform independent render context API which would allow you to retrieve pointers to internal renderer data like queue, textures etc.

Something like:

void customDrawMtl(RendererContextI* _ctx)
{
    MtlCommandQueue* queue = (MtlCommandQueue*)bgfx::getInternalData(_ctx, BGFX_INTERNAL_DATA_QUEUE);
    ...
}

My main concern with exposing queue in different way, for example without callback:

MtlCommandQueue* queue = (MtlCommandQueue*)bgfx::getInternalData(BGFX_INTERNAL_DATA_QUEUE);

is that a lot of users of bgfx are not familiar with threading issues and it will cause too much support burden when they mess it up. Callback forces things to be at least on correct thread when poking internal data.