[L0v2] add multiple submission modes in queue gtests

[EuphoricThinking]

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.

[pbalcer]

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.

[pbalcer]

broadly lgtm

[EuphoricThinking]

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]

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.

[lukaszstolarczuk]

I'd say - bump dates -2026 😉

[EuphoricThinking]

As you wish c;

[EuphoricThinking]

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.

[kswiecicki]

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.