search

oneapi-src / level-zero-spec

MIT License
17 stars 26 forks source link

Add IPC event pool function to strip/encode file descriptor from/to IPC event pool handle #205

Open zzdanowicz opened 1 year ago

zzdanowicz commented 1 year ago

Equivalents of functions: zeMemGetIpcHandleFromFileDescriptorExp zeMemGetFileDescriptorFromIpcHandleExp

Function proposals: zeEventPoolGetIpcHandleFromFileDescriptorExp(ze_context_handle_t hContext, uint64_t handle, ze_ipc_event_pool_handle_t *pIpcHandle)

ze_result_t zeEventPoolGetFileDescriptorFromIpcHandleExp(ze_context_handle_t hContext, ze_ipc_event_pool_handle_t ipcHandle, uint64_t *pHandle)

jandres742 commented 1 year ago

@wdamon-intel : I think we can do this w/o problems. we have the ones for memory, we could add the ones for pools, following the same semantics and meaning. this should be easy to do for v1.8.

jandres742 commented 12 months ago

@zzdanowicz please check https://github.com/oneapi-src/level-zero-spec/pull/220

wdamon-intel commented 11 months ago

Moving out of v1.8 Release. Offline review highlighted a need for further discussion.

MichalMrozek commented 9 months ago

We had a discussion on this and IPC should remain opaque, so any API's that expose internal handles / OS details shouldn't be added.

zzdanowicz commented 9 months ago

So adding that two functions to strip wanted data out of opaque handles is justified.

MichalMrozek commented 9 months ago

no , as it would make IPC not opaque.

zzdanowicz commented 9 months ago

Retrieving data from opaque handler by dedicated function is making handler not opaque? We do not reveal memory layout that can change and sounds like contradiction to me - can you expand your thinking?

MichalMrozek commented 9 months ago

to keep it opaque we should never return any handle via any APIs

zzdanowicz commented 9 months ago

So retrieving via API call partial data from opaque handler is not an option? OK, but right now applications are stripping that data directly - this is much worse as driver can change memory layout of the opaque handler and applications would break. With these at least the driver allows for some control over applications.

MichalMrozek commented 9 months ago

yes what is now is much worse, but this is due to the fact that IPC is not opaque. The solution is not to add more API's that return implementation details, but rather make ipc_handles truly opaque and whenever you use IPC you just use IPC opaque structures and nothing else. And yes exposing handles requires underlying implementation to implement IPC using single handle, which reveals' the implementation details and solidifies it.