[L0v2] add multiple submission modes in queue gtests

[EuphoricThinking]

A few solutions and a few questions.

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 (work in progress)
• 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

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 PR 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.

The PR is partitioned into several commits to enable comparison between versions.

Questions:

• 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?
• urCommandBufferCommandExpTest seems to be referenced nowhere, is it needed?

[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

[pbalcer]

Suggested change

	::testing::Values(0)), \
	::testing::Values(0)), // default queue \

[pbalcer]

You duplicated all the print... functions, adding a queue variant. Would it be possible to use the original print function, and then just append the queue mode afterwards? Something like:

inline std::string printImageCopyTestStringMultiQueue(
    const testing::TestParamInfo<typename T::ParamType> &info) {
  auto str = printImageCopyTestString(info); // this info param would need to be converted somehow
  const auto queue_mode = std::get<1>(paramTuple);

  std::stringstream ss;
  ss << str<< "__" << queue_mode;

  return ss.str();
}

[EuphoricThinking]

I think it's possible to rework all of them, I've been just not sure whether we would need them in the future.

[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.