Open chris2lee opened 2 years ago
15 看这个讨论,可能是由于cpu数据传输的原因
您好,大佬想请教一下,作者原文RVM 在4k视频可以达到76fps,我想在3090上达到最快速度推理,基于咱们这个库如何改进呢,这里推理包括数据加载方式、数据预处理以及模型推理得到输出值alpha、fgr,不包含后续合成
15 看这个讨论,可能是由于cpu数据传输的原因
您好,大佬想请教一下,作者原文RVM 在4k视频可以达到76fps,我想在3090上达到最快速度推理,基于咱们这个库如何改进呢,这里推理包括数据加载方式、数据预处理以及模型推理得到输出值alpha、fgr,不包含后续合成
在服务端的话,感觉不是很有必要用c++,可以看我fork的分支,里面有个python的推理:
需要用到onnxruntime的gpu版本,并且做好iobinding,onnxruntime-gpu python服务端的配置可以看我写的文章:
如果你想用c++版本,我具体也没试过做这些优化,业余精力有限,主要还是在研究算法本身。但是你可以从2点入手:
大佬,目的是使用C++推理,1.使用TensorRT会不会增加推理速度呢,2.我看你回复其他人问题,有提到rxi是在cpu操作的, 3.视频加载使用什么能提速?opencv GPU版本还是ffmpeg gpu?,预处理是否必须在cpu下才能操作。
大佬,目的是使用C++推理,1.使用TensorRT会不会增加推理速度呢,2.我看你回复其他人问题,有提到rxi是在cpu操作的, 3.视频加载使用什么能提速?opencv GPU版本还是ffmpeg gpu?,预处理是否必须在cpu下才能操作。 我认为应该进行GPU编解码才能做到真正的实时
大佬,目的是使用C++推理,1.使用TensorRT会不会增加推理速度呢,2.我看你回复其他人问题,有提到rxi是在cpu操作的, 3.视频加载使用什么能提速?opencv GPU版本还是ffmpeg gpu?,预处理是否必须在cpu下才能操作。 我认为应该进行GPU编解码才能做到真正的实时
你能提供一些思路吗,该如何操作,才能实现真正的实时,期待大佬的回复
大佬,目的是使用C++推理,1.使用TensorRT会不会增加推理速度呢,2.我看你回复其他人问题,有提到rxi是在cpu操作的, 3.视频加载使用什么能提速?opencv GPU版本还是ffmpeg gpu?,预处理是否必须在cpu下才能操作。 我认为应该进行GPU编解码才能做到真正的实时
你能提供一些思路吗,该如何操作,才能实现真正的实时,期待大佬的回复
预处理肯定是要在GPU上做,这个模型的逻辑是循环,要提高GPU利用率是最优解法 并不是模型转换
大佬,目的是使用C++推理,1.使用TensorRT会不会增加推理速度呢,2.我看你回复其他人问题,有提到rxi是在cpu操作的, 3.视频加载使用什么能提速?opencv GPU版本还是ffmpeg gpu?,预处理是否必须在cpu下才能操作。 我认为应该进行GPU编解码才能做到真正的实时
你能提供一些思路吗,该如何操作,才能实现真正的实时,期待大佬的回复
预处理肯定是要在GPU上做,这个模型的逻辑是循环,要提高GPU利用率是最优解法 并不是模型转换
很抱歉~ 最近工作太忙了,回复稍晚。这位大佬的思路是对的,onnxruntime-gpu可以考虑使用io_binding把张量放在gpu进行处理,避免context的io,我之前写了一份python版本的代码,你可以参考一下,但是c++的没时间搞了:
大佬,目的是使用C++推理,1.使用TensorRT会不会增加推理速度呢,2.我看你回复其他人问题,有提到rxi是在cpu操作的, 3.视频加载使用什么能提速?opencv GPU版本还是ffmpeg gpu?,预处理是否必须在cpu下才能操作。 我认为应该进行GPU编解码才能做到真正的实时
你能提供一些思路吗,该如何操作,才能实现真正的实时,期待大佬的回复
预处理肯定是要在GPU上做,这个模型的逻辑是循环,要提高GPU利用率是最优解法 并不是模型转换
很抱歉~ 最近工作太忙了,回复稍晚。这位大佬的思路是对的,onnxruntime-gpu可以考虑使用io_binding把张量放在gpu进行处理,避免context的io,我之前写了一份python版本的代码,你可以参考一下,但是c++的没时间搞了:
恩恩,我参照研究一下,谢谢大佬
大佬,目的是使用C++推理,1.使用TensorRT会不会增加推理速度呢,2.我看你回复其他人问题,有提到rxi是在cpu操作的, 3.视频加载使用什么能提速?opencv GPU版本还是ffmpeg gpu?,预处理是否必须在cpu下才能操作。 我认为应该进行GPU编解码才能做到真正的实时
你能提供一些思路吗,该如何操作,才能实现真正的实时,期待大佬的回复
预处理肯定是要在GPU上做,这个模型的逻辑是循环,要提高GPU利用率是最优解法 并不是模型转换
很抱歉~ 最近工作太忙了,回复稍晚。这位大佬的思路是对的,onnxruntime-gpu可以考虑使用io_binding把张量放在gpu进行处理,避免context的io,我之前写了一份python版本的代码,你可以参考一下,但是c++的没时间搞了:
大佬,我按照转换代码转了,静态转onnx测试没有问题,动态的转onnx,采用这个推理( https://github.com/DefTruth/RobustVideoMatting/blob/onnx/inference_onnx.py
),cpu float32 没有问题,切换成 gpu 无论 fl16 还是fl32 都会报错 ,转换时候 和推理的 float都是对应的,,采用报错
/media/lg/1484975B84973E64/anaconda3/envs/RVM/bin/python "/media/lg/1484975B84973E64/project/Matte/RobustVideoMatting-onnx _infer/RobustVideoMatting-onnx/inference_onnx.py" --checkpoint ./rvm_model1.onnx --device cuda --dtype fp32 --input-source /media/lg/1484975B84973E64/project/Matte/video/Depth.mov --downsample-ratio 0.125 --output-type video --output-composition composition.mp4 --output-alpha alpha.mp4 --output-video-mbps 4 --seq-chunk 1
/media/lg/1484975B84973E64/anaconda3/envs/RVM/lib/python3.9/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py:350: UserWarning: Deprecation warning. This ORT build has ['CUDAExecutionProvider', 'CPUExecutionProvider'] enabled. The next release (ORT 1.10) will require explicitly setting the providers parameter (as opposed to the current behavior of providers getting set/registered by default based on the build flags) when instantiating InferenceSession.For example, onnxruntime.InferenceSession(..., providers=["CUDAExecutionProvider"], ...)
warnings.warn("Deprecation warning. This ORT build has {} enabled. ".format(available_providers) +
Traceback (most recent call last):
File "/media/lg/1484975B84973E64/project/Matte/RobustVideoMatting-onnx _infer/RobustVideoMatting-onnx/inference_onnx.py", line 230, in
同问,想知道纯CPU推理的话,FPS能有多少?可以做实时抠图吗
15 看这个讨论,可能是由于cpu数据传输的原因