-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated Driver In order lists check and required version #17620
base: sycl
Are you sure you want to change the base?
Updated Driver In order lists check and required version #17620
Conversation
- Cleaned up the checks for driver in order lists and migrated the check to platform. - Updated version needed to match version with fixes. - Enabled default usage only in L0 core adapter, command buffer is optional - Removed driver workaround in p2p Signed-off-by: Neil R. Spruit <[email protected]>
Signed-off-by: Zhang, Winston <[email protected]>
Signed-off-by: Zhang, Winston <[email protected]>
Signed-off-by: Zhang, Winston <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: Zhang, Winston <[email protected]>
Signed-off-by: Zhang, Winston <[email protected]>
ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled. |
Signed-off-by: Zhang, Winston <[email protected]>
@nrspruit I believe your previous patch had a graph test(s) fail too, I'm not sure if these are similar. We could stagger this change, so we enable in-order command lists by default (if driver version met) on the path without command-buffers, and then do a follow-on PR that enabled it for command-buffers and can resolve these graph fails? |
That appears to be the case. @winstonzhang-intel , please update this patch to specifically disable the command graphs from using driver in order lists unless explicitly requested, but leave the default for the rest of the adapter. That will let us know if the remaining failures are limited to only the command buffers. Then, we can work on a PR to re-enable driver in order lists for command buffers once the failures have been addressed. |
Signed-off-by: Zhang, Winston <[email protected]>
Ok reverted back to when the tests were passing with allowDriverInOrderLists(true) in command buffer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the functionality does not handle all cases of "mixing" driver in order and non-driver in order support, I don't think we can safely split this unless we do a major refactor in the event/queue code paths.
Signed-off-by: Zhang, Winston <[email protected]>
if (OnlyIfRequested) { | ||
const char *UrRet = std::getenv("UR_L0_USE_DRIVER_INORDER_LISTS"); | ||
bool DriverInOrderRequested = UrRet ? std::atoi(UrRet) != 0 : false; | ||
return DriverInOrderRequested; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick, but I'd move this if
to the start of the function before the UseDriverInOrderLists()
lamdba. Otherwise when OnlyIfRequested
is true we're doing the extra work from the lambda call but it doesn't affect the value returned from allowDriverInOrderLists
@nrspruit's patch rebased and posted here as I work on fixing this patch.