Feature/queue manager v3 #323
Conversation
1. error_handler function typedef changed 2. DPCTLDevice_Copy, DPCTLQueue_Copy added 3. DPCTLDeviceMgr_GetContextAndDevicePair exported as well as the struct it returns.
SyclQueue(device_selector, props) SyclQueue(sycl_device, props) SyclQueue(sycl_context, sycl_device, props) create SyclQueue from given data. A default asynch error handler is used. The error handler raises SyclAsynchronousError.
Removed get_num_queues, has_cpu_queues, has_gpu_queues. The context manager accepts device selector string, device, or a queue itself.
This way the handler does not use `PyErr_WriteUnraisable`, but uses `PyErr_PrintEx` instead.
to skip tests that would create queue from a device for which it is impossible (like accelerator device with driver installed, but hardware absent)
|
@oleksandr-pavlyk @PokhodenkoSA I am merging this PR as I and @oleksandr-pavlyk have reviewed the changes. The new code requires more test cases, but that can be done as a follow up work. I do not want to keep this open and make it even bigger. |
|
@diptorupd please squash commits in PRs next time. |
|
@PokhodenkoSA I strongly disfavor the practice of enforcing squashing of commits in the PR. Doing so rewrites history (philosophical objection, granted, but development history is lost, commit messages loose their context and relevance, etc.), makes it difficult to share common commits which are not yet in master between branches, and makes it impossible to precision revert one of the faulty commits in the PR later on. |
|
@oleksandr-pavlyk I would like to recommend to make PRs smaller. It is nightmare to review PRs with hundreds lines changed and without proper description. |
|
I think forcing merging PRs is not right way too. If keeping original commits is important for some reason it is ok. |
3 participants
Contains several improvements to queue creation and management. Filter strings are now properly supported, in-order queues may be created, SYCL async errors are handled, and a whole bunch of related changes to both C API and Python API.
This PR is a subset and a cleaned up version of #310 and supersedes that PR.