Exposing/implementing the HAL driver registry via the C API. #3937
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
benvanik
force-pushed
the
benvanik-driver-registry
branch
4 times, most recently
from
9487e50
to
2106f4f
Compare
benvanik
force-pushed
the
benvanik-hack-and-slash
branch
2 times, most recently
from
855884c
to
7b8e9f7
Compare
benvanik
force-pushed
the
benvanik-driver-registry
branch
from
2106f4f
to
b1bfbc7
Compare
|
@KoolJBlack scott mentioned you may be looking at HAL+android stuff soon - this is probably going to be very useful for you :) Happy to gvc and walk through this if you have questions (about this or the HAL API in general). |
This was referenced Nov 22, 2020
Enables drivers to be provided externally by callers and discovered/loaded dynamically. Zero cost when applications explicitly create their own drivers directly (LTO stripped). Example use cases are compiling LLVM JIT in its own dylib, remote/sandboxed drivers enumerated based on availability, driver multiversioning, and out-of-tree drivers from downstream projects.
benvanik
force-pushed
the
benvanik-driver-registry
branch
from
b1bfbc7
to
0e7dfa0
Compare
ScottTodd
requested changes
Dec 1, 2020
ScottTodd
approved these changes
Dec 1, 2020
KoolJBlack
approved these changes
Dec 1, 2020
This was referenced Dec 2, 2020
Closed
Closed
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Enables drivers to be provided externally by callers and discovered/loaded dynamically. Zero cost when applications explicitly create their own drivers directly (LTO stripped).
Example use cases are compiling LLVM JIT in its own dylib, remote/sandboxed drivers enumerated based on availability, driver multiversioning, and out-of-tree drivers from downstream projects. Hooray for having a story that will prevent us from ever needing to link CUDA into our binaries ;)
This also let me clean up some of the duplication that had crept in with multiple places all doing driver querying/filtering/etc (and sometimes in slightly different ways). It's intentional that we don't have a non-test utility for that, as non-test targets should not be trying to create all drivers and ignoring any of the metadata the driver registry is now able to provide.