first of all im very happy to see these changes, thank you very much!
Besides the comments i attached to the code, id like to say that we have an option with which we can "force" the correct gpu. So, while i know that amd gpus will we recognised as gpu="Advanced" (because of advanced micro devices being spelled out), im not sure for intel. if you know which name intel gets, you could write an elif that captures amd and intel, with the else remaining unknown. alternatively you could just capture amd for now, and until we know how intel is recognised, we ask intel users to force the "Advanced" for it to work.

That's a great point. There should still be an unknown fallback.

I'll see if I can beg/borrow/steal an Intel laptop at work to test it on.

Though that raises an interesting question. As is, it detects multiple GPUs that share the data source structure, but having it handle something like an integrated Intel with discrete Nvidia or AMD, as many laptops have, would be handy. I have neither... but again, work may have something I can pilfer for a day.

I can only find devices with Intel and Matrox iGPUs, no discreet or Arc ones.

What I have show up asIntel orMatrox respectively but cannot use this workflow to collect the needed data so only using this forAdvanced is the way to go.

awesome! the only thing left to talk about is the normalize_percent_len that you removed

The values returned by vram and power aren't single entry percentages (##.#GB/##GB, and ###W/###W) so it over pads slightly. Each additional gpu doubles that padding leading to almost having as much whitespace between VRAM and the values as the values themselves take up.

that is fair, but taking away the padding from the other options isnt necessarily the way to go either. do you think you can figure out a solution where amd is unpadded but nvidia and apple keep their padding?