Skip to content

Conversation

@smaslov-intel
Copy link
Contributor

No description provided.

@smaslov-intel smaslov-intel requested a review from a team as a code owner March 30, 2023 23:24
auto TID = std::this_thread::get_id();
auto &InitialGroup = Queue->ComputeQueueGroupsByTID.begin()->second;
const auto &Result =
Queue->ComputeQueueGroupsByTID.insert({TID, InitialGroup});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This code was doing wrong it used the same ZeQueues for the new entry so it is then was destroyed multiple times causing a segfault. Now, without per-thread setting we don't even create multiple entries, and we do per-thread then the new entry is properly initialized here: https://github.com/intel/llvm/pull/8896/files#diff-1f19baf7cc76d94bf4a1819c81e7b34292fb3ce215cd50873e8c9236cc73601cR501

Copy link
Contributor

Choose a reason for hiding this comment

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

This feature was for immediate command lists only. So the zeQueues should have been unallocated. Have you extended it for command queues also?

Copy link
Contributor

Choose a reason for hiding this comment

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

So now the vector of ZeQueues is now separate for each entry?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is still for immediate command-lists only, but it is safer to initialize ZeQueues to null for safety

Copy link
Contributor

Choose a reason for hiding this comment

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

But that value should have been a null, and the zecommandqueuedestroy should not have been called. But it did get called, which means that the vector of zequeus has to be explicitly set to nullptrs. OK.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it was nullptr but then a call togetZeQueue created a non-null one: https://github.com/intel/llvm/pull/8896/files#diff-15dd1eb076d2164bd9e87d9057f05f652a716498e8cdf5975e564c65309a0985L2843

That non-null value was then copied to yet a new entry created for another thread.

Copy link
Contributor

Choose a reason for hiding this comment

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

The perThread and getNative don't mix well. Say you have a queue that uses multiple cmd lists, one per thread. Someone calls getNative, makes his own queue from it and assumes that a sync on that queue is also a sync on the original queue. But it isn't because only one cmd list will be synch'ed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, but the failure was even without per-thread requested. We still created multiple redundant entries, which additionally held the same queues. I don't think that syncing a queue returned by a get_native() gives any guarantees about the entire SYCL queue being synced.

Copy link
Contributor

Choose a reason for hiding this comment

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

That insert was supposed to be "insert if not found".

@smaslov-intel smaslov-intel requested a review from rdeodhar March 30, 2023 23:27
Signed-off-by: Sergey V Maslov <[email protected]>
@smaslov-intel smaslov-intel temporarily deployed to aws March 31, 2023 01:42 — with GitHub Actions Inactive
@smaslov-intel smaslov-intel temporarily deployed to aws March 31, 2023 03:20 — with GitHub Actions Inactive
@againull againull merged commit 0749e4f into intel:sycl Mar 31, 2023
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.

3 participants