Skip to content

Conversation

@EuphoricThinking
Copy link
Contributor

@EuphoricThinking EuphoricThinking commented Dec 28, 2025

Modifications allow for running tests with different queue submission modes, either specified by the user or provided by default. This is made possible through the introduced macros:

  • UUR_INSTANTIATE_DEVICE_TEST_SUITE_MULTI_QUEUE(FIXTURE): instantiates the provided FIXTURE with the submission modes: UR_QUEUE_FLAG_SUBMISSION_BATCHED and UR_QUEUE_FLAG_SUBMISSION_IMMEDIATE
  • UUR_MULTI_QUEUE_TYPE_TEST_SUITE_WITH_PARAM(FIXTURE, VALUES, PRINTER): similarly instantiates the FIXTURE with either batched or immediate submission modes, but additionally accepts parameters
  • UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES(FIXTURE, MODES): instantiates the provided FIXTURE with queue submission modes provided by the user
  • UUR_DEVICE_TEST_SUITE_WITH_DEFAULT_QUEUE(FIXTURE): provides only one default submission mode (specified as 0); the exact mode is chosen by the device
  • UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES_PRINTER(FIXTURE, MODES, PRINTER): similar to UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES, but the user also provides the PRINTER function
  • UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES_AND_PARAM(FIXTURE, VALUES, MODES, PRINTER): similar to UUR_MULTI_QUEUE_TYPE_TEST_SUITE_WITH_PARAM, but the user also provides queue submission modes

At this moment, UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES_AND_PARAM is not used in any test. As a helper intended for parametrized tests, this macro is complementary to UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES, which enables the user to specify queue submission modes for unparametrized tests. Example usage:

UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES_AND_PARAM(
    urEnqueueMemBufferFillTest, testing::ValuesIn(test_cases), testing::ValuesIn(UR_QUEUE_FLAG_SUBMISSION_BATCHED,
                                        UR_QUEUE_FLAG_SUBMISSION_IMMEDIATE),
    uur::printFillTestStringMultiQueueType<urEnqueueMemBufferFillTest>);

Tests that do not use any queue (like most of the urProgramTests, except for urProgramSetSpecializationConstantsTest) are instantiated using UUR_DEVICE_TEST_SUITE_WITH_DEFAULT_QUEUE. There might be more tests that do not need a queue, since the heuristic for determining whether the given test needs a queue consisted of checking whether the queue defined in the test class is mentioned in the test file (not checked per derived test class).

This patch introduces equivalents for urQueueTest for unparametrized tests and urQueueTestWithParam, which are urMultiQueueTypeTest and urMultiQueueTypeTestWithParam, respectively. Parametrized tests use a new parameter type: MultiQueueParam (std::tuple<T, ur_queue_flag_t>). Similarly, the previously "unparametrized" tests, which were eventually parametrized with the DeviceTuple, now use std::tuple<DeviceTuple, ur_queue_flag_t> as their parameter type.

Additionally, urCommandBufferCommandExpTest is removed since it is not referenced anywhere.

@EuphoricThinking EuphoricThinking requested review from a team as code owners December 28, 2025 16:02
@EuphoricThinking EuphoricThinking force-pushed the batch_TEST4_gtest_pr1 branch 3 times, most recently from e193914 to 8a4d851 Compare December 29, 2025 16:01
@EuphoricThinking EuphoricThinking changed the title add multiple submission modes in queue gtests [L0v2] add multiple submission modes in queue gtests Dec 30, 2025
@EuphoricThinking EuphoricThinking marked this pull request as draft December 30, 2025 03:12
@pbalcer
Copy link
Contributor

pbalcer commented Jan 7, 2026

For features unsupported in batched queues, batched submission mode is omitted in instantiation. Is it better to use previously introduced SKIP_IF_BATCHED macro instead?

I would prefer the latter if its related to functionality we want to eventually support. SKIP_IF_BATCHED is going to be easier to spot. Otherwise I'd leave it as-is, with a comment why test doesn't make sense on a batch queue.

urCommandBufferCommandExpTest seems to be referenced nowhere, is it needed?

Let's just remove it.

Copy link
Contributor

@pbalcer pbalcer left a comment

Choose a reason for hiding this comment

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

broadly lgtm

@EuphoricThinking
Copy link
Contributor Author

For features unsupported in batched queues, batched submission mode is omitted in instantiation. Is it better to use previously introduced SKIP_IF_BATCHED macro instead?

I would prefer the latter if its related to functionality we want to eventually support. SKIP_IF_BATCHED is going to be easier to spot. Otherwise I'd leave it as-is, with a comment why test doesn't make sense on a batch queue.

@pbalcer At this moment EnqueueTimestamp and USM alloc/free are omitted (at least as I remember). Do they qualify for SKIP_IF_BATCHED?

@pbalcer
Copy link
Contributor

pbalcer commented Jan 7, 2026

For features unsupported in batched queues, batched submission mode is omitted in instantiation. Is it better to use previously introduced SKIP_IF_BATCHED macro instead?

I would prefer the latter if its related to functionality we want to eventually support. SKIP_IF_BATCHED is going to be easier to spot. Otherwise I'd leave it as-is, with a comment why test doesn't make sense on a batch queue.

@pbalcer At this moment EnqueueTimestamp and USM alloc/free are omitted (at least as I remember). Do they qualify for SKIP_IF_BATCHED?

Yes, we will definitely want to implement these features on the batch queue.

@EuphoricThinking EuphoricThinking force-pushed the batch_TEST4_gtest_pr1 branch 2 times, most recently from 641fd6e to c62389c Compare January 9, 2026 15:08
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd say - bump dates -2026 😉

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As you wish c;

@EuphoricThinking EuphoricThinking force-pushed the batch_TEST4_gtest_pr1 branch 3 times, most recently from 6255673 to 989a76e Compare January 19, 2026 15:00
@EuphoricThinking EuphoricThinking marked this pull request as ready for review January 19, 2026 15:01
@EuphoricThinking
Copy link
Contributor Author

For features unsupported in batched queues, batched submission mode is omitted in instantiation. Is it better to use previously introduced SKIP_IF_BATCHED macro instead?

I would prefer the latter if its related to functionality we want to eventually support. SKIP_IF_BATCHED is going to be easier to spot. Otherwise I'd leave it as-is, with a comment why test doesn't make sense on a batch queue.

@pbalcer At this moment EnqueueTimestamp and USM alloc/free are omitted (at least as I remember). Do they qualify for SKIP_IF_BATCHED?

Yes, we will definitely want to implement these features on the batch queue.

I would prefer to leave EnqueueTimestamp and USM alloc/free for the next PRs, which should implement the missing functionalities.

Modifications allow for running tests with different queue submission
modes, either specified by the user or provided by default. This is
made possible through the introduced macros:
- UUR_INSTANTIATE_DEVICE_TEST_SUITE_MULTI_QUEUE(FIXTURE):
instantiates the provided FIXTURE with the submission modes:
UR_QUEUE_FLAG_SUBMISSION_BATCHED and UR_QUEUE_FLAG_SUBMISSION_IMMEDIATE
- UUR_MULTI_QUEUE_TYPE_TEST_SUITE_WITH_PARAM(FIXTURE, VALUES,
PRINTER): similarly instantiates the FIXTURE with either batched or
immediate submission modes, but additionally accepts parameters
- UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES(FIXTURE, MODES):
instantiates the provided FIXTURE with queue submission modes
provided by the user
- UUR_DEVICE_TEST_SUITE_WITH_DEFAULT_QUEUE(FIXTURE): provides only
one default submission mode (specified as 0); the exact mode is chosen
by the device
- UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES_PRINTER(FIXTURE, MODES,
PRINTER): similar to UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES, but
the user also provides the PRINTER function
- UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES_AND_PARAM(FIXTURE, VALUES,
MODES, PRINTER): similar to UUR_MULTI_QUEUE_TYPE_TEST_SUITE_WITH_PARAM,
but the user also provides queue submission modes

At this moment, UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES_AND_PARAM is
not used in any test. As a helper intended for parametrized tests,
this macro is complementary to UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES,
which enables the user to specify queue submission modes
for unparametrized tests. Example usage:

UUR_DEVICE_TEST_SUITE_WITH_QUEUE_TYPES_AND_PARAM(
urEnqueueMemBufferFillTest,
testing::ValuesIn(test_cases),
testing::ValuesIn(UR_QUEUE_FLAG_SUBMISSION_BATCHED,
               UR_QUEUE_FLAG_SUBMISSION_IMMEDIATE),
uur::printFillTestStringMultiQueueType<urEnqueueMemBufferFillTest>);

Tests that do not use any queue (like most of the urProgramTests,
except for urProgramSetSpecializationConstantsTest) are instantiated using
UUR_DEVICE_TEST_SUITE_WITH_DEFAULT_QUEUE. There might be more tests
that do not need a queue, since the heuristic for determining whether
the given test needs a queue consisted of checking whether the queue
defined in the test class is mentioned in the test file (not checked
per derived test class).

This patch introduces equivalents for urQueueTest for unparametrized
tests and urQueueTestWithParam, which are urMultiQueueTypeTest and
urMultiQueueTypeTestWithParam, respectively. Parametrized tests use
a new parameter type: MultiQueueParam (std::tuple<T, ur_queue_flag_t>).
Similarly, the previously unparametrized tests, which were eventually
parametrized with the DeviceTuple, now use std::tuple<DeviceTuple,
ur_queue_flag_t> as their parameter type.

Additionally, urCommandBufferCommandExpTest is removed since it is not
referenced anywhere.
@kswiecicki
Copy link
Contributor

I see that this PR needs @intel/sycl-graphs-reviewers approval, could someone take a look at this please. The changes to unified-runtime/test/conformance/exp_command_buffer/* tests are minimal.

@kswiecicki kswiecicki merged commit 64481e4 into intel:sycl Jan 21, 2026
15 checks passed
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.

5 participants