High GPU usage

[mirh]

I get 30% usage on a RTX 3060, as long as the editor is not minimized.
It's not critical, but it seems very very strange.

[KarlitosVII]

It is a bug in my Opengl backend.
I found a workaround, the new version should works.

[mirh]

Mhh nope.
CPU is more or less fine (even though I'm not sure such a simple application is really supposed to use ~2% of cpu sitting there doing nothing), GPU is still super used.

[KarlitosVII]

CPU usage is working as intended because it is immediate GUI instead of more traditional retained mode. And it use less than 1% GPU for me so...

[mirh]

I don't really know what to say.
It happens with both the intel igp, and the nvidia gpu.
And I couldn't check in safe mode because it immediately crashes (I guess it's the graphics api or something missing there)

[Mashrien]

It's still an issue as of 1.5.0 with a 2080super, holds ~30% gpu usage. 4k/60 video playback only uses ~35%

Edit, if the app's working fine on your system (likely because you have the RT/SDK, libs, and whatnot on your dev machine) run the program on another machine that doesn't have the Rust SDK installed, or worst case, in a virtual machine (vmware being free for personal use)

[KarlitosVII]

Can you tell me if this is fixed in 1.6.1 ?

[mirh]

GPU usage is now in the neighbourhood of 10% (rather than 30%), but still it's crazy that there is usage like at all.
Also.... it seems kind of lame to require *vulkan* from such a simple UI, for games themselves that could technically even work with older hardware.

[Mashrien]

It's not fixed completely. It's down to ~18% on a 2080super..
However, it IS "fixed enough"- It's 18% on the lowest P-state of the gpu, it's no longer causing the GPU to clock-up.
Meaning no increased power draw, no increased heat causing the fans to ramp up.

GPU usage is now in the neighbourhood of 10% (rather than 30%), but still it's crazy that there is usage like at all.
Also.... it seems kind of lame to require vulkan from such a simple UI, for games themselves that could technically even work with older hardware.

It's because Rust doesn't have things like WinForms or WPF to work with, or any "real" windowing system like other languages better suited to this kind of project. That said, before I learned C#, I wrote game trainers in Perl, using WinAPI for peek/poke, ReadProcessMemory and WriteProcessMemory. Coders write their apps in whatever language they're comfortable with. This dude's giving out the editor (and I promise hundreds of hours of work) for absolutely free, and even trying to see to our, ultimately inconsequential, complaints about gpu usage.

The GUI is anything but simple, far as I can tell he's actually rendering the UI on the GPU itself using opengl/vulkan, a proper in-game HUD being used to create a GUI for the app. The fact he got it down to <20% on a 300mhz clocked gpu is impressive, imo.

This is very much a satisfactory resolution considering the language and drawing backend/api chosen for the UI, and I'm alright with closing the issue as resolved, personally.

Thanks for this Karlitos :)
Edit/PS: If you're interested in porting this over to C#, I'd be happy to handle the custom UI.. Can easily recreate your UI-design with OwnerDrawn winforms-- I've got a LOT of experience with custom UIs and WinForms, as well as reading/writing custom file formats.

SS from a custom-format archiver I've been working on for 100gb+ archives stored on a NAS (can pull/write individual files from the middle of the archive without having to copy/move the archive, or even read the entire archive), showing MWin, another project for highly customized UIs I wrote many years back.. The archiver is chunk-based, basically a stripped down FAT32 inside a single file so individual chunks can be manipulated.

[KarlitosVII]

Thank you. :)

Indeed, Rust doesn't have a lot of GUI libraries but I could use GTK or a web-view based interface. But, I choose to use Imgui because it is well suited for directly edit big chunk of data like save game are. This is why other save editors use Imgui too (CPSE for Cyberpunk 2077). It's quite customizable and more importantly it's really enjoyable to code with. You can make a complex UI in a few lines of code. Furthermore, it is very reactive. For example, Gibbed's editor can take few second to open a save or to show a collection of hundred entries because in retained GUI you have to refresh the view each time data changed or use proxy view or whatever that can slow down the UI.

The GUI is anything but simple, far as I can tell he's actually rendering the UI on the GPU itself using opengl/vulkan, a proper in-game HUD being used to create a GUI for the app. The fact he got it down to <20% on a 300mhz clocked gpu is impressive, imo.

It's not that complicated, I just use Dear Imgui on top of a graphical back-end. It's very lightweight and >10% GPU usage is really a bug.
For comparison purposes, with my 1060 GTX it permanently use less than 1% GPU and less than 10% CPU when opening Head Morph > Lod0 with thousands of entries.

Anyway, even if it hadn't improved your performance, swaping to Vulkan reduce compile time, file size and a little bit of CPU usage. So, it is clearly a win.

[mirh]

1.7.0 has ~8% rather than the previously reported 10%.

But here's the crazy fun fact: when I put my laptop in optimus mode, my integrated gpu sits at 50%, while the dedicated one is on 30% again.
And it doesn't stop until I close the program (or until I right click on the title bar, which I think stops the UI from running, while the context menu is open)

[mirh]

Sigh, it's not just this program
WerWolv/ImHex#189

[mirh]

Well, turns out limiting framerate from 3000 (TIL) to 64 (I don't know why this odd number) really goes a long way into lowering usage.
(though still far from what you'd expect a static window, let alone that when you drag it around the screen, it lags sooo much)

Still, for the aforementioned reasons, I guess like it's not really your fault specifically.. And I'd rather have you work on those other juicy feature requests than this frontend detail.