1.女黑客真要价1亿美元？GPU源代码泄露事件后续还有吗？
2.AMD被黑客叫卖Navi显卡源码，显卡显1亿美元出售是源码源码真吗？
3.腾讯T2I-adapter源码分析（1）-运行源码跑训练
4.视频和视频帧：Intel GPU（核显）的编解码故事
5.Ubuntu20.04源码编译CARLA0.9.14全过程记录

女黑客真要价1亿美元？GPU源代码泄露事件后续还有吗？

AMD GPU源代码遭女黑客公开叫卖，价值达1亿美元

       近日，什意思AMD遭受了一次不寻常的显卡显威胁，一位女性黑客声称成功获取了AMD当前和未发布图形产品的源码源码部分测试文件，其中包括了AMD Navi 、什意思安卓源码 翻墙Navi 和Arden GPU的显卡显源代码。Navi 对应的源码源码是RX /系列显卡的核心，Navi 预示着下一代RDNA 2架构的什意思旗舰产品，而Arden据传是显卡显Xbox Series X内部采用的GPU核心。

       据称，源码源码被盗的什意思图形IP虽然非核心机密，但对AMD的显卡显声誉和产品安全构成了威胁。AMD已采取法律行动应对，源码源码但黑客并未因此退缩。什意思她声称通过远程攻击获取了这些源代码，并公开标价1亿美元，表示正在寻找买家，若无人接手，她将全部泄漏至网络。

       黑客曾将部分代码发布到GitHub，但在AMD的要求下被删除。然而，这位女黑客并未停止行动，她在平台上发布了第二部分源代码，文件名中明确标注为“pt.2”。她表示，如果未达成她的要求，她将继续分批公开剩余部分。

       AMD目前对此事保持沉默，而黑客拒绝接受进一步的采访。这场事件对AMD来说，无疑是一场潜在的商业和安全危机，如果源代码被大量公开，后果将不堪设想。

AMD被黑客叫卖Navi显卡源码，1亿美元出售是真吗？

AMD遭遇严重信息安全事件：1亿美元Navi显卡源码被曝光

       近期，AMD在公告中揭示了一起惊人的事件：年底，有人试图联系他们，声称持有AMD图形产品及相关子集的测试文件。这些文件一度在网上传出，canvas推箱子游戏源码但已被删除。AMD强调，虽然这些测试文件非核心机密，但黑客可能还有其他未公开的AMD知识产权（IP）存在。

       AMD已果断采取行动，报警并将此事交由刑事调查处理，与执法机构紧密合作，以应对这一威胁。然而，公众对于此事的知晓程度并不高，直到有人在Github上发布了疑似被窃取的Navi显卡源码，最初甚至标价1亿美元，若未达成交易，将公之于众。

       AMD已通过法律途径要求Github删除相关源码，公告中明确表示，泄密内容并未涉及其核心产品，似乎在排除7nm Navi显卡源码泄露的可能。此次事件无疑给AMD及其用户带来了不小的忧虑，但AMD的快速反应和法律措施显示了他们对信息安全的重视。

腾讯T2I-adapter源码分析（1）-运行源码跑训练

       稳定扩散、midjourney等AI绘图技术，为人们带来了令人惊叹的效果，不禁让人感叹技术发展的日新月异。然而，AI绘图的可控性一直不是很好，通过prompt描述词来操控图像很难做到随心所欲。为了使AI绘制的图像更具可控性，Controlnet、T2I-adapter等技术应运而生。本系列文章将从T2I-adapter的源码出发，分析其实现方法。

       本篇是第一篇，主要介绍源码的运行方法，后续两篇将以深度图为例，分别分析推理部分和训练部分的代码。分析T2I-Adapter，也是为了继续研究我一直在研究的课题：“AI生成同一人物不同动作”，例如：罗培羽：stable-diffusion生成同一人物不同动作的尝试（多姿势图），Controlnet、django图片网站源码T2I-adapter给了我一些灵感，后续将进行尝试。

       T2I-Adapter论文地址如下，它与controlnet类似，都是在原模型增加一个旁路，然后对推理结果求和。

       T2I-Adapter和controlnet有两个主要的不同点，从图中可见，其一是在unet的编码阶段增加参数，而controlnet主要是解码阶段；其二是controlnet复制unit的上半部结构，而T2I-Adapter使用不同的模型结构。由于采用较小的模型，因此T2I-Adapter的模型较小，默认下占用M左右，而controlnet模型一般要5G空间。

       首先确保机器上装有3.6版本以上python，然后把代码clone下来。随后安装依赖项，打开requirements.txt，可以看到依赖项的内容。然后下载示例，下载的会放到examples目录下。接着下载sd模型到model目录下，再下载T2I-Adapter的模型到目录下，模型可以按需到huggingface.co/TencentA...下载。这里我下载了depth和openpose。sd模型除了上述的v1-5，也还下载了sd-v1-4.ckpt。

       根据文档，尝试运行一个由深度图生成的例子，下图的左侧是深度图，提示语是"desk, best quality, extremely detailed"，右侧是生成出来的。运行过程比较艰辛，一开始在一台8G显存的服务器上跑，显存不够；重新搭环境在一台G显存的服务器上跑，还是不够；最后用一台G显存的服务器，终于运行起来了。

       接下来尝试跑openpose的例子，下图左侧是android5.0 源码编译骨架图，提示词为"Iron man, high-quality, high-res"，右侧是生成的图像。

       既然能跑推理，那么尝试跑训练。为了后续修改代码运行，目标是准备一点点数据把训练代码跑起来，至于训练的效果不是当前关注的。程序中也有训练的脚步，我们以训练深度图条件为例，来运行train_depth.py。

       显然，习惯了，会有一些问题没法直接运行，需要先做两步工作。准备训练数据，分析代码，定位到ldm/data/dataset_depth.py，反推它的数据集结构，然后准备对应数据。先创建文件datasets/laion_depth_meta_v1.txt，用于存放数据文件的地址，由于只是测试，我就只添加两行。然后准备，图中的.png和.png是结果图，.depth.png和.depth.png是深度图，.txt和.txt是对应的文本描述。

       文本描述如下，都只是为了把代码跑起来而做的简单设置。设置环境变量，由于T2I-Adapter使用多卡训练，显然我也没这个环境，因此要让它在单机上跑。而代码中也会获取一些环境变量，因此做简单的设置。

       做好准备工作，可以运行程序了，出于硬件条件限制，只能把batch size设置为1。在A显卡跑了约8小时，git的linux源码下载完成，按默认的配置，模型保存experiments/train_depth/models/model_ad_.pth。那么，使用训练出来的模型试试效果，能生成如下（此处只是为了跑起来代码，用训练集来测试），验证了可以跑起来。

       运行起来，但这还不够，我们还得看看代码是怎么写法，下一篇见。

       PS：《直观理解AI博弈原理》是笔者写的一篇长文，从五子棋、象棋、围棋的AI演进讲起，从深度遍历、MAX-MIN剪枝再到蒙特卡罗树搜索，一步步介绍AI博弈的原理，而后引出强化学习方法，通俗易懂地介绍AlphaGo围棋、星际争霸强化学习AI、王者荣耀AI的一些强化学习要点，值得推荐。

       AUTOMATIC的webui是近期很流行的stable-diffusion应用，它集合stable-diffusion各项常用功能，还通过扩展的形式支持controlnet、lora等技术，我们也分析了它的源码实现，写了一系列文章。

视频和视频帧：Intel GPU（核显）的编解码故事

       一般提及基于“显卡或多媒体处理芯片对视频进行解码”为硬解码，本文将探讨如何利用Intel的核显，即集成GPU实现硬解码。提及QSV，全称为Quick Sync Video，Intel在年发布Sandy Bridge CPU时，一同推出了这项基于核显进行多媒体处理，包括视频编解码的技术。集成核显，官方称HD Graphics，最早在Sandy Bridge前一代制程已推出，但性能提升及充分发挥在Sandy Bridge时期。Haswell及后续制程发布更高级的Iris架构。最近Intel宣布将开发独立显卡，核显发展具体走向未知。

       接手QSV项目时，预期会有很多相关资料，实则相反。因此，将记录自己学习过程。

       本文将介绍：

       I. Intel的核显（集成GPU）：

       了解核显很有必要，几个月前，作者对CPU的认识还停留在“南北桥”架构。以下内容若有不准确之处，欢迎指正。

       查看Gen CPU结构图，首先看CPU核心部分。在整块CPU芯片中，核显占比不小，算力不容小觑。在没有独立显卡的笔记本上，可以运行大量大型游戏，虽偶有卡顿、掉帧情况，整体表现已相对不错。

       接下来，看官方给出的GPU内部结构图。GPU内部远比图上所示复杂，图中介绍的仅为部分Subslice芯片结构。GPU分为Slice部分和Un-Slice部分，Slice部分已介绍，接下来介绍Un-Slice部分。

       作者找到了一张图，展示了在MFF上进行视频处理的流程：1) 首先在MFX/VDBOX模块上进行编解码；2) 接着送到VQE/VEBOX上做图像增强和矫正处理；3) 然后送到SFC上做scale和transcode；4) 最后送出到显示屏上展示。是否完全正确，作者这里做个记录。

       推荐知乎文章《转》Intel Gen8/Gen9核芯显卡微架构详细剖析，深入浅出，关于thread dispatch的说明即出自该文。

       最后，总结Intel集成GPU/核显结构图。

       注意，这是skylake架构下的GT2/GT3/GT4 GPU结构图，X数字越大，集成的Slice和Unslice芯片更多，能力越强，价格也更高。

       II. Quick Sync Video（QSV）技术：

       QSV是Intel推出的将视频处理任务直接送到GPU上进行专门负责视频处理的硬件模块处理的软件技术。与CPU或通用GPU上的视频编码不同，QSV是处理器芯片上的专用硬件核心，这使得视频处理更为高效。

       要了解QSV如何驱动GPU的MFF，首先看官方Intel® Video and Audio for Linux上的图。在介绍QSV之前，提及Intel在FFmpeg上提供的插件，包括ffmpeg-qsv、ffmpeg-vaapi和ffmpeg-ocl。详细描述如下：

       · FFmpeg-vaapi提供基于低级VAAPI接口的硬件加速，在VA API标准下在Intel GPU上执行高性能视频编解码器、视频处理和转码功能。

       · FFmpeg-qsv提供基于Intel GPU的硬件加速，基于Intel Media SDK提供高性能视频编解码器、视频处理和转码功能。

       · FFmpeg-ocl提供基于工业标准OpenCL在CPU/GPU上的硬件加速，主要用于加速视频处理过滤器。

       接下来，介绍QSV在ffmpeg2.8及以上版本的支持，经过MSDK、LibVA、UMD和LibDRM。分层进行分析：

       · MSDK：Intel的媒体开发库，支持多种图形平台，实现通用功能，可用于数字视频的预处理、编解码和不同编码格式的转换。源码地址为Intel® Media SDK，在Linux平台上编译使用。

       · VA-API：Video Acceleration API，提供类unix平台的视频硬件加速开源库和标准。Intel源码地址在Intel-vaapi-driver Project，在Linux平台上使用。

       · UMD：User Mode Driver的缩写，指VA-API Driver。Intel提供了两个工具：intel-vaapi-driver 和 intel-media-driver，推荐使用后者。

       · LibDRM：Direct Rendering Manager，解决多个程序协同使用Video Card资源问题，提供一组API访问GPU。与VA-API，LibDRM是一套通用的Linux/Unix解决方案。

       · Linux Kernel：Intel的Kernel是i driver，描述了libDRM和Kernel Driver之间的关系。

       至此，整个关系图较为清晰。

       III. FFMPEG+QSV解码：

       QSV硬解的任务主要包括：

       关于3-4步操作的详细实现，底层库会帮助完成。但作为一个优秀的工程师，研究FFMPEG源码依然十分重要。接下来，介绍如何使用FFmpeg API中的h_qsv解码器插件。

       提及FFmpeg命令行使用方法，推荐阅读官方资料《QuickSync》或《Intel_FFmpeg_plugins》。

       关于示例代码，作者曾遇到许多坑，总结为：多数中文博客不可靠，官方demo最可信。官方代码提供了两份可用：qsvdec.c和hw_decode.c。作者最早使用的是第一段代码，核心部分如下：

       然而，这段代码存在问题。测试发现，对于赛扬系列一款CPU，在p视频上MSDK达到fps，理论上h_qsv平台上限也应为fps，但实际测试不到fps。排查后发现是av_hwframe_transfer_data()性能较弱。

       最终，与Intel一起解决了性能问题。那么，性能提升方案为何是GPU-COPY技术做Memory-Mapping？

       解释GPU和CPU渲染图像的过程，包括坐标系转化、纹理叠加等，仅需了解两点：

       后者的数据组织方式能充分利用GPU的并行特性，加速图像处理、渲染。尽管存在一些纹理叠加的技术难题，但性能提升足以补偿。

       接下来，解释Memory-Mapping：从Intel CPU架构图中可见，GPU和CPU位于同一芯片上，各自寄存器/缓存区有限，视频数据主要存储在内存上。GPU和CPU的数据组织方式不同，同一帧数据存于内存同一位置，数据格式不同，因此需要做Memory-Mapping。Memory-Mapping相较于Memory-Copy，减少了数据从内存区域A移动到区域B的操作，已经是优化。进一步优化：GPU完成Memory-Mapping以及数据从GPU到内存和CPU的操作。

       在av_hwframe_transfer_data()内部，Memory-Mapping由CPU完成，性能受限于CPU，只能并行。修改后，整体性能从不到fps提升至fps，虽然与理想fps仍有差距，但满足性能需求。

       据悉，Intel将在FFmpeg 4.3开源出这个解决方案。

       写在后面：

       了解GPU底层对应用开发人员帮助不大，毕竟了解芯片布线的重新设计、制程工艺提升、GPU-COPY技术的数据I/O提升等，也不能做什么。最终，芯片架构是芯片工程师的事，底层逻辑实现是嵌入式工程师的事。应用开发人员无法做出实质贡献，但作为知识库扩充或休闲阅读，了解也无妨。

       希望有机会接触CUDA的编解码，深入学习N卡设计。

       感谢因《视频和帧》系列文章结识的朋友，热心指出文章描述不准确的地方。文中如有不严谨之处，欢迎指正。

Ubuntu.源码编译CARLA0.9.全过程记录

       本文详尽记录了在Ubuntu .上通过源码编译CARLA 0.9.的全过程，特别强调了Linux系统环境的配置以支持与ROS和Autoware的协同仿真，并且允许自定义场景和车辆配置。

       步骤一：系统基础配置

       首先，确保安装Ubuntu .并配置Nvidia显卡驱动，参考链接：win + Ubuntu . LTS 双系统安装（UEFI + GPT）。

       步骤二：安装依赖

       参考Linux build - CARLA Simulator -branch 0.9.，逐步安装必要的软件，如遇到下载问题，可考虑使用阿里源或新华源，推荐查阅：ubuntu安装软件依赖问题。

       步骤三：Unreal Engine 4. 安装与配置

       由于CARLA 0.9.以上版本使用UE4.，需先安装并编译。确保Github账户已与Unreal Engine账户关联，如需Personal Access Token，参考Github - 使用新的Personal Access Token进行仓库认证。

       步骤四：下载与编译CARLA

       从官方仓库下载CARLA源代码，更新时可能遇到官方资产Url变化，需修改Update.sh文件。编译过程中，PythonAPI部分网络需求较高，make launch可能需要设定UE4_ROOT环境变量，具体步骤见BuildCarlaUE4.sh。

       步骤五：运行测试

       在完成上述步骤后，进行测试并欢迎在评论区交流问题，如有任何疑问，欢迎留言。如果你对内容满意，请别忘了收藏和关注。