Valve Has Been Working On A HUD For The RADV Vulkan Driver

[phoronix]

Phoronix: Valve Has Been Working On A HUD For The RADV Vulkan Driver

It hasn't been merged to Mesa 18.3-devel yet nor even published on the Mesa-dev list for review, but it turns out Valve's Samuel Pitoiset has begun working on a heads-up display (HUD) for the driver...

http://www.phoronix.com/scan.php?pag...ve-HUD-Display

[[email protected]]

How about doing it in a generic way, as a validation layer (maybe with a few extensions to cover some driver-specific info)? I could see that being useful for ANV and others as well.

IIRC, that's how the steam overlay is implemented under Vulkan.

[FireBurn]

Would be good if all the hud stuff could be factored out and shared between implementations, the bits of the code that get temperatures, processor clocks could all be shared

[Michael]

How about doing it in a generic way, as a validation layer (maybe with a few extensions to cover some driver-specific info)? I could see that being useful for ANV and others as well.

IIRC, that's how the steam overlay is implemented under Vulkan.

Currently it's all just in RADV driver code right now... I imagine doing it as a validation layer might be possible moving forward, there is the new driver properties query extension that might allow exposing FPS and other data/perf metrics, but haven't looked at that new extension closely yet to see if it would allow offering that sort of data nicely in a standardized way. As currently there is no cross-driver uniform way for exposing the clocks, FPS, etc.

[theghost]

Phoronix: Valve Has Been Working On A HUD For The RADV Vulkan Driver
This morning I stumbled across Samuel's radv_hud branch of Mesa.
http://www.phoronix.com/scan.php?pag...ve-HUD-Display

The usual morning branch walk around Mesa

[aufkrawall]

How about doing it in a generic way, as a validation layer (maybe with a few extensions to cover some driver-specific info)? I could see that being useful for ANV and others as well.

IIRC, that's how the steam overlay is implemented under Vulkan.

Injecting overlays often has compatibility issues, while a proper driver solution doesn't. To have it only in radv would also be a great progress over status quo. So, even if you prefer a generic solution, I think you can appreciate it.

[[email protected]]

Injecting overlays often has compatibility issues, while a proper driver solution doesn't. To have it only in radv would also be a great progress over status quo. So, even if you prefer a generic solution, I think you can appreciate it.

That might be true, especially in the case of injecting them trough LD_PRELOAD. However, Vulkan validation layers were designed with this in mind. Could you point to a single instance of them not working?
And you are right as well, but that doesn't mean that the overlay couldn't cooperate more with radv than the Vulkan spec allows. In any case, I am not against an overlay, I just wondered if there was any technical blocker to sharing most of the code.
Plus, having a unified interface to setup the overlay and gather data would be nice, for control panels as well as Michael and his benchmarks!

[gurv]

I really, really like GALLIUM_HUD!
So if we can get similar functionality (fps, gpu load, cpu load, vram usage, temperature, frequency etc.) for Vulkan, it would be awesome!
Thanks Samuel / Valve