Add platform specific repository for xclbins #7712
Merged
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
stsoe
requested review from
vboggara-xilinx,
rozumx and
uday610
as code owners
|
retest this please. (We tried different backend for pcie/hw tests. looks like there was an issue so retest should work) |
|
Build Passed! |
|
Build Passed! |
maxzhen
pushed a commit
to maxzhen/XRT
that referenced
this pull request
Oct 6, 2023
Ensure that only one legacy command monitor thread (kds_device) is created for platforms that do not implement create_hw_queue. The legacy command monitor handles command completion for the enqueued command execution, mostly OpenCL or native XRT with callback, latter rarely used. The APIs used by the monitor are legacy execbuf and execwait() APIs that operate at the device level. Testing of Xilinx#7712 found that when a platform supports hardware contexts, but not hardware queue, it ends up creating multiple kds_devices (command monitor threads) one for each unique hwctx handle. The command monitor does not support a single thread creating multiple instances and also it is wasteful to use multiple monitor threads for same device when execbuf and execwait calls go through the xrt_core::device object anyway. This PR thus adds logic to ensure that only one kds_device is created for each xrt_core::device. For platforms that support hardware queue, new queue specific APIs are used to manage command execution and as such require a command monitor per hardware queue, so no changes are made here. Only legacy non hardware queue flow is changed. Signed-off-by: Soren Soe <[email protected]> Signed-off-by: Soren Soe <[email protected]>
stsoe
requested review from
AShivangi
and removed request for
uday610,
rozumx and
vboggara-xilinx
|
Build failed :( |
1 similar comment
|
Build failed :( |
For some use flows xclbins are not provided by the application but instead dynamically loaded from a repository created at sw stack install time. This PR adds support for repository of xclbins though the xrt::xclbin_repository first class object. Support repository of xclbins, where repository path(s) are one of - explicit directory path - platform specific directory where xclbins are installed - configuration option via xrt.ini The repository can be iterated for all xclbins available in the repo or it can open a specific xclbin. The built-in repository path is platform specific. The PR also changes the behavior of xrt::xclbin constructed from std::string. The constructor now checks for specified xclbin either as (1) absolute path, (2) relative path to current directory, or (3) relative path under built-in repository. What has been tested and how, request additional testing if necessary Standard OpenCL tests on Alveo. Hand picked windows tests on MCDM. Debugging. See tests/xrt/56_xclbin/main.cpp for sample use. Signed-off-by: Soren Soe <[email protected]>
- xrtdeps.sh installs gcc-toolset-9-toolchain - build.sh switches to gcc9 when building on CentOS8
|
Build Passed! |
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.
Problem solved by the commit
For some use flows xclbins are not provided by the application but instead dynamically loaded from a repository created at sw stack install time. This PR adds support for repository of xclbins though the xrt::xclbin_repository first class object.
How problem was solved, alternative solutions (if any) and why they were rejected
Support repository of xclbins, where repository path(s) are one of
The repository can be iterated for all xclbins is available in the repo or it can be asked to load a specific xclbin.
The built-in repository path is platform specific.
The PR also changes the behavior of xrt::xclbin constructed from std::string. The constructor now checks for specified xclbin either as (1) absolute path, (2) relative path to current directory, (3) relative path under user configured repository, or (4) relative path under built-in repository.
What has been tested and how, request additional testing if necessary
See tests/xrt/56_xclbin/main.cpp for sample use.