Repository navigation
Conversation
The low and high priority flags didn't match the ends of the reported priority range, and devices without priority levels didn't support numeric priorities at all although they support the flags: - zeDeviceGetPriorityLevels only reports the levels of the context group, while ZE_COMMAND_QUEUE_PRIORITY_PRIORITY_LOW uses a separate context that runs below all of them, so the low flag had no numeric equivalent. - The high priority class alone gets the driver's default priority of high priority queues, which may be below the highest priority level. Report one more level below the driver range and create queues at that level with the low priority class and without a priority level, since the driver derives the class from a level. Use the highest level for the high priority flag. Without driver levels, report the range [-1, 1] made of the high, normal and low priority classes, like the v1 adapter. Assisted-By: Claude
The Level Zero v1 adapter supports the low and high priority flags, so also report the priority levels 1, 0 and -1 and create queues with them using the corresponding Level Zero priority classes. Keep the priority class separate from the queue flags, so that UR_QUEUE_INFO_FLAGS only reports the requested flags, and test this for all adapters. Assisted-By: Claude
ldorau
approved these changes
Oct 20, 2026
Comment on lines
+119
to
+121
| if (Range.HasLevels && Range.Highest < 0) | ||
| return {ZE_COMMAND_QUEUE_PRIORITY_NORMAL, Range.Highest}; | ||
| return {ZE_COMMAND_QUEUE_PRIORITY_PRIORITY_HIGH, std::nullopt}; |
Contributor
There was a problem hiding this comment.
Nit: what if the driver reports levels where the highest level is 0 (for example {1, 0})?
Then the HIGH flag uses the high priority class, but the numeric priority 0
(the highest value in the range) uses the normal class with level 0.
So the HIGH flag and the highest numeric priority are not the same queue,
which is what this PR wants to fix.
I guess real drivers always report a negative highest level, so this is OK.
Could you add a short comment about this case?
| #include "queue_immediate_in_order.hpp" | ||
| #include "unified-runtime/ur_api.h" | ||
|
|
||
| #include <algorithm> |
Contributor
There was a problem hiding this comment.
Nit: std::clamp was moved to common/device.hpp, so this include looks unused now.
You can remove it.
Contributor
|
@intel/llvm-gatekeepers please consider merging |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The sycl_ext_oneapi_queue_priority extension defines priority_low and priority_high as the ends of the device's priority range:
SYCL implements these with UR_QUEUE_FLAG_PRIORITY_LOW/HIGH. So for every adapter that supports those flags:
Considering this, the following changes were made:
v2 adapter:
v1 adapter: