API for supporting fences

[nachogarglez]

Dear all,

I am working on a project that uses BGFX as a headless library, for drawing on a texture that comes from a DirectX12 video pipeline.

In order to ensure that the texture has indeed been rendered by the GPU before continuing to send it through the video pipeline, I have implemented a minimal API for DirectX12 only at the moment. It is available in our fork at fluendo@4bd66d0

In this way, my code for a frame looks like this:

[Init]
m_fence = bgfx::createFence(0 /*initial fence value*/, 0 /*flags, not implemented yet*/);

[Render method]
.
void renderSomeThing (..... )
{
.
.
.
m_fenceValue++;
bgfx::fenceSignal(m_fence, m_fenceValue);
bgfx::frame();
bgfx::fenceWaitCPUSide(m_fence, m_fenceValue);
}

I wanted to discuss it here for your opinions on the convenience of having this type of API officially, and of course, so that others with the same need can find it.

Greetings to all,

Nacho Garcia
Fluendo SL

[bkaradzic]

Fences are too low-level concept to belong to bgfx API.

It would be better if you used frame number when result is 100% available, instead fence that would give you mid-frame result or that blocking API you have:
https://bkaradzic.github.io/bgfx/bgfx.html#_CPPv4N4bgfx11readTextureE13TextureHandlePv7uint8_t

[nachogarglez]

Okay, I understand that it's a low-level concept. I am enhancing fences by incorporating the capability to wrap externally created textures (fluendo#1), and my next step is to synchronize both libraries (BGFX and the video library) to utilize fences on the GPU side and avoid CPU blocking.

Thank you for your response and thanks a lot for all your work :-)

[nachogarglez]

I tried using bgfx::overrideInternal, but I found it tremendously confusing due to the need for a separate thread (or so I believe) and because you can't override internal until the texture has been created in the render thread. After several unsuccessful attempts, I decided to create that API to wrap textures, which seemed simpler to me. The number of textures in the pool is fixed, so I simply initialize both libraries by sharing the same textures in the pool.

As for the idea that calling bgfx::frame twice ensures that the GPU finishes its work, it's something I suspected but couldn't confirm by reading the code, so I opted to use fences.

[bkaradzic]

bgfx::overrideInternal just need to be executed on thread that calls bgfx::renderFrame because it's poking data of that particular thread.

I might add bgfx::createTexture API that would take uintptr_t with override, and then internally if it does have override it will not create texture rather, just use that pointer.

[nachogarglez]

A question about this, something that is not very clear to me when textures are shared between libraries: What happens to the current state of the resource? In my wrapping API, I added two parameters (pointer and current state) to place the corresponding barrier in the state needed by BGFX, and similarly, from the other library, I obtain the last state of the resource. Do you know if this is really necessary, or does the state of the resource only matter within each Queue?

[bkaradzic]

That's why I said to use 2x bgfx::frame as "fence", because before and after 2 frame calls state is known/default. Likewise if you're doing something outside of bgfx, you should make sure resource is in default state as it would be in bgfx.

[nachogarglez]

Thank you very much for your responses and information about how BGFX works internally. I will keep that in mind.