An efficient hardware architecture of integer motion estimation based on early termination and data

An efficient hardware architecture of integer motion estimation based on early termination and data
Zhang, Jun, Yu Zhang, and Hao Zhang. “An efficient hardware architecture of integer motion estimation based on early termination and data reuse for versatile video coding.” Expert Systems with Applications 242 (2024): 122706.

一、现存问题分析

1、由于降低搜索复杂度而降低搜索精度

目前已有的一些整数运动估计算法(如三步和四步搜索算法)通过简化搜索模板来降低运动估计的复杂度。然而,减少搜索点的数量和使用更小的搜索窗口会导致搜索算法陷入局部最优而不是全局最优,从而降低运动搜索的准确性。

2、由于增强搜索精度而导致高计算复杂度和资源消耗

另一种类型的整数运动估计算法(例如菱形搜索算法)采用复杂的搜索模板并增加搜索窗口内的搜索点的数量以提高搜索精度。复杂的运动搜索过程和额外的计算数据导致在视频编码期间显著的计算和存储资源消耗,这是以高成本来实现的。

二、论文提出的方法

1、基于搜索窗口划分的数据重用算法

TZ搜索过程中,搜索窗口重复调用参考像素比例较大,论文提出划分策略。

分析了TZ搜索算法搜索窗口中搜索点的分布,将单元块的大小设置为8×8。较大的块可以被分成几个8×8的子块。搜索窗口被分成两部分:距离大于4的区域称为稀疏区域,距离不大于4的区域称为密集区域。当距离小于或等于4时,满足提前终止以高概率提前结束复杂的搜索过程。搜索点太密集而不能分成8×8个子块。并且对于所有PU大小,仅当步长小于或等于4时才使用搜索窗口中的所有参考像素。

第一个搜索起点被分成四个8×8的子块:A、B、C、D,第二个搜索起点被分成四个8×8的子块:E、F、G、H。当读取参考像素时,不同子块中的重复像素被分配给相应的子块。

在这里插入图片描述

直观展示不同搜索点下的数据重复使用。

在这里插入图片描述

分析了不同尺寸CU在TZ搜索过程中,数据重复使用的占比情况。

在这里插入图片描述

论文想要解决的是从片外重复读取数据这部分消耗,但是片上重新组装的资源消耗是不变的,并没有节省下来。 16×16×8=2KB这个区域分配后就是4KB,大约就有一半是重复的。

参考像素的输入采用的是行输入,但每一次输入的是一行像素,而不是一个完整的8×8块。这些像素会被分配到多个8×8子块中,策略是输入一行,然后first-stage给每个8×8子块分类缓冲,等到一个完整的8×8子块拼接完成输入给下一个阶段进行比较处理。【这里的存储容量的计算感觉有问题,4KB、272bits、80KB的问题都没有说清楚。】核心目的是期望获得一个没有重复调用的8×8子块,然后根据8×8子块进行SAD计算等,那么这个地方根据CU尺寸的不同,扫描顺序就成了一个问题,IME的硬件架构设计也有点问题,上面的SAD Cal不应该只有8个8*8,这样的话并不支持128×128。而且从这个角度来看,需要缓存完整的一个参考像素来做计算,片上资源消耗问题也就出来了。【我现在算出来他的4KB是64×64×8,也就是说缓存一个64×64的参考】

在这里插入图片描述

2、稠密区域/稀疏区域

  1. 稠密区域策略
    • 按行读取和数据复用:参考像素按行读取,并分配到8×8的子块中,以提高数据复用率,减少从外部存储器读取数据的次数。
    • 突发传输:由于像素在行中是连续的,使用突发传输来提高数据传输效率。
    • 提前终止:在搜索过程中,如果SAD值小于等于阈值Tn,则提前终止搜索,减少计算复杂度。
    • 8×8子块划分:稠密区域的搜索窗口被划分为8×8的子块,以便于数据复用和SAD计算。
  2. 稀疏区域策略
    • 按距离分段读取:参考像素按距离从小到大读取,以提高效率。
    • 可变大小子块划分:根据PU的大小,将参考像素划分为四个可变大小的稀疏区域搜索窗口。
    • 数据复用:稀疏区域的搜索窗口也被划分为8×8的子块,以便于数据复用和减少存储资源的消耗。
    • 提前终止:在搜索过程中,如果SAD值小于等于阈值Tn,则提前终止搜索,减少计算复杂度。

