You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#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.)
The text was updated successfully, but these errors were encountered:
#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):
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.
The text was updated successfully, but these errors were encountered: