-
Notifications
You must be signed in to change notification settings - Fork 166
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
[DFT] Allow the descriptor to be modified and recommitted #282
Conversation
aad7522
to
35f0e3b
Compare
461f11c
to
c7cc568
Compare
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.
I think the biggest challenge is what to do in situations that the spec doesn't cover - eg. changing queue or backend for the descriptor.
ece0cc4
to
924a08d
Compare
Log of the test runs. My machine only supports single precision and through opencl, but I hope this demonstrates the descriptor tests are passing. |
Next time this needs to be rebased you could fix the typo |
} | ||
pimpl_.reset(detail::create_commit(*this, queue)); | ||
} | ||
pimpl_->commit(values_); | ||
} |
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.
Maybe it's worth adding a recommit_values
test which would change the queue between commit calls?
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.
I've added a tests to show that there is a wait on the old queue here 088fa08
I was unable to prove that work is submitted to the new queue or not submitted to the old.
- I don't believe there is any direct way to query if a queue has not completed tasks
- I don't believe there is a way to query if an event is associated with a task.
- When an command group function object is submitted to the queue, I don't believe there are any guarantees that is will complete before slow work on other queues.
Because of all this I can't think of how to test that reliably.
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.
Thank you for that. I think you're right for every bullet point you mentioned and I'm sorry if my original suggestion generated complications/misunderstanding on the testing scope. Those changes look fine to me.
To be clearer, my original concern was about a use case like
- create a descriptor
desc
; - create a queue
q1
and commitdesc
toq1
; - delete
q1
; - create a queue
q2
and commitdesc
toq2
; - submit a compute task to
desc
.
I am not 100% sure this works as expected for the closed-source mkl. But that is something we can/should check on our side as that would be an issue for us to fix anyways. We may consider this thread resolved.
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.
Ok, that's interesting. I think this should work because objects like sycl::queue
are kept alive by the SYCL runtime with reference counting semantics. I guess I could have a test that follows the steps you've detailed, waits on q2
and then shows that the event returned from the task is complete. It's not perfect but its something. I'm about to finish for the day but I'll do this sometime tomorrow.
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.
I've added a test for that in 8d0a608
1d17c5c
to
088fa08
Compare
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.
Thank you for your work!
@FMarno conflicts need to be resolved before I can merge this. Thanks! |
Also reported error in cpu backend
d6a5430
to
4259829
Compare
In the last rebase I made some changes to compute_inplace.hpp and compute_out_of_place.hpp which meant the same descriptor was used twice with a recommit in the middle to update the strides. Here is evidence of the passing tests. I still only have access to single precision and the OpenCL backend - |
Description
Allows the descriptor class for DFTs to be modified and recommitted. Some backends will likely need to regenerate the descriptor completely, but this will allow for those that don't.
This builds on top of #259
Checklist
All Submissions
New features