Read more

Windows 环境下 llama.cpp 编译 + Qwen 模型本地部署全指南

在大模型落地场景中,本地轻量化部署因低延迟、高隐私性、无需依赖云端算力等优势,成为开发者与 AI 爱好者的热门需求。本文聚焦 Windows 10/11(64 位)环境,详细拆解 llama.cpp 工具的编译流程(支持 CPU/GPU 双模式,GPU 加速需依赖 NVIDIA CUDA),并指导如何通过 modelscope 下载 GGUF 格式的 Qwen-7B-Chat 模型,最终实现模型本地启动与 API 服务搭建。 1.打开管理员权限的 PowerShell/CMD,执行以下命令克隆代码: git clone https://github.com/ggml-org/llama.cpp mkdir

VsCode远程Copilot无法使用Claude Agent问题

最近我突然发现vscode Copilot中Claude模型突然没了,我刚充的钱啊!没有Claude我还用啥Copilot 很多小伙伴知道要开代理,开完代理后确实Claude会出来,本地使用是没有任何问题的,但是如果使用远程ssh的话,会出现访问异常,连接不上的情况。这时候很多小伙伴就在网上寻找方法,在vscode setting中添加这么一段代码。可以看看这篇博客 "http.proxy": "http://127.0.0.1:1082", "remote.extensionKind": { "GitHub.copilot": [ "ui" ], "GitHub.copilot-chat": [ "ui" ], "pub.name": [ "ui&

OpenClaw之Memory配置成本地模式,Ubuntu+CUDA+cuDNN+llama.cpp

文章目录 * 背景:Memory不生效的问题 * OpenClaw的Memory配置 * Ubuntu24.04安装CUDA和cuDNN * 编译llama.cpp * 验证方案1: * 验证方案2:下载并运行Llama-2 7B模型 * 安装node-llama-cpp * 验证Memory * sqlite-vec unavailable * 踩过的坑 * 安装node-llama-cpp的一些提示 * 安装node-llama-cpp的前置条件 * Using `node-llama-cpp` With Vulkan 承接上文:Windows11基于WSL2首次运行Openclaw,并对接飞书应用,我已经在电脑上安装了OpenClaw,接下来解决Memory问题。走了很多弯路,下面主要讲我总结的正确的安装过程。 总结来说:针对Memory不生效的问题,又不想用OpenAI或Gemini,或者只想单纯的节省token,可以按照如下的方式,设置为local模式: * 修改openclaw.json配置 * 安装CUDA和cu

Stable Diffusion 3.5 FP8 + GPU算力组合推荐:最佳性价比配置出炉

Stable Diffusion 3.5 FP8 + GPU算力组合推荐:最佳性价比配置出炉 在AI绘画的世界里,你有没有遇到过这样的“灵魂拷问”? 👉 显卡爆了,图还没生成完? 👉 想跑个1024×1024高清图,结果提示“CUDA out of memory”? 👉 花大几万买A100,结果发现连SD3.5都跑不动FP16原版? 别慌,救星来了——Stable Diffusion 3.5 的 FP8 量化版本正式登场!🚀 它不是简单的“压缩包”,而是一次真正的技术跃迁:显存砍半、速度飙快、画质几乎不变。更关键的是,你现在用一张消费级显卡,也能干翻以前需要多块专业卡才能完成的任务。 那么问题来了:到底哪款GPU最适合跑这个FP8版SD3.5?怎么配才不花冤枉钱? 咱们今天就来扒一扒这背后的门道,顺便给你整出一份“闭眼入”的性价比神装清单 💪。 先说结论:如果你是做生产部署、