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

Lacking healthy driver coexistence API design #2130

Open
krOoze opened this issue May 19, 2023 · 0 comments
Open

Lacking healthy driver coexistence API design #2130

krOoze opened this issue May 19, 2023 · 0 comments

Comments

@krOoze
Copy link
Contributor

krOoze commented May 19, 2023

#2121 makes me realize there's a lack of overal healthy design for driver coexistence (and kinda makes me apprehensive to any short-term thinkist and narrow additions trying to mitigate some symptoms).

Now, drivers might want to co-exist for various reasons (or as an user I would like them to):

  • stable vs beta drivers
  • vendor vs competing (perhaps open-source) drivers
  • native vs emulated drivers
  • workstation vs "game-ready" drivers
  • old driver version for that one picky game
  • ???

The original API is great in simplicity, assuming there's a "physical" device, and that's it. To just tack co-existence on top of this, we have to add more Physical Devices per one physical device. It is getting bit messy.

Additionally, the relationships get non-trivial. E.g. emulated driver might not want to meddle in if native driver is present, unless a power-user actively wants it.

My concern here is the design does not end up an usual messy post-factum putting-out-fires frankenstein (cough cough like the versioning system and associated API cough). It should end up neither a chore, mess, clownfest, or disaster. And it should stay timeless, so Application can rely on it from this point forward without fear.

  • Example of a chore: End user must go through bunchload of reinstalls to choose between stable and beta driver.
  • Example of a mess: App does the best choices available at the time using messy API (as it exist at the time the app is implemented), and perhaps exporting some responsibilities to the end-user that he did not ask for or perhaps even understands.
  • Example of a clownfest: There's a Dx-on-Vulkan emulator, and Vulkan-on-Dx emulator. This results into infinite Physical Devices offered, only differing by level of indirection.
  • Example of a disaster: Vulkan-on-Dx driver might be exposing more extensions (on the account of some features being mandatory in Dx), but overal the driver is poorly performing. App sees a dedicated GPU with all the extensions it prefers, and so chooses this inferior driver. (App can potentially be an old app that can't or won't be updated, and does not know any of the newer newfangled extensions.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants