@supple valve could you please add a comment to this issue registering your interest?
https://github.com/GPUOpen-LibrariesAndSDKs/ADLX/issues/9
I can bring it up with Eric in the mean time
#Is there still no API for retrieving the GPU UUID on windows?
1 messages · Page 1 of 1 (latest)
will do
I'll schedule a message to him now
https://discord.com/channels/1239631572886491286/1509257333379956887
fwiw I filed an issue for it, link in this thread
oh, interesting. I'm not sure if ADLX will intersect with the rocm SMI...
I guess SMI could be seen as cross platform once it's more built out on windows
ADLX is more gaming focused, though unfortunately this is specific to windows.
would that be a viable path for your needs?
(i'm also happy to pursue the HIP issue)
the IADLXGPU->UniqueID() API also returns an incorrect value and is not usable from my test, it would be great if that could be fixed also
honestly anything that can get a valid UUID that's identical to the one retrieved from amd-smi would work from our perspective, HIP or ADLX
appreciate your time for looking this over!
happy to help. we'll do what we can
I'll see what we can learn about the SMI bug on Windows as well.
hm, the adlx method requires support from the kernel mode driver. I'm wondering if this is also the case for the rocm SMI.
I'll speak to some friends in kmd
upon a closer look, it seems the serial is already mapped into usermode memory with a giant NtGdiDdDDIQueryAdapterInfo call, so umd should have access to it already
I guess there's just no usermode API hooked up to parse the structure properly yet
I'll pass that on to eric
@supple valve if you use QueryAdapterInfo, does that also return a null value?
that should expose the serial number from the win gfx kmd
Well I don’t know the correct offset in the umd private data blob, but the serial is definitely in there
hip and adlx get it wrong though so what’s returned from their APIs is incorrect
If the blob layout is hardcoded I guess I can also just hardcode an offset and make an API myself
QueryAdapterInfo seems to only accept a few sizes, the one I needed being 0x4360, any larger or smaller the call simply fails to populate any data
i see. I'll discuss exposing that property via adlx with eric as soon as
the smi route will take me a little longer to get started on
so this interface definitely can work with adlx,, Eric quickly tested this and it does indeed work
the hurdle there is getting that new feature aligned to a release, I think 1.5 just came out, 1.6 is likely still a ways out