Add zelReloadDrivers(flags) API #191
Conversation
lisanna-dettwyler
force-pushed
the
zelreloaddriver
branch
2 times, most recently
from
8804e8a
to
8433b6b
Compare
| if (drv.handle) { | ||
| auto free_result = FREE_DRIVER_LIBRARY( drv.handle ); | ||
| auto failure = FREE_DRIVER_LIBRARY_FAILURE_CHECK(free_result); | ||
| if (failure) | ||
| return ZE_RESULT_ERROR_UNINITIALIZED; | ||
| } |
There was a problem hiding this comment.
So overall I would ask if there is any advantage to separating this step out into it's own API of zelUnloadDriversInternal() at least initially and possibly even into user exposed API in the future. I think fine for doing a proof of concept... Down the road this would give the option of changing which drivers were re-initialized for whatever reason.
There was a problem hiding this comment.
2nd thought here, would be we could simplify the load step.... by removing unload... But in contrast we could then improve the unload step by adding state machine checking if any was necessary... i.e. are there any conditions in which unload was not allowed, or if a timeout/wait was necessary to kill in flight commands before catastrophic teardown.. (I realize this doesn't really need to be enforced here, as we could put that responsibility on the user and effective document 'use at your own risk')
There was a problem hiding this comment.
Down the road this would give the option of changing which drivers were re-initialized for whatever reason.
I think in order to have that we would need it to operate only on a single driver, rather than separating load/unload.
are there any conditions in which unload was not allowed
I agree it's on the user to not call this if they expect in-flight things to finish, so I don't think we need to count that as one such condition. If we end up adopting this, we should document that all prior resources / handles are invalidated and that new ones will need to be obtained.
|
I guess the theory here is that an application could use this to guarantee a clean slate if hardware resources change out from underneath a driver library. The only concerns I have with this are that it may be more straightforward to have it re-init only a passed in driver handle rather than all of them, but I couldn't get the handle typecasting to work inside of ze_loader_api.cpp; that I'm adding another location where I've manually written out something that is normally autogenerated; and that the debug trace logging functions aren't available for any of the failure cases. I still need to add a null driver test to verify that this works. |
lisanna-dettwyler
force-pushed
the
zelreloaddriver
branch
2 times, most recently
from
dc926b2
to
3878b3b
Compare
Provides a means to re-initialize all of the drivers' library handles and DDI tables. The value of flags must match what was provided to zeInit(flags). Signed-off-by: Lisanna Dettwyler <[email protected]>
lisanna-dettwyler
force-pushed
the
zelreloaddriver
branch
from
3878b3b
to
ad076d3
Compare
Provides a means to re-initialize all of the drivers' library handles and DDI tables. The value of flags must match what was provided to zeInit(flags).