请选择 进入手机版 | 继续访问电脑版
 找回密码
 立即注册
查看: 556|回复: 12

核显调用OpenCL导致严重恶性画面bug (未完待续)

  • TA的每日心情
    慵懒
    昨天 21:57
  • 签到天数: 270 天

    [LV.8]以坛为家I

    10

    主题

    43

    回帖

    0

    VC币

    荣誉会员

    Rank: 14Rank: 14Rank: 14Rank: 14

    积分
    103175
    op200 发表于 2024-11-28 09:03:01 | 显示全部楼层 |阅读模式
    本帖最后由 op200 于 2024-11-28 20:10 编辑

    初章:初见端倪


    今天在压视频的时候,发现一个离奇的现象



    如图所示,边缘已经崩坏到无法形容

    这张图是我用压制鸡压的,压制鸡内是 ffmpeg 7.0.2-full_build,其内置的 libx265 版本为 3.6+36-2cdd69a6d

    而我使用主力鸡的 ffmpeg 7.1-full_build、x265 4.0+6-a069836f3

    主力鸡没有出现这种情况,如下图



    这是怎么一回事呢?

    经过比对 x265 的参数,如下图



    我发现仅有这两个参数有区别

    1. :: Intel Core i5 12500 6c12t
    2. frame-threads=3
    3. numa-pools=12

    4. :: Intel QXJE (12900K ES) 16c24t
    5. frame-threads=4
    6. numa-pools=24
    复制代码

    因为线程类参数会随着CPU线程数改变,所以我将压制鸡的参数调为 frame-threads=3 numa-pools=12,画面bug消失了,且即使 frame-threads=4 numa-pools=12 依旧不存在画面bug

    所以到这里就告一段落了吗?仅仅是因为 numa-pools 导致的吗?事情似乎并没有这么简单

    我将压制鸡的 ffmpeg 换成 7.1,也就是说把 x265 换成 4.0+6,继续进行测试

    似乎是因为 x265 的根据线程自动调参的算法没变,参数依旧是 frame-threads=4 numa-pools=24,但神奇的是画面bug荡然无存

    我又想到这个根据线程自动调参的算法是不是 3.6 版本修改,发现有bug后在新版本修正,于是我又去测试了下更老的版本

    ffmpeg 6.1 x265 3.5+111 frame-threads=4 numa-pools=24

    看来根据线程自动调参的算法一直是这样,再看画面,没有任何问题



    幕间一:大事不妙

    隔了半天,我看了下4.0压出来的整个成品,某些画面没有了这个bug,但大部分画面依旧存在这个bug,感觉这又跟源有关系,因为之前压的番没看到这个bug,只有这个番存在这个问题,而且非常明显

    目前仅知道调整 numa-pools 能解决这个问题,后面测试出其他结论我会接着修改文章



    第二章:最好笑的一集

    经过我再再再次繁杂但不严谨的测试,我总算是排除了编码器的bug

    这次,我将bug锁定在了一个vapoursynth的滤镜上——knlm.KNLMeansCL

    为什么我之前测试了一两个小时都没有怀疑过滤镜呢?
    那是因为我的vpy脚本是在主力鸡上编写的,而主力鸡上运行的预览画面完全没问题;
    再加上压制鸡使用高 numa-pools 时这个bug会加重(也可能是x265把瑕疵糊掉了导致我误判,现在再测x265没意义了,我就不测这个了);
    更离奇的是,我前天刚刚用这个滤镜压制了另一部番,那部番完全没有出现这个问题(没出问题的原因是我用了强度很高的边缘蒙版,把所有纹理全部盖住了),导致我知道最后才怀疑到滤镜头上;

    当我总结了这些规律之后,我直接把bug锁定在显卡驱动上,我满怀希望地装上新驱动,重新启动,结果依旧,希望破灭;
    但这并不能证明不是显卡的问题,因为压制鸡的使用的是仅有的核显 UHD 770 调用 OpenCL,而主力鸡使用的是 Arc 750,所以现在有两个可能性:
    • UHD 770 干的
    • ES 干的

    而有一个办法可以一石二鸟,直接测试出这两点的结论:
    主力鸡的 12500 的核显就是 UHD 770,只要更改形参 device_id,即可用主力鸡的核显测试

    结果令人大跌眼镜——还真是 UHD 770 干的



    下集预告:
    楼主是否能战胜核显bug?
    拯救世界的,是弱不禁风的770核显,还是那张尘封已久的四朝矿神 5600xt?又或是那张从来没掉过驱动的 GTX770?
    红绿蓝三家的终极决战就此拉开序幕…


    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有账号?立即注册

    x
    回复

    使用道具 举报

  • TA的每日心情
    慵懒
    2024-11-28 16:42
  • 签到天数: 14 天

    [LV.3]偶尔看看II

    0

    主题

    21

    回帖

    0

    VC币

    中级会员

    Rank: 3Rank: 3

    积分
    2051
    nyanmisaka 发表于 2024-11-28 16:29:55 | 显示全部楼层
    没啥稀奇的,知道 3.6+36 什么意思么?

    在 x265 发布了 3.6 版本的基础上,又额外提交了 36 个新 commit,但还没有提升版本号到 4.0,所以你在用的不是正式版,而是某个开发分支,随时都会坏,也随时都能修。

    另外从签名的得知你的 ffmpeg 中的 x265 包含了非官方的补丁,最后一次提交的 hash 在官方仓库里找不到。
    https://bitbucket.org/multicoreware/x265_git/commits/2cdd69a6d
    https://bitbucket.org/multicoreware/x265_git/commits/a069836f3
    回复

    使用道具 举报

  • TA的每日心情
    慵懒
    昨天 21:57
  • 签到天数: 270 天

    [LV.8]以坛为家I

    10

    主题

    43

    回帖

    0

    VC币

    荣誉会员

    Rank: 14Rank: 14Rank: 14Rank: 14

    积分
    103175
    op200  楼主| 发表于 2024-11-28 18:33:34 | 显示全部楼层
    nyanmisaka 发表于 2024-11-28 16:29
    没啥稀奇的,知道 3.6+36 什么意思么?

    在 x265 发布了 3.6 版本的基础上,又额外提交了 36 个新 commit, ...

    我刚才看了下整个成品,发现大概率所有版本都存在这个bug,只是新版中某些画面中没有了这个bug,看来只能调 numa-pools 了

    编码器这玩意也没啥大影响的 commit 基本上用新版不会有问题

    回复

    使用道具 举报

  • TA的每日心情
    慵懒
    2024-11-19 16:34
  • 签到天数: 291 天

    [LV.8]以坛为家I

    1

    主题

    17

    回帖

    0

    VC币

    高级会员

    Rank: 4

    积分
    22573
    fzz 发表于 2024-11-28 20:19:53 | 显示全部楼层
    编码没那么容易出恶性bug,你看果然是输入就炸了
    回复

    使用道具 举报

  • TA的每日心情
    慵懒
    昨天 21:57
  • 签到天数: 270 天

    [LV.8]以坛为家I

    10

    主题

    43

    回帖

    0

    VC币

    荣誉会员

    Rank: 14Rank: 14Rank: 14Rank: 14

    积分
    103175
    op200  楼主| 发表于 2024-11-28 20:31:31 | 显示全部楼层
    fzz 发表于 2024-11-28 20:19
    编码没那么容易出恶性bug,你看果然是输入就炸了

    确实,对vs太放心导致的(
    回复

    使用道具 举报

  • TA的每日心情
    慵懒
    2024-11-28 16:42
  • 签到天数: 14 天

    [LV.3]偶尔看看II

    0

    主题

    21

    回帖

    0

    VC币

    中级会员

    Rank: 3Rank: 3

    积分
    2051
    nyanmisaka 发表于 2024-11-28 21:48:00 | 显示全部楼层
    本帖最后由 nyanmisaka 于 2024-11-28 22:03 编辑

    喷了。。结果是OpenCL滤镜就错了。

    这玩意不如CUDA的一点就是,它在各个厂商的驱动上跑结果能不一样,必须自己调试。

    。。。

    https://github.com/search?q=repo ... -math&type=code

    看来作者开了不少编译器优化选项,比如“-cl-denorms-are-zero -cl-fast-relaxed-math”,这些非常规参数很容易导致问题。
    回复

    使用道具 举报

  • TA的每日心情
    无聊
    2018-10-31 18:41
  • 签到天数: 4 天

    [LV.2]偶尔看看I

    0

    主题

    37

    回帖

    8

    VC币

    中级会员

    Rank: 3Rank: 3

    积分
    3812
    787633258 发表于 2024-11-29 08:56:02 | 显示全部楼层
    KNLMeansCL在amd显卡上坏了很久了,预测gtx770赢。
    建议考虑一下用cpu版本nlm-ispc
    回复

    使用道具 举报

  • TA的每日心情
    奋斗
    昨天 19:26
  • 签到天数: 21 天

    [LV.4]偶尔看看III

    1

    主题

    10

    回帖

    0

    VC币

    白金会员

    Rank: 12Rank: 12Rank: 12

    积分
    71350
    yuygfgg 发表于 2024-11-29 10:01:20 | 显示全部楼层
    KNLMeansCL 在apple soc上也是坏的(

    这玩意根本不好使
    回复

    使用道具 举报

  • TA的每日心情
    慵懒
    昨天 21:57
  • 签到天数: 270 天

    [LV.8]以坛为家I

    10

    主题

    43

    回帖

    0

    VC币

    荣誉会员

    Rank: 14Rank: 14Rank: 14Rank: 14

    积分
    103175
    op200  楼主| 发表于 2024-11-29 13:43:48 | 显示全部楼层
    yuygfgg 发表于 2024-11-29 10:01
    KNLMeansCL 在apple soc上也是坏的(

    这玩意根本不好使

    我感觉效果挺好的,再加上没找到其他好用的滤镜,就一直用的这个(

    顺带一提,这玩意的时域降噪(形参 a)开了之后会有残影,而且默认参数就是开的(a=1),过于抽象

    回复

    使用道具 举报

  • TA的每日心情
    奋斗
    昨天 19:26
  • 签到天数: 21 天

    [LV.4]偶尔看看III

    1

    主题

    10

    回帖

    0

    VC币

    白金会员

    Rank: 12Rank: 12Rank: 12

    积分
    71350
    yuygfgg 发表于 2024-11-29 20:33:17 | 显示全部楼层
    本帖最后由 yuygfgg 于 2024-11-29 21:05 编辑

    我现在基本用的bm3dcuda (其实没有cuda,用的cpu版);要是噪点太严重就用dpir;nlm速度不快(比bm3d快一倍左右,但是两者都挺快的),效果还差


    残影时域降噪都会有点吧 特别是MVTools那一派的会比nlm更明显...不过我也不太懂(

    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    快速回复 返回顶部 返回列表