Skip to content

  • 体验新版
    • 正在加载...
  • 登录
  • PaddlePaddle
  • Paddle-Lite
  • 合并请求
  • !4003

P
Paddle-Lite
  • 项目概览

PaddlePaddle / Paddle-Lite

通知 337
Star 4
Fork 1
  • 代码
    • 文件
    • 提交
    • 分支
    • Tags
    • 贡献者
    • 分支图
    • Diff
  • Issue 271
    • 列表
    • 看板
    • 标记
    • 里程碑
  • 合并请求 78
  • Wiki 0
    • Wiki
  • 分析
    • 仓库
    • DevOps
  • 项目成员
  • Pages
P
Paddle-Lite
  • 项目概览
    • 项目概览
    • 详情
    • 发布
  • 仓库
    • 仓库
    • 文件
    • 提交
    • 分支
    • 标签
    • 贡献者
    • 分支图
    • 比较
  • Issue 271
    • Issue 271
    • 列表
    • 看板
    • 标记
    • 里程碑
  • 合并请求 78
    • 合并请求 78
  • Pages
  • 分析
    • 分析
    • 仓库分析
    • DevOps
  • Wiki 0
    • Wiki
  • 成员
    • 成员
  • 收起侧边栏
  • 动态
  • 分支图
  • 创建新Issue
  • 提交
  • Issue看板

[BugFix][OPENCL] Fix initalization sequence of opencl backend valid API. test=develop !4003

  • Report abuse
!4003 已合并 7月 28, 2020 由 saxon_zh@saxon_zh 创建
#<User:0x000055935a6c7e18>
  • 概览 4
  • 提交 9
  • 变更 6

Created by: ysh329

状态:等待review


主要内容

修正OpenCL的预判API导致的初始化顺序问题。先前的预判API会让CLRuntime调用CLWrapper去检查库是否找到,符号加载是否正常。但因为该顺序问题导致后续segfault bug(如加载cpu+gpu库,但加载cpu模型,在不支持gpu的手机上面会挂的问题)。

因先初始化CLRuntime会初始化相关平台设备等等,二者存在交叉依赖的问题。现改为,预判API先不调用CLRuntime,而是先通过CLWrapper获取是否找到lib和符号方法,在做CLRuntime层面的检查(fp16的支持等等)。

再就是RuntimeProgram创建的时候,有针对opencl设置每个kernel的kernelContext,这部分之前咱们是每个kernel共用一个kernelContext,因为cl::Context是唯一的。这里也需要考虑到当跑CPU模型时,遇到这里需要预判是否硬件支持opencl。否则出现segfault(gdb定位到这里),因而这里加上了预判再去setContext。

指派人
分配到
审核者
Request review from
无
里程碑
无
分配里程碑
工时统计
标识: paddlepaddle/Paddle-Lite!4003
Source branch: github/fork/ysh329/fix-gpu-load-cpu-model
渝ICP备2023009037号

京公网安备11010502055752号

网络110报警服务 Powered by GitLab CE v13.7
开源知识
Git 入门 Pro Git 电子书 在线学 Git
Markdown 基础入门 IT 技术知识开源图谱
帮助
使用手册 反馈建议 博客
《GitCode 隐私声明》 《GitCode 服务条款》 关于GitCode
Powered by GitLab CE v13.7