Monitor layer issues

[eero-t]

I noticed few issues in the new Monitor layer:

• When vkreplay loops e.g. short smoketest demo trace, Monitor layer it reports wrong FPS (I guess it depends on length of the loop, in my case Monitor reported 1/4 of the actual FPS)
• No FPS reported for DOTA2 in windowed mode
• No FPS reporting in fullscreen mode

Notes:

• I have a python script that parses ftrace uprobe hits for the Vulkan driver present calls, so I can easily check Vulkan programs' real FPS and verify that problem with vkreplay wasn't monitor overhead, it just reports wrong value
• In the DOTA2 case, the game doesn't do present calls through libvulkan ABI, it seems to call the driver present function directly
• What's the plan for fullscreen mode, drawing FPS on top of the window content?

[TonyBarbour]

• All monitor does is count the number of calls to vkQueuePresentKHR per second - it's hard to get that wrong. Depending on present mode, it's possible that not all of the frames are being displayed, but I would expect monitor to report a higher FPS than the actually displayed FPS.
• I'm having some trouble getting my DOTA2 installation to cooperate and probably won't get back to this until after the holidays. I don't think DOTA2 is bypassing layers for present or we wouldn't be able to trace it.
• I originally tried rendering into the present buffer with monitor, but found that the overhead affected the FPS measurements, especially for high frame rate apps.

[eero-t]

I'm having some trouble getting my DOTA2 installation to cooperate and probably won't get back to this until after the holidays. I don't think DOTA2 is bypassing layers for present or we wouldn't be able to trace it.

I don't get any hits if I attach to DOTA2 with Gdb: gdb /proc/$(pidof dota2)/exe $(pidof dota2)

And check for calls to vkQueuePresentKHR loader function:

(gdb) break vkQueuePresentKHR 
Breakpoint 1 at 0x7f68d1015340
(gdb) c
Continuing.
...

I do get hits to Mesa anv_QueuePresentKHR() function though, so I was thinking that DOTA2 gets the driver function address with the get address call and calls that directly.

In the tracing case, I assume tracing layer returns address for its own present function wrapper to the application (which will call the driver one after saving the call info). You need similar wrapper for that too.

I originally tried rendering into the present buffer with monitor, but found that the overhead affected the FPS measurements, especially for high frame rate apps.

Could be if you're first rendering antialiased TrueType font to bitmap on CPU side, uploading that to GPU and then blending the FPS number bitmap or glyph bitmaps to screen. If you use vertex array(s) for numbers 0-9 and render them directly to screen, number of vertices and the number of affected pixels should be so small that impact on performance is insignificant.

Alternatively, you could output the FPS to a file, at least when program is fullscreen, with "file" defaulting to stdout, until user overrides it e.g. environment variable.

[TonyBarbour]

For DOTA2, are you in windowed mode? With Settings->Video->Display Mode set to "Windowed", I see FPS in the window border. Most of the time - there are some times that all I get is a white screen which I will investigate.

Yes, my experiments in rendering to the presentable image were probably not optimal. The file option is reasonable and I'll add it to the features list.

[eero-t]

In fullscreen. I would assume most people to play action games in fullscreen.

[TonyBarbour]

It looks like the occasional white screen is a result of the message processing thread taking too long to process the WM_SETTEXT message that results from calling SetWindowText from the render thread. This, and your comments about fullscreen make me think that FPS in the title bar is not the way to go. We're planning on adding an auxiliary window to display the output and we can also add a mode that prints to stdout. Would that address your concerns?

[eero-t]

How the auxiliary window would work in fullscreen? If you have separate window, it covers things on screen unless its transparent (which would be even more costly), and it requires separate buffer updates (copies) from X. It wouldn't be visible in fullscreen unless it's override redirect, or you wouldn't have compositing bypass (with more than single window visible). And then, what about Wayland (which doesn't have override redirect)?

Can't you just render few triangles representing number shapes onto current framebuffer, in monitor layer's wrapped Vulkan Present call?

[krOoze]

• Does not work in Xlib (and does not even bother reporting this fact by callback),
• In XCB it seems to overwrite the original title of the window.
• It could perhaps use queue timestamps instead of vkQueuePresentKHR?