Skip to content

  • 体验新版
    • 正在加载...
  • 登录
  • PaddlePaddle
  • Paddle
  • Issue
  • #13487

P
Paddle
  • 项目概览

PaddlePaddle / Paddle
大约 2 年 前同步成功

通知 2325
Star 20933
Fork 5424
  • 代码
    • 文件
    • 提交
    • 分支
    • Tags
    • 贡献者
    • 分支图
    • Diff
  • Issue 1423
    • 列表
    • 看板
    • 标记
    • 里程碑
  • 合并请求 543
  • Wiki 0
    • Wiki
  • 分析
    • 仓库
    • DevOps
  • 项目成员
  • Pages
P
Paddle
  • 项目概览
    • 项目概览
    • 详情
    • 发布
  • 仓库
    • 仓库
    • 文件
    • 提交
    • 分支
    • 标签
    • 贡献者
    • 分支图
    • 比较
  • Issue 1,423
    • Issue 1,423
    • 列表
    • 看板
    • 标记
    • 里程碑
  • 合并请求 543
    • 合并请求 543
  • Pages
  • 分析
    • 分析
    • 仓库分析
    • DevOps
  • Wiki 0
    • Wiki
  • 成员
    • 成员
  • 收起侧边栏
  • 动态
  • 分支图
  • 创建新Issue
  • 提交
  • Issue看板
已关闭
开放中
Opened 9月 19, 2018 by saxon_zh@saxon_zhGuest

Visual Prediction test fails with MKL-DNN due to incorrect Pooling dimensions

Created by: Sand3r-

I've managed to correct the code of AnalysisPredictor (analysis_predictor.cc) as to actually have it run an MKL-DNN engine (previously the MKL-DNN layers weren't called at all) in the analyzer_vis_tester.cc. The corrected code can be found at https://github.com/Sand3r-/Paddle at branch mgallus/fix_mkldnn_at_vis_test.

However, after running the test with MKL-DNN enabled it crashed.

To assess whether that was caused by the fuses, I have disabled all the relevant fuses. The program remained crashing anyway.

I have then debugged the program deep enough to find out that the crash was caused by MKLDNN's check for pooling output size consistency (the relevant line can be found here). It says that the determined output size of (1, 16, 24, 385) is incorrect, and that the correct output shape should be of (1, 16, 24, 384), given that: the input to the pooling has shape of (1, 16, 48, 769), kernel size is (2, 2), padding of (0,0), and strides of (2, 2).

Which according to formula found at http://cs231n.github.io/convolutional-networks/?utm_source=top.caibaojian.com/48879 Section Pooling Layer provides the following:

width = (old_width - filter_size) / stride + 1

width = ((769 - 2)/2 + 1) = 384, hence the MKL-DNN check is correct.

That would imply, that model downloaded for the purposes of test_analyzer_ocr is flawed, as it contains incorrectly computed output pooling size(s?).

After an investigation into how does the reference CPU implementation of Paddle computes the output shape, I have noticed that it must've had used the ceil_mode attribute, which uses the formula (input_size - filter_size + 2 * padding + stride - 1) / stride + 1 here for output shape computation. That indeed results with computation of output width to be 385 and not 384. Now the question is, is that ceil_mode formula necessary, and if so, why? Cannot the model be trained without it? I haven't found any usages in the code that would alter the behaviour of pooling when this parameter is enabled. Moreover, is the formula even correct if it outputs different results?

指派人
分配到
无
里程碑
无
分配里程碑
工时统计
无
截止日期
无
标识: paddlepaddle/Paddle#13487
渝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