Skip to content
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

Open
wants to merge 9 commits into
base: sycl
Choose a base branch
from

Conversation

winstonzhang-intel
Copy link
Contributor

@winstonzhang-intel winstonzhang-intel commented Mar 24, 2025

@nrspruit's patch rebased and posted here as I work on fixing this patch.

  • Refactor's the check for driver in order lists into one place, but still disables driver in order lists by default.

yingcong-wu and others added 2 commits March 24, 2025 22:29
- 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]>
Copy link
Contributor

@nrspruit nrspruit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@nrspruit
Copy link
Contributor

ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled.

@EwanC
Copy link
Contributor

EwanC commented Mar 28, 2025

ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled.

@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?

@nrspruit
Copy link
Contributor

ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled.

@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.

@winstonzhang-intel
Copy link
Contributor Author

ok, unfortunately, it appears the command graph functionality fails if one runs with the driver in order lists enabled.

@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.

Ok reverted back to when the tests were passing with allowDriverInOrderLists(true) in command buffer.

Copy link
Contributor

@nrspruit nrspruit left a 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.

Comment on lines +515 to +519
if (OnlyIfRequested) {
const char *UrRet = std::getenv("UR_L0_USE_DRIVER_INORDER_LISTS");
bool DriverInOrderRequested = UrRet ? std::atoi(UrRet) != 0 : false;
return DriverInOrderRequested;
}
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants