[draft] Add new experimental entry point for get native mem on device

[hdelan]

Accessor interop requires urMemGetNativeHandle to return a valid mem handle. Multi dev ctx breaks this because a UR mem can be on many different devices now, so we need a new entry point that also takes a device or a queue param.

Will wait until @kbenzie is back to discuss the best approach

[codecov-commenter]

Codecov Report

Attention: 77 lines in your changes are missing coverage. Please review.

Comparison is base (8d1486a) 15.74% compared to head (e4682d9) 15.82%.

Files	Patch %	Lines
include/ur_print.hpp	0.00%	18 Missing ⚠️
source/loader/ur_ldrddi.cpp	48.38%	16 Missing ⚠️
source/loader/layers/validation/ur_valddi.cpp	46.42%	15 Missing ⚠️
source/loader/layers/tracing/ur_trcddi.cpp	54.16%	11 Missing ⚠️
source/adapters/null/ur_nullddi.cpp	37.50%	10 Missing ⚠️
source/loader/ur_libapi.cpp	0.00%	7 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1199      +/-   ##
==========================================
+ Coverage   15.74%   15.82%   +0.08%     
==========================================
  Files         223      223              
  Lines       31466    31591     +125     
  Branches     3556     3578      +22     
==========================================
+ Hits         4953     5000      +47     
- Misses      26462    26540      +78     
  Partials       51       51              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kbenzie]

I think we should just modify the existing GetNativeHandle to add this argument.

[hdelan]

Is that not an ABI breaking change that will take some time to get merged?

[kbenzie]

We don't claim ABI stability in UR at this time, this won't be an issue as long as the necessary SYCL RT changes are made in tandem with this.

[hdelan]

Great thanks @kbenzie . I will close this PR and open a new one with just changes to the existing entry point

[hdelan]

Hi @kbenzie this entry point is needed for both accessor interop as well as buffer interop. So do you think it's OK to have the same entry point for both (as is currently the case)? For accessor interop we can call urMemGetNativeHandle(Mem, Dev, &Handle) and for the buffer interop we just call the same but with the Dev arg as nullptr?

Do you think that is acceptable or should we split this into two entry points, as this PR does?

[kbenzie]

I'm not really sure what the implications are here, would need to have a bit more info about why the buffer interop path differs I think.