Cat-myq

> hi, ncnn yolo11 examples are on board https://github.com/Tencent/ncnn/tree/master/examples https://github.com/nihui/ncnn-android-yolo11 > > model conversion guide (zh) https://zhuanlan.zhihu.com/p/1903414797195781701 首先感谢大佬，用例子中的方式裁剪模型，修改推理代码后，在原先出问题的GPU上输出结果正常了。 分析例子发现，外部实现后处理相当于将box位置的计算拿出来放在CPU上进行。令我不解的是，为什么后处理放在GPU上会运行错误。 后面我又进行了以下测试： - 测试环境：同样放在出错的GPU上运行 1. 代码1： ```c++ ncnn::Extractor ex = net->create_extractor(); ex.input("in0",...

抱歉，刚才误触了关闭，这里直接说明最新进展： ### 错误原因 经排查，出现错误的GPU是因为其不支持Vulkan的推送描述符`VK_KHR_push_descriptor`： ```c++ vkdev->info.support_VK_KHR_push_descriptor(); ``` ### 错误情况 - box位置错误 - 概率、置信度、角度正常 ### 错误定位 - 最终定位到错误出现在`layer_index = 204`层，后续位置计算依赖该层结果，因此该层出错导致最终位置错误： ``` layer_204->MemoryData pnnx_188 0 1 255 0=8400 ``` - 影响204层出错的层大概率是305层： ```...

@nihui 大佬，我后续又深入vulkan研究了一下，麻烦你看看这种现象 ### 只要存在为临时变量top_blob_unpacked申请内存，并且不支持VK_KHR_push_descriptor的GPU感觉都会必然出现这种现象。 ## 一、RenderDoc捕获vulkan指令 通过RenderDoc捕获Vulkan指令，发现**204层（clone运算）与305层（concat运算）存在显存地址重叠**，最终导致依赖204层结果的306层读取异常。 ### 1. 显存地址重叠验证 核心冲突对象为**buffer5271**，两层对该buffer的写入地址范围完全重叠，具体如下： - 204层（clone传输单元）：写入地址 `3069888 ~ 3069888 + 33600` - 305层（CS计算单元）：写入地址 `3069888 ~ 3069888 + 134400` - 整体地址重叠：两层写入起始地址均为`3069888`，204层地址范围完全包含于305层地址范围内。 ### 2. 指令调度异常与数据覆盖...