oneapi-src
[Bindless][Exp] Windows & DX12 interop. Semaphore ops can take values.
The interop import API has been adapted to cater to multiple external memory and semaphore handle types.
This enables memory and semaphores to be imported by single functions irregardless of what the underlying handle type is.
The following APIs have been removed:
-
ImportExternalOpaqueFDExp -
ImportExternalSemaphoreOpaqueFDExp
The following APIs have been added:
-
ImportExternalMemoryExp -
ImportExternalSemaphoreExp
The following enums have been added:
-
exp_external_mem_type_t -
exp_external_semaphore_type_t
Support has also been added to import DirectX 12 memory and fences.
Semaphore operations (wait/signal) can now take values which set the semaphore state to the value passed by the user.
I think that my comment here: https://github.com/intel/llvm/pull/13860#discussion_r1608052501
applies to all the ur_context_handle_t instances here. They aren't doing anything, and even hypothetically if you were to make a full impl for opencl backend in the future (where the whole context concept comes from), I don't think there would be any functional reason to add a context parameter here:
- Because this is a USM style extension anyway: the user controls memory movement; a concept of memory context serves no purpose.
- Even if it mapped to buffers, functionally for the purpose of interop with opencl you can construct contexts separating cpu and gpu opencl platforms just from using the platform class. In what real situation using modern hardware would you ever use a finer grained usage of "context" in a buffer style program? Does some obscure (and probably badly designed) program mean that we should overcomplicate a (hopefully) widely used programming model for 99.9% of users?
I might be missing something, but to me it looks like this extension is another example of inheriting a useless concept from opencl that has no functional purpose, just because everywhere else does it. If there is a genuine reason for it to be added in all these interfaces then I'd be very happy to be proven wrong.
Pinging @oneapi-src/unified-runtime-bindless-images-write @oneapi-src/unified-runtime-native-cpu-write @oneapi-src/unified-runtime-opencl-write @oneapi-src/unified-runtime-level-zero-write @oneapi-src/unified-runtime-maintain
CI failure seems to be unrelated to any changes I made to the Bindless Images APIs, could be from generating on Windows, will investigate. Either way, all code should be ready for review.
@przemektmalon I've rebased this on top of main which now includes the fix from #1732 so we'll see if the e2e workflow changes are working.
