Low Vulkan <-> OpenGL interop performance

[MennoVink]

Vulkan

• VK_KHR_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME
• VK_KHR_EXTERNAL_SEMAPHORE_WIN32_EXTENSION_NAME
• VK_KHR_EXTERNAL_FENCE_WIN32_EXTENSION_NAME

OpenGL

• GL_EXT_memory_object
• GL_EXT_memory_object_win32
• GL_EXT_semaphore
• GL_EXT_semaphore_win32

As far as i'm aware this is all that i need to achieve high performance Vulkan to and from OpenGL interoperability. I'm using memory sharing to keep texture data on the GPU and i'm using semaphores so that (in theory) i can keep the pipeline fed without any cpu/gpu sync. My implementation works great on hardware/drivers from a different vendor, but on AMD hardware i'm getting suboptimal performance.

Manual instrumentation shows large amounts of time being spent somewhere inside glSignalSemaphoreEXT. I'm not sure how reliable sampling is without the driver's symbols, but fwiw it shows that the time ends up being spent in GetSettingsBlobsAll. Obviously the driver is a black box to me, but my hunch is that cross-api semaphores aren't really implemented and it does a queue flush, resulting in sync and idle time.
Realistically speaking i need the performance issue solved, and if it's indeed a driver issue i need automated QC in this area on the driver to prevent future interop issues as outlined under the link provided below.
If you nee a repro i can probably cook something up, just assessing if there's any interest in this area before i do that though.

Hardware
RX 7900 XT
driver 25.9.1

Use Case
I'm working on a professional media server controlling audio, video and lights. Our target audience are artists performing anywhere in that space, for example local bars, clubs, theatres, television shows and large outdoor festivals. As for the video side of things you can think of the software as a compositor. Users play/generate video content, apply effects to it and mix it together before projecting it on to the stage.
Great performers provide unique experiences to visitors of any of these venues. This is why our application supports plugins. Plugins are critical to get some stages going, and for historic reasons but also future simplicity, they're implemented using OpenGL.
This is why i'm creating this issue. For us interop is not just an intermediate stage we have to pass through while porting the rest of the application. It's an actual feature we need for years to come and then some more years after that.

Insufficient Workarounds

• We are replacing 80% of plugins by a custom programming environment, the rest is too unique/custom to support in any non-plugin matter.
• Plugins could in theory become vulkan, but vulkan is already hard for professional programmers. Our plugin developers are mostly artists picking up programming just to get something done. Vulkan is too much to ask, nor would we trust them to not make us lose the device.
• There's a good writeup about Zink here https://developer.x-plane.com/2023/02/addressing-plugin-flickering/. I've tried that same path but zink shows too many anomalies to be usable.

[baozholu-AMD]

Could you provide us with a demo that reproduces the issue?

[MennoVink]

13_Interop.zip

This example reproduces it. The interop image is cleared using OpenGL and then exported to vulkan where it's copied to the swapchain image. This example is built using the same graphics engine as the media server application.
No uninstaller, it creates some small files in %localappdata%/mevicg/Interop Example/ which you might want to delete afterwards.

Time spent distribution on RX 7900 XT:

That same example running on RTX 3070

On nvidia the semaphore seems to work appropiately, resuling in higher framerate and thus hitting the flat per-frame swapchain costs more.

[baozholu-AMD]

I run this demo 13_Interop.zip

It switches between black and white, is this the expected phenomenon for this demo? Does Nvidia get higher FPS than AMD when running this demo?

[MennoVink]

That is correct, this example just animates the clear color. It simulates generating content in opengl and exporting it to vulkan to send it to the outputs. This is the opengl code generating the texture you should see (fbo to interop texture is bound externally).

void GLPass::RenderGL( Blackboard& blackboard, ArrayProxy< GLuint > inputs, GLuint outFBOID ) const
{
	static float p = 0.0f;
	p = fmodf( p + 0.01f, Math::TWO_PI );
	float i = sinf( p ) * 0.5f + 0.5f;
	glClearColor( i, i, i, 1.0f );
	glClear( GL_COLOR_BUFFER_BIT );
}

To answer your question, yes the 3070 does run faster than the 7900, but that's not what interests me (i dont even know if they're comparable or of the same generation). What matters most is that when i release the next version of my app (OGL + VK) it must not be slower than the current version (just OGL). On NV my experience is that the OGL+VK version is slightly faster than just OGL whereas on AMD OGL+VK is slower than just OGL.

*edit: According to this benchmark the amd card would be expected to run ~50% faster but in this example it runs about 17% slower. The example runs at a stupidly high framerate though so flat driver overhead could skew things in that regard.
I have a different example that runs just on VK only and does pretty much nothing. That example runs at 0,3ms/f on this card, whereas this VK+GL example runs at 1,0ms/f. If you want, i can send the real world application i'm using this in. It is still in development though so i cant share it publicly.

[baozholu-AMD]

Can the source code for demo 13_Interop.zip be shared publicly? it will significantly expedite the preocess for our developers to find out the root cause and fix it if we can build and debug using the source code directly

