[SYCL][Graph] async_malloc use allocation size for zeVirtualMemQueryPageSize

[lslusarczyk]

In L0 we need to call zeVirtualMemQueryPageSize with the actual allocation size for the virtual/physical allocations to align correctly.

Right now we check alignment without passing any size: https://github.com/intel/llvm/blob/sycl/sycl/source/detail/graph/memory_pool.cpp#L45

This ends up translating to 1 byte in the call to L0: https://github.com/oneapi-src/unified-runtime/blob/de05f984aa19458a4993d2a2709e3b79d82f1a37/source/adapters/level_zero/virtual_mem.cpp#L32-L37 and for large allocations a wrong alignment is used and L0 reports ZE_RESULT_ERROR_UNSUPPORTED_SIZE upon zePhysicalMemCreate call (UR fails with UR_RESULT_ERROR_INVALID_VALUE then).

The UR API should change to accept a size.

This PR exposes this issue in a unittest and fixes it.

[EwanC]

LGTM, thanks

[reble]

@intel/llvm-reviewers-runtime ping

[aelovikov-intel]

On the one hand, I'd like us to move to a future where sycl::<object> aren't used inside source/detail and instead code there operates on <object>_impls only. On the other hand, implementation isn't under source/detail (why?) and get_ur_handles is designed to work on sycl::<object> so changing signature would probably make the code uglier.

As such, I think the "why?" above is what really matters here.

[lslusarczyk]

I do not feel competent enough to answer. I've kept implementation in the place where it existed so far. I see no clear criteria why some .cpp files are in sycl/source and other in sycl/source/detail

@aelovikov-intel , do you want us to work on this further in this PR or can we merge without going deep into this? If we can merge, do you have permissions to do so or shall I ask someone else?

[aelovikov-intel]

Ok, let's change this new overload to accept device_impl & and context_impl &. You'd need to add another overload to helpers at

llvm/sycl/source/detail/context_impl.hpp

Lines 364 to 384 in 004f38e

	// We're under sycl/source and these won't be exported but it's way more
	// convenient to be able to reference them without extra `detail::`.
	inline auto get_ur_handles(sycl::detail::context_impl &Ctx) {
	ur_context_handle_t urCtx = Ctx.getHandleRef();
	return std::tuple{urCtx, &Ctx.getAdapter()};
	}
	inline auto get_ur_handles(const sycl::context &syclContext) {
	return get_ur_handles(*sycl::detail::getSyclObjImpl(syclContext));
	}
	inline auto get_ur_handles(const sycl::device &syclDevice,
	const sycl::context &syclContext) {
	auto [urCtx, Adapter] = get_ur_handles(syclContext);
	ur_device_handle_t urDevice =
	sycl::detail::getSyclObjImpl(syclDevice)->getHandleRef();
	return std::tuple{urDevice, urCtx, Adapter};
	}
	inline auto get_ur_handles(const sycl::device &syclDevice) {
	auto &implDevice = *sycl::detail::getSyclObjImpl(syclDevice);
	ur_device_handle_t urDevice = implDevice.getHandleRef();
	return std::tuple{urDevice, &implDevice.getAdapter()};
	}

, but that would be trivial.

[lslusarczyk]

OK. I've applied. Please check the last commit if this is what you wanted.

[lslusarczyk]

@intel/llvm-gatekeepers , could you please merge? There are all approvals and the only one failed job is validate_email, which is due to faulty CI change from yesterday (I've checked with @uditagarwal97 - author of the checker change that there is no problem with my email). Please merge.