DefTruth

> > 非常感谢，可以了。哎。 头文件添加： > > #include “onnxruntime_c_api.h” > > #ifdef USE_CUDA #include "cuda_provider_factory.h" #endif > > 然后： initialize_handler()中，添加： #ifdef USE_CUDA //OrtCUDAProviderOptions provider_options; // C接口 //session_options.AppendExecutionProvider_CUDA(provider_options); //OrtCUDAProviderOptions 选项； //options.device_id =...

https://github.com/microsoft/onnxruntime/releases/tag/v1.8.1 可以看下onnxruntime 1.8.1 官方release，1.8.1后支持CUDA 10.2 和 cudnn 11

> 所以，不知道是我们代码里面，配置的问题，还是库的问题 emmm，不太清楚哎，毕竟我这里的代码和onnxruntime没法比。以下是我的一些建议： 有可能是CUDAExecuteProvider对应的设备号不一定是0，我这里写死了是0. 在 [lite/ort/core/ort_handler.cpp](https://github.com/DefTruth/lite.ai.toolkit/blob/main/lite/ort/core/ort_handler.cpp) 中： ```C++ // GPU compatiable. // OrtCUDAProviderOptions provider_options; // session_options.AppendExecutionProvider_CUDA(provider_options); #ifdef USE_CUDA OrtSessionOptionsAppendExecutionProvider_CUDA(session_options, 0); // C API stable. #endif // 1. session ort_session =...

> 您这边自己编译的onnxruntime，速度咋样？能达到30ms吗，yolov5? 1. 我暂时在mac玩，没有用到GPU，yolov5s的速度还可以，没有具体去测。等之后MNN/TNN/NCNN各个版本的整合完善后，会添加在不同平台和性能测试。 2. 关于 lite_yolov5 的测试方式，因为用的是 yolov5s.onnx ，本身是小模型，在CPU是可以跑挺快的，如果切换成GPU，不能只跑我写的demo，我写的只是单次推理。GPU的首次推理通常比较慢，之后会变快。你需要参考test_lite_yolov5.cpp的例子，在 new 完 lite::cv::detection::YoloV5 后，跑个循环测一下，忽略首次推理。

> 嗯嗯。就是很奇怪的是，我自己编译的gpu版本的onnxruntime，推理速度就是cpu的速度 下载的git上onnxruntime的源码，然后使用下面的命名编译，推理的时候，还是cpu速度： .\build.bat --build_shared_lib --config Release --use_cuda --cuda_version=11.0 --cudnn_home "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0" --cuda_home "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0" --use_tensorrt --tensorrt_home "D:\vison_software\NVIDIA\cuda11.0\TensorRT-8.2.0.6" 这就不太清楚了，可以尝试下把GPU设置的status打log，看看是否正常设置了GPU ```C++ int enable_cuda(OrtSessionOptions* session_options) {...

linux下的话需要重新编译onnxruntime或者去官方网站下载，请参考README中的说明。也可以查看一下相关的issue: * https://github.com/DefTruth/lite.ai.toolkit/issues/97 * https://github.com/DefTruth/lite.ai.toolkit/issues/104 * https://github.com/DefTruth/lite.ai.toolkit/issues/81 * https://github.com/DefTruth/lite.ai.toolkit/issues/27

ENV确实应该是全局的。如果你是在一个类中使用ENV，那么ENV需要是类内全局的，它的生命周期和这个类一致。也就说，ENV必须是这个类的一个属性，而不应该是类的某个方法中临时变量。因为Session绑定了ENV，如果ENV是方法的临时变量，则在方法退出时会被销毁，此时Session就会指向一个不存在的资源。按照这个逻辑，如果你想实现一个类，在这个类中使用多线程，每个线程有单独的Session，可尝试的选择就是，让ENV成为这个类的属性，在每个子线程的Session共享这个ENV。如果ENV是属于线程，而Session的生命周期却不限于子线程，那么就有可能引发堆栈溢出，而ENV是类全局(类属性)时，则可避免这个问题，此时无论Session何时调用，都是指向有效的ENV。简单来说就是，如果你能确保ENV的生命周期大于等于你所使用的Session的生命周期，应该是比较合理的。 ```c++ #ifdef ORT_API_MANUAL_INIT const OrtApi* Global::api_{}; inline void InitApi() { Global::api_ = OrtGetApiBase()->GetApi(ORT_API_VERSION); } #else const OrtApi* Global::api_ = OrtGetApiBase()->GetApi(ORT_API_VERSION); #endif // This returns a reference to the OrtApi...

> 感谢支持，通过阅读接口代码，找到了正确的使用方式 > > Ort::OrtRelease(m_session.release()); > Ort::OrtRelease(sessionOptions.release()); > Ort::OrtRelease(m_env.release()); 可以从ort_env.cc以及ort_env.h中看到OrtEnv实际上是 单例模式 + 引用计数 的模式： ```c++ // 在 ort_env.h中的定义 struct OrtEnv { public: struct LoggingManagerConstructionInfo { LoggingManagerConstructionInfo(OrtLoggingFunction logging_function1, void* logger_param1, OrtLoggingLevel...

哈哈，我也不是大佬，也就是业余玩一下~ 关于内存的问题的，我也没研究太深，你可以看下 [onnxruntime内存增长问题探讨](https://zhuanlan.zhihu.com/p/371426504) 资料。欢迎分享新知识，共同学习~🙃🙃🙃

> 请问一下 在include lite.h这一步出了问题 > 然后说是无法解析外部符号的报错 是一些ort的函数 > error LNK2001: 无法解析的外部符号 "public: void __cdecl ortcv::YoloX::detect这种情况怎么办啊 每个类已经添加LITE_EXPORTS来兼容不同的操作系统。我没有在windows上玩过，你可能需要检测一下动态库链接有没有正确。方便把报错的log放上来吗？