-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Adding VIM3 (Verisilicon TPU) to Frigate #5892
Conversation
…IB only when needed on the platform.
✅ Deploy Preview for frigate-docs canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, few comments left. Also, you will need to update the documentation in this PR to reflect the detector, what hardware it runs on, and example config to get it up and running.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way that these can be downloaded in the docker file, as opposed to included in the repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was an open question! .. is there a method to detect hardware being run on?
Hardware : Khadas VIM3
khadas@Khadas:~/git/frigate$
The output can determine if the files are needed or not
Additionally... where to host?
the VIM3_Frigate_modules.tar.gz are hosted on Gdrive
https://drive.google.com/file/d/1um67CKxJOybbzz6xE75RlyyDR-m2YsA3/view?usp=sharing
need to be unpacked in to /lib/vim3
NOTE : I did not want to touch the Dockerfile as my version has got the OV components commented out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, google drive is interesting. Curious what @blakeblackshear thinks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont like it! .. but looking for solutions :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does that Google drive link originate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be best to build them in a docker layer. If that takes way too long, precompiled binaries can be downloaded from a separate github repository, but it would to need have a transparent build process and versioned releases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be best to build them in a docker layer. If that takes way too long, precompiled binaries can be downloaded from a separate github repository, but it would to need have a transparent build process and versioned releases.
Ideally.. yes - but I would also like an end to world hunger and peace on earth :D The Verisilicon code only compiles on AMD64 with a cross compiler; which is weird; but its not mine so I have no place to critique. The build takes about 20 minutes to complete if your tongue is at the right angle. (and that is on an i7
I will put the blobs in a seperate respitory - that leaves open the question, how can I detect if its a VIM3 board. The host has /proc/cpuinfo which shows VIM3 SBC in the Hardware field.. how can this be queried in the Docker container? (is the hosts /proc/ inherited within the Docker create process?
Richard
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The image is built on a GitHub server (amd64) not on the end users device. This means there are a few options:
- vim3 would either always be included in the default docker builds 2. Similar to tensorrt there would be a specific image for vim3 and that would be its own docker build process on top of the default image
- There will be a separate dockerfile for this board altogether.
I believe there may be some guidance around 3 as the preferred way to go, seems we are going to be getting more and more community submissions for different detector / board types. Hopefully there will be more clarification here after 0.12 releases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The image is built on a GitHub server (amd64) not on the end users device. This means there are a few options:
1. vim3 would either always be included in the default docker builds 2. Similar to tensorrt there would be a specific image for vim3 and that would be its own docker build process on top of the default image 2. There will be a separate dockerfile for this board altogether.
I believe there may be some guidance around 3 as the preferred way to go, seems we are going to be getting more and more community submissions for different detector / board types. Hopefully there will be more clarification here after 0.12 releases.
I am totally lost on using Git for Building stuff and all the shenanigans around that! Never done that before. I dont mind including the VIM3 with the default docker, but it wont scale when more boards are added - perhaps have a script to download new libraries/objects to a docker volume for persistence.
maybe a script can be executed at the start of Frigate (run /bin/check_platform_dependencies.sh) to run only once which checks the platform and which detectors are configured - and then downloads/installs them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done...
made a new repo to download binaries..
added script to install files
Added documentation
to the ldconfig path
@@ -75,6 +75,18 @@ if [[ "${TARGETARCH}" == "arm64" ]]; then | |||
libva-drm2 mesa-va-drivers | |||
fi | |||
|
|||
# Check if the platform is a VIM3 and download TF delegate drivers for NPU |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would only work if the build was actually done on a VIM3 device, it would not include VIM3 support in the official builds.
I would suggest for now leaving this as is, the 0.12 build is being finished up and then new PRs can be merged so at that point we will have a better idea for the strategy of supporting boards like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks...
I can change the line to
if [[ "${TARGETARCH}" == "arm64" ]]
instead?
There is no love for the platform.. it has a working NPU and there is no desire to get the hardware video decoder working -abandoned- |
There's no reason to close this. As has been said on other issues, we're not looking to personally support all SBC detectors so working on an idea for community supported detectors but that will take some time. This was of course pinned and meant to stay open. |
With all due respect, The board has a working NPU and there was no engagement to get FFMPEG to work with hardware video decode. I closed it as I didnt see the point of adding a SBC that was crap and not up to the job. |
I think we were assuming you meant there was a lack of engagement from us. It's clear now that's not what you meant. |
:) I am preparing a new pull request for the Khadas VIM4 board running the ARMNN in the GPU. So far its running nicely... but again, its the packages specific for the SBC that slow things down. (It may work with all MALI/OpenCL based boards though!) Richard |
Khadas has announced a while ago (https://www.khadas.com/post/june-2023-update) that they are releasing new 5.15 kernel which would include support for h264 hw decode. Just as an extra info here. |
And those images are now available for testing: https://forum.khadas.com/t/vim3-3l-ubuntu-22-04-linux-5-15-testing-images-are-available-now/20600 |
Verisolicon TPU on the Amlogic A311D SBC (Khadas VIM3)
config.yml
Bootup Log