Skip to content
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

[TAG review] Should there be a higher granularity for selecting devices? #2945

Closed
kdashg opened this issue May 25, 2022 · 2 comments
Closed
Milestone

Comments

@kdashg
Copy link
Contributor

kdashg commented May 25, 2022

From w3ctag/design-reviews#626 (comment)

Should there be a higher granularity for selecting devices? For example, for cases where one wants to select a high-VRAM device (e.g. for machine learning workloads) or the non-dominant (e.g. secondary device which hopefully will not jank the current compositor) device. Allowing a single application to be the dominant resource user is not new, but it is definitely something that want to be careful about.

@kdashg kdashg changed the title [from TAG] Should there be a higher granularity for selecting devices? [TAG review] Should there be a higher granularity for selecting devices? May 25, 2022
@kainino0x kainino0x added this to the V1.0 milestone May 25, 2022
@kdashg kdashg modified the milestones: V1.0, post-V1 Jun 15, 2022
@litherum
Copy link
Contributor

Resolved today: this isn't necessary because almost all machines have either 1 or 2 devices which are already addressable by just the high-performance/low-power existing toggle.

@kainino0x
Copy link
Contributor

We moved it to post-V1 instead of closing it because there's a possibility that devs will come to us with this requirement in the future. However, I think we should just close it, because there's not much discussion on this issue and I'm sure it would end up getting filed as a new one anyway. (Or we can reopen this when the time comes.)

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

No branches or pull requests

3 participants