KhronosGroup / KhronosGroup/Vulkan-Docs
Lacking healthy driver coexistence API design
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 3.3k
- Forks
- 549
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 2
Description
#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.)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named. Start by reading issue #2121 and the existing Physical Device and driver API described in the issue; done would be a settled coexistence design covering the listed driver relationships and avoiding ambiguous device selection.
Written by the indexing model from the issue text.
Assessment
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100