[L0] Optimize kernel lookup in enqueue

[igchor]

Change unordered_map to vector as number of entries is expected to be low (1 in common case).

Also, do not store mapping between subdevices and the kernel handles. Instead, just look up kernel based on RootDevice handle for a sub device.

Additionally, use unique_ptr to store kernel_handle to avoid memory leaks in case zeKernelCreate fails.

[igchor]

After #1611 I started to look into how rest of the functions in kernel.cpp are implemented and I think some of them might not handle kernels created from native handles and regular ones correctly (when kernel is created for more than one device). For example, here,

unified-runtime/source/adapters/level_zero/kernel.cpp

Line 742 in 056d653

ZE2UR_CALL(zeKernelSetIndirectAccess, (ZeKernel, IndirectFlags));

the properties are only set on the single ZeKernel while all others (from ZeKernelMap) are ignored. Similarly, the properties are only reported for that single ZeKernel:

unified-runtime/source/adapters/level_zero/kernel.cpp

Line 876 in 056d653

ZE_CALL_NOCHECK(zeKernelGetProperties, (ZeKernel, &Properties));

@nrspruit @pbalcer Do you know if this is expected or should those functions actually set/query all ZeKernels from the ZeKernelMap?

[pbalcer]

👍 the next step should be to get rid of zeKernel entirely :)

[pbalcer]

The number of devices is basically set the moment we initialize the driver. In my event cache rewrite, I took advantage of that to give monotonically increasing ID's to the devices, allowing us to make this type of operation a direct lookup in an array.
pbalcer@147f0b4#diff-89d38124dbcf1f91b31dc489a7e7c66bc0e6607ff77f2654810f74eae0826025R205

[igchor]

I also thought about assigning ids to the devices on a context level. But you're right, it would be easier to do that globally, per-driver. We could do that in a separate PR probably.