[baozholu-AMD]

An internal bug ticket has been created to track this issue, will keep you posted on its progress.

Do you have OGL and Vulkan versions of this demo as well?
When running the demo, how significant is the performance difference between NV and AMD? Could you share the performance data from your tests, such as the FPS?

[MennoVink]

These examples are implemented using proprietary code so sharing cannot be done publicly. I dont think it'll be really useful long-term either though. You'd have to learn how this graphics engine works rather than sticking to the bare minimal gl/vk.
I'm assuming you have an automated performance regression test suite, i think once you've confirmed this issue using this example; you create a test there.

The example accepts F1 keyboard input. The fps will be in the top left, but you have to read fast as the text rendering affects the measurement. A more stable approach would be to open the Vulkan Configurator (from the sdk). Disable all layers except for VK_LAYER_AMD_switchable_graphics and VK_LAYER_LUNARG_monitor, set those two to enabled. Then you can see the fps in the title bar.

13_Interop.zip
Here's a new example, with some changes:

• The image being copied to the screen is now 8K 16bpc (was 2K 8bpc). Realistically speaking this is the highest usable texture format for my users. Doing this gives the gpu a higher load, allowing the amd card to show it is faster when doing actual work.
• Blinking is green to represent OpenGL+interop
• Blinking is red to represent pure Vulkan.
• Press v to switch to Vulkan, press g to switch back to OpenGL+interop.

There is no OpenGL only mode.

Measured using the Vulkan Configurator while having focus on the example's window (somehow focus on the window brings the number down):

~	RTX 3070	RX 7900 XT
GL only	???	???
GL+interop	600fps	1080 fps
VK only	980fps	3050fps

[baozholu-AMD]

Thank you for your prompt and extremely helpful response, our developerss are currently investigating this performance issue, will keep you posted on its progress. Thanks.

[baozholu-AMD]

What is the FPS of the real-world application (VK+GL) that is still in development?
Does this mean there is a published real-world application (GL) available for download from the official website?

[MennoVink]

For this comparison i have these settings in the AMD Software:

• Gaming -> Graphics -> Wait for Vertical Refresh = Off, unless application specifies
• Gaming -> Games -> Arena -> Wait for Vertical Refresh = Always off

I'm running on Threadripper 7970X 32-Cores + RX 7900 XT

This is what i'm comparing with:

1. "Download Arena & Wire" from https://resolume.com/download/
2. Install and start Resolume Arena
3. From the Composition menu, click New
4. Composition menu -> Settings -> change size to 7680 x 4320 (bottom option in drop down) -> Apply
5. From the Sources panel (bottom right) search for "Meta" and drag the Metaballs' Red cells preset onto a big square in the grid
6. Click on the big square in the grid (it will start playing)
7. In the Effects panel (bottom right) search for bloom and drag it onto that same grid cell
8. In the View menu, enable Show FPS & Stats

At this point we've given the gpu some load
The fps is shown in the footer. Using this public release im getting 111 fps.

In the vk+gl version i'm getting 66fps. In the vk+gl version the sources and effects are still rendered in opengl, then sent over to vulkan where it is rendered in the Composition Monitor.
If you can provide me with your e-mail address i can send you a link to the vk+gl build should you want to compare it yourself.

[baozholu-AMD]

Currently, We find some clues from the demo but can not confirm that it also provide significant benefits to the real world application, besides, it will take considerable time for changes to be included in the public Adrenalin driver even if we able identify the root cause and implement a fix now, so it would significantly expedite the fix if we can debug and test with the real world application (Only need the prebuilt executable exe, don't need the source code).

If you can provide me with your e-mail address i can send you a link to the vk+gl build should you want to compare it yourself.

This involve some of personal information, and since the Vulkan-OpenGL version is still in development, and to ensure safety, could you please provide the link here Vulkan-OpenGL_interop_of_Arena_Wire_APP invitations and then return for further communication?

[MennoVink]

I have sent the link. The provided installer will install a separate application. The executable will be known as "Resolume Arena amd interop test". I've found that the GTX 3070 is significantly slower than the 7900XT, 30fps with 7.23.2 (public download). For this interop build however it runs at 38 fps, so it goes up instead of down for some reason (probably replacement of gl context switches by vulkan swapchains). I'd already be happy if the framerate stays the same.

Even though we expect a Q1-2026 release, I'm not in a hurry to get this solved in the public driver. For this first stage we're expecting a smallish number of interops each frame (around 1 to 5 with 2 on average). I'm making optimizations elsewhere in the program to hide this performance hit so only users that end up using more interops will notice it.
Later on we're going to push opengl further back. At that point interops will become bidirectional. Entry users will run without interops, advanced users will use a couple (3ish) and experts could be running any unknown amount (8-25? hopefully less ofcourse)

[baozholu-AMD]

The Vulkan-OpenGL version gets stuck / hang here when I try to launch it, could you please check the "Resolume Arena amd interop test" app that you sent to me?

Besides, could you verify if my reproduction steps are correct?
Running in the official release application