8000 Fix clc device selection on multi-device platform by dlopr · Pull Request #788 · uxlfoundation/oneapi-construction-kit · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix clc device selection on multi-device platform #788

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dlopr
Copy link
Contributor
@dlopr dlopr commented Apr 24, 2025

If a platform reports multiple devices, they will all have the same name and --device selection will be ambiguous.

This adds a --device-idx cmd-line option to directly select by index.

@coldav
Copy link
Collaborator
coldav commented Apr 25, 2025

Hi, it would be good to get some context. Why would the devices have the same names?

@dlopr
Copy link
Contributor Author
dlopr commented Apr 25, 2025

Hi, it would be good to get some context. Why would the devices have the same names?

Maybe they shouldn't. The problem is that hal::hal_t::device_get_info returns a pointer for some reason. So an implementator is forced to keep that object alive. I guess an option would be to keep a vector of infos, one per device even if they only differ in the name, but that feels rather silly and I thought this wouldn't hurt.

For more context, see the hal_refsi_tutorial example. It just keeps an instance of hal_device_info_t and returns it regardless of the index.

One extra weirdness is that the fact that the name is a const char* means that if it were something dynamic based on the index, one would need to manage the lifetime of that string separately.

I'd think that method should return by value and the returned object should use std::string for string fields, but changing that would be a much bigger change.

@hvdijk
Copy link
Collaborator
hvdijk commented Apr 25, 2025

For more context, see the hal_refsi_tutorial example. It just keeps an instance of hal_device_info_t and returns it regardless of the index.

It also sets hal_info.num_devices = 1; though, so it knows in device_get_info(uint32_t index) that index must necessarily be zero.

The assumption that the name uniquely identifies the device is kind of baked into our build system. We call clc during our build with the appropriate -d option that we assume is enough. If we make it so that that assumption is no longer valid, we would need to make bigger changes, I am not sure what that would need to look like.

@dlopr dlopr force-pushed the clc-add-device-idx-cmdline-opt branch 2 times, most recently from 57e3e55 to 3ebb4ed Compare April 25, 2025 15:54
@dlopr
Copy link
Contributor Author
dlopr commented Apr 25, 2025

For more context, see the hal_refsi_tutorial example. It just keeps an instance of hal_device_info_t and returns it regardless of the index.

It also sets hal_info.num_devices = 1; though, so it knows in device_get_info(uint32_t index) that index must necessarily be zero.

The assumption that the name uniquely identifies the device is kind of baked into our build system. We call clc during our build with the appropriate -d option that we assume is enough. If we make it so that that assumption is no longer valid, we would need to make bigger changes, I am not sure what that would need to look like.

This PR doesn't affect your build system. It cannot hurt, just help in case there's a name clash either by coincidence or by design.

@dlopr
Copy link
Contributor Author
dlopr commented Apr 25, 2025

Note that muxc already has a --device-idx option.

@dlopr
Copy link
Contributor Author
dlopr commented Apr 25, 2025

And also note that it may be more convenient to select a device by index than by name regardless of potential name clashes.

@hvdijk
Copy link
Collaborator
hvdijk commented Apr 25, 2025

Note that muxc already has a --device-idx option.

That is a strong argument in favour of your PR and I'm okay in principle with it on that basis, but note that the option there is not to deal with duplicate device names. I think we still have to consider duplicate device names an error.

@@ -219,7 +219,7 @@ class argument {
cargo::array_view<cargo::string_view> Choices;
};
union {
bool *Bool;
bool *Bool = {};
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is the reason for this change?

@dlopr
Copy link
Contributor Author
dlopr commented Apr 25, 2025 via email

@hvdijk
Copy link
Collaborator
hvdijk commented Apr 25, 2025

The compiler gives a warning if left uninitilized (as it happens with the custom parser overload of the constructor).

Ah, thanks, that makes sense. As you've seen, the idea is that Type tells which union member is active, but then we inexplicably don't put CustomHandler in that union despite that being controlled by Type == CUSTOM. That isn't consistent with the rest of the code, this seems like a good time to fix that.

@dlopr
Copy link
Contributor Author
dlopr commented Apr 25, 2025

That's a tagged-union. But in its basic form, it has problems. A plain union won't have an implicitly defined destructor if one of its members has a user-defined destructor. That's why simply adding CustomHandler to the union doesn't work.

std::variant is in fact an advanced implementation of the tagged-union idea that correctly handles that sort of thing. That's why I suggested to use it instead of the plain union.

That should be in a different PR, though.

@hvdijk
Copy link
Collaborator
hvdijk commented Apr 26, 2025

If now is not a good time to do that, then I don't know when :) Does hvdijk@cargo-argument-variant avoid that problem? If it does, I can put that up as a pull request first, or you can rebase your pull request on it and we can merge them together.

I notice that muxc's --device-idx is zero-based, but your new clc's --device-idx is one-based. Can you make sure that they work the same way?

@dlopr
Copy link
Contributor Author
dlopr commented Apr 26, 2025 via email

If a platform reports multiple devices, they will all have the same name
and --device selection will be ambiguous.

This adds a --device-idx cmd-line option to directly select by index.
@dlopr dlopr force-pushed the clc-add-device-idx-cmdline-opt branch from 3ebb4ed to 8af7a06 Compare April 28, 2025 08:35
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.

3 participants
0