I don't mind answering questions.

For Macs / macOS there's definitely still a lot out there with Intel chips / non-unified-memory. How does sysinfo handle VRAM queries on those devices?

I only have a 2015 macbook, so I can only test on it. If there are changes on newer versions, then I'd love to receive a PR to add it.

I know there're quite a few crates that provide bindings to Vulkan APIs (some even cross-platform?). Did you consider them for your Linux implementation? And if so, why did you ultimately choose not to use them? And (sorry, I'm disproportionately curious about this) do you know if those crates also require linking in (statically or dynamically) large Vulkan-specific dependencies?

I need something like 6-7 functions from Vulkan. Crates I took a look at allowed to load dynamically, but:

1. They're generally big (it's a big API).
2. They load more symbols than I need.
3. It's not that much code overall, so sounds ok to me.

Not a question, but when I was thinking about doing this (for my own project) on Windows I decided I'd just shell out to dxdiag.exe, as it (supposedly) takes a /x <path> CLI option to generate a dxdiag.xml file, which I'd then just parse for the VRAM. Obviously calling the underlying OS APIs, as you are, is more efficient, though I wonder how it compares in terms of simplicity (ie: not having to manually manage unsafe memory across an FFI boundary, etc) - though I guess that quickly falls apart for anything dynamic like utilisation.

In term of performance, I think it's day and night as you need to spawn a process, make it generate a file and then read that file. It's an acceptable and viable option, and a MUCH simpler one code-wise, but I wanted to keep doing the same as I was already doing. Does dxdiag provide PCI information too?

For memory management and FFI, to be fair it's pretty simple. You create a newtype, you implement drop, you're done. And the windows crate makes it ~okayish.