Broadcom BCM5770X 网络驱动支持即将登陆 Linux 6.17
一个月前, Phoronix 发布了一份报告, 称 Broadcom "BNGE" 开源驱动程序已发布, 用于即将推出的 BCM5770X 网络芯片组
该新的 Broadcom BNGE 驱动程序现已确定将在即将发布的 Linux 6.17 内核中引入, 以支持新的 Broadcom 有线网络硬件, 速度高达 800 千兆
Broadcom BCM5770X 网络 ASIC 支持 50 / 100 / 200 / 400 / 800 Gb/s 的链接速度
支持 BCM5770X 芯片系列的 BNGE "bng_en" 驱动程序代码量超过四千行, 但目前只提供了基本的硬件/功能支持
该驱动程序最初支持的硬件目标是 Broadcom BCM57708
引入该驱动程序的补丁消息解释道:
这个新的 Broadcom 有线网络驱动程序已经排队进入 net-next.git 代码, 因此应该在 7 月底/8 月初的 Linux 6.17 合并窗口中合并
Linux 6.17 稳定版将于 10 月初发布, 并将在 Fedora 43 和 Ubuntu 25.10 等系统中原生支持 Broadcom BCM5770X 硬件
#LinuxNetworking
原文链接
一个月前, Phoronix 发布了一份报告, 称 Broadcom "BNGE" 开源驱动程序已发布, 用于即将推出的 BCM5770X 网络芯片组
该新的 Broadcom BNGE 驱动程序现已确定将在即将发布的 Linux 6.17 内核中引入, 以支持新的 Broadcom 有线网络硬件, 速度高达 800 千兆
Broadcom BCM5770X 网络 ASIC 支持 50 / 100 / 200 / 400 / 800 Gb/s 的链接速度
支持 BCM5770X 芯片系列的 BNGE "bng_en" 驱动程序代码量超过四千行, 但目前只提供了基本的硬件/功能支持
该驱动程序最初支持的硬件目标是 Broadcom BCM57708
引入该驱动程序的补丁消息解释道:
此补丁系列引入了 Broadcom BCM5770X 芯片家族的以太网驱动程序, 该家族支持 50/100/200/400/800 Gbps 的链接速度
该驱动程序构建为 bng_en.ko 内核模块
为了将系列保持在可审查的大小 (约 5K 行代码内) , 本次初始提交侧重于核心基础设施和初始化, 包括:
1. PCIe 支持 (设备 ID, 探测/移除)
2. Devlink 支持
3. 固件通信机制
4. 网络设备创建
5. PF 资源管理 (用于 netdev 和辅助设备的环, 中断等)
Tx/Rx 数据路径, 链接管理, ethtool/devlink 操作和附加功能的支持将在后续补丁系列中引入
bng_en 驱动程序与 bnxt_en 驱动程序共享 bnxt_hsi.h 文件, 因为 bng_en 驱动程序利用了 bnxt_en 驱动程序使用的硬件通信协议
这个新的 Broadcom 有线网络驱动程序已经排队进入 net-next.git 代码, 因此应该在 7 月底/8 月初的 Linux 6.17 合并窗口中合并
Linux 6.17 稳定版将于 10 月初发布, 并将在 Fedora 43 和 Ubuntu 25.10 等系统中原生支持 Broadcom BCM5770X 硬件
#LinuxNetworking
原文链接
Blender 4.5 LTS 发布: 包含 Vulkan 和 Wayland 改进及部分优化
Blender 4.5 作为这款流行的跨平台 3D 建模软件的最新功能版本, 现已正式发布, 并且是一个长期支持 (LTS) 版本
Blender 4.5 LTS 是一个重要的版本, 为即将到来的 Blender 5.0 做好了准备
Blender 4.5 具有更好的 Vulkan 支持和大量其他增强功能:
有关 Blender 4.5 LTS 版本及其诸多变化的更多详细信息, 请参阅 Blender 4.5 发布说明
Blender 4.5 适用于所有主要平台, 可从 Blender.org 下载此出色的免费软件
Blender 4.5 版本针对 CPU 和 GPU 的最新基准测试即将推出
#FreeSoftware
原文链接
Blender 4.5 作为这款流行的跨平台 3D 建模软件的最新功能版本, 现已正式发布, 并且是一个长期支持 (LTS) 版本
Blender 4.5 LTS 是一个重要的版本, 为即将到来的 Blender 5.0 做好了准备
Blender 4.5 具有更好的 Vulkan 支持和大量其他增强功能:
- Blender 的 Vulkan 后端现在被认为与 OpenGL 处于同等水平
Vulkan 代码现在支持 OpenXR, 细分, USD/Hydra 和其他功能
使用 Vulkan 后端的性能也比以前的版本更好
Blender 4.5 默认仍使用 OpenGL, 但基本上, 当使用最新的 Windows 或 Linux 驱动程序时, Vulkan 路径应该可以用于生产环境
- 为 Linux 用户提供了一些 Wayland 和 X11 平台增强功能
- Vector Math, Vector Rotate, Vector Mix, Value Mix, Clamp, Float Curve 和 Blackbody 节点已添加到 Blender 4.5 中
- 借助此 Blender 核心改进, 当存在许多数据块时, Blender 4.5 的依赖图构建速度提高了 18%
- 实验性自适应细分支持的改进, 包括多线程以获得更好的性能
- Eevee 的纹理加载性能得到了改善, 启动性能也得到了提高
着色器编译现在默认也支持多线程
- Blender 4.5 的物理代码将液体模拟性能提高了 1.25~1.5 倍
- Blender 4.5 现在支持写入 ProRes 编解码器视频, 一次导入多个 SVG 文件, USD 文件导入改进, 以及各种其他文件处理导入/导出改进
- 大端支持已弃用, 并将在 Blender 5.0 中移除
- 不再支持 Intel 硬件上的 macOS
由于在 Intel 或 AMD GPU 的 Intel Mac 上处理图形相关问题导致的高维护成本, Blender 4.5 是官方 Intel macOS 构建的最后一个版本
有关 Blender 4.5 LTS 版本及其诸多变化的更多详细信息, 请参阅 Blender 4.5 发布说明
Blender 4.5 适用于所有主要平台, 可从 Blender.org 下载此出色的免费软件
Blender 4.5 版本针对 CPU 和 GPU 的最新基准测试即将推出
#FreeSoftware
原文链接
❤1
Intel 在 Linux 6.17 为 Battlemage 显卡启用 SR-IOV
即将推出的 Linux 6.17 内核对于 Linux 上现代 Intel 图形硬件的用户来说, 将是一个特别棒的版本
为下一个 Linux 内核版本启用的最新功能是针对 Battlemage GPU 的 SR-IOV, 以极大地增强虚拟化环境中的 Intel Linux 图形体验
在 Linux 6.17 内核合并窗口之前, 已经有补丁排队等待默认启用 Panther Lake 的 Xe3 图形 (在 Panther Lake 笔记本电脑首次亮相之前有效宣布其稳定) , 作为 Project Battlematrix 一部分的多设备 (多 GPU) 准备工作, Wildcat Lake 图形支持, 通过 sysfs 从 Xe 驱动程序获取风扇控制和电压信息, 无闪烁启动改进, 实验性翻转队列支持, 甚至长期延迟/被忽视的 DG1 图形也默认启用
现在, 今天提交给 DRM-Next, 在 Linux 6.17 之前, 最新的是为 Battlemage 图形启用单根 I/O 虚拟化 (SR-IOV) 支持
Intel 已经支持其多代图形处理器上的 SR-IOV, 尽管 Linux 下针对不同 Intel 图形世代的官方 SR-IOV 支持有所不同
对于 Linux 6.17, SR-IOV 在 Battlemage GPU 上工作并已启用, 前提是您的显卡运行的是最新固件
Battlemage 上的 SR-IOV 支持是 Intel Project Battlematrix 计划的一部分
Intel 工程师还在努力开发 VDI 和其图形硬件的其他虚拟化改进, 作为 Battlematrix 的一部分
Battlemage 的 SR-IOV 是今天 drm-xe-next 拉取请求的一部分
Linux 6.17 正在成为一个非常令人兴奋的内核功能版本
Linux 6.17 合并窗口将在 8 月初开放, 而稳定的 Linux v6.17 将在 10 月初首次亮相, 并为 Ubuntu 25.10 和 Fedora 43 等 Linux 发行版提供支持
#Intel
原文链接
即将推出的 Linux 6.17 内核对于 Linux 上现代 Intel 图形硬件的用户来说, 将是一个特别棒的版本
为下一个 Linux 内核版本启用的最新功能是针对 Battlemage GPU 的 SR-IOV, 以极大地增强虚拟化环境中的 Intel Linux 图形体验
在 Linux 6.17 内核合并窗口之前, 已经有补丁排队等待默认启用 Panther Lake 的 Xe3 图形 (在 Panther Lake 笔记本电脑首次亮相之前有效宣布其稳定) , 作为 Project Battlematrix 一部分的多设备 (多 GPU) 准备工作, Wildcat Lake 图形支持, 通过 sysfs 从 Xe 驱动程序获取风扇控制和电压信息, 无闪烁启动改进, 实验性翻转队列支持, 甚至长期延迟/被忽视的 DG1 图形也默认启用
现在, 今天提交给 DRM-Next, 在 Linux 6.17 之前, 最新的是为 Battlemage 图形启用单根 I/O 虚拟化 (SR-IOV) 支持
Intel 已经支持其多代图形处理器上的 SR-IOV, 尽管 Linux 下针对不同 Intel 图形世代的官方 SR-IOV 支持有所不同
对于 Linux 6.17, SR-IOV 在 Battlemage GPU 上工作并已启用, 前提是您的显卡运行的是最新固件
Battlemage 上的 SR-IOV 支持是 Intel Project Battlematrix 计划的一部分
Intel 工程师还在努力开发 VDI 和其图形硬件的其他虚拟化改进, 作为 Battlematrix 的一部分
drm-xe-next-2025-07-15:
驱动程序更改:
- 创建并使用 XE_DEVICE_WA 基础设施
- SRIOV: 将 BMG 标记为支持 SR-IOV
- 不跳过 VF 上的 TLB 无效
- 修复 access_memory 中的迁移复制方向
- 常规代码清理
- 更多缺失的 XeLP 变通方案
- SRIOV: 放宽 VF/PF 版本协商
- SRIOV: LMTT 无效
Battlemage 的 SR-IOV 是今天 drm-xe-next 拉取请求的一部分
Linux 6.17 正在成为一个非常令人兴奋的内核功能版本
Linux 6.17 合并窗口将在 8 月初开放, 而稳定的 Linux v6.17 将在 10 月初首次亮相, 并为 Ubuntu 25.10 和 Fedora 43 等 Linux 发行版提供支持
#Intel
原文链接
为 Mesa 25.2 RADV 添加 AMD RDNA3 & RDNA4 光线追踪改进
Mesa 25.2 的功能冻结和代码分支预计将于本周晚些时候进行, 在此之前, Radeon "RADV" Vulkan 驱动今天合并了一些额外的光线追踪优化
这些最新的 RADV 光线追踪改进对最新的 Radeon RX 9000 系列 "RDNA4" 帮助最大, 但对 RDNA3 级 GPU 也有一些优化
Natalie Vock 是 Valve 的几位致力于 Linux 图形驱动栈的承包商之一, 她完成了这些最新的 RADV 光线追踪优化
该补丁系列增加了对 gfx11/gfx12 ds_bvh_stack* 指令的支持, 以及其他 GFX12 (RDNA4) 光线追踪性能改进
提醒一下, GFX11 适用于 RDNA3 和 RDNA3.5 GPU
Natalie 在合并请求中解释道:
然而, 今天合并到 Mesa 25.2 对最终用户来说真正的亮点是性能提升:
与目前 Mesa 25.2-devel 相比, AMD Radeon RX 9000 系列的性能提升了约 14%, 而 Mesa 25.2-devel 已经包含了一些光线追踪优化
在 Quake II RTX 之外, 光线追踪的优势也很有趣
就在上周, 我在 AMD Radeon RX 9070 光线追踪性能在 Mesa 25.2 中得到改进中介绍了一些基准测试, 这些测试已经显示了本季度 Mesa3D 功能发布中 RADV 的 Vulkan 光线追踪性能得到了大幅改进
随着今天的合并, 这些数字现在已经过时了, 我渴望在 AMD Radeon RX 7000 系列和 RX 9000 系列 GPU 上运行一些新的测试
#Radeon
原文链接
Mesa 25.2 的功能冻结和代码分支预计将于本周晚些时候进行, 在此之前, Radeon "RADV" Vulkan 驱动今天合并了一些额外的光线追踪优化
这些最新的 RADV 光线追踪改进对最新的 Radeon RX 9000 系列 "RDNA4" 帮助最大, 但对 RDNA3 级 GPU 也有一些优化
Natalie Vock 是 Valve 的几位致力于 Linux 图形驱动栈的承包商之一, 她完成了这些最新的 RADV 光线追踪优化
该补丁系列增加了对 gfx11/gfx12 ds_bvh_stack* 指令的支持, 以及其他 GFX12 (RDNA4) 光线追踪性能改进
提醒一下, GFX11 适用于 RDNA3 和 RDNA3.5 GPU
Natalie 在合并请求中解释道:
增加了对 gfx11 ds_bvh_stack_rtn 指令以及 gfx12 ds_bvh_stack_push8_pop1_rtn (用于 BVH8 遍历) 指令的支持
ds_bvh_push8_pop1 需要将 8x32 BVH 交集结果作为矢量对齐操作数输入, 以避免复制
这在 gfx11 上不是什么大问题, 因为我们只转发整个交集结果 - 在 gfx12 上我们需要操作单个组件
前两个提交是相当微不足道的更改, 如果我将它们拆分到其他 MR 中, 重新定位会非常麻烦, 但它们也为 gfx12 带来了显著的性能提升
我还将 "aco/isel: Use vector-aligned operands for image_bvh8_intersect_ray" 包含在此 MR 中, 因为它支持与 def 绑定的矢量对齐操作数作为共享依赖项 (ds_bvh_push8_pop1 也依赖于它) , 并且本身也相当简单
然而, 今天合并到 Mesa 25.2 对最终用户来说真正的亮点是性能提升:
在我的测试中, 所有组合的 q2rtx 在 gfx12 上获得了 14% 的 fps 提升
与目前 Mesa 25.2-devel 相比, AMD Radeon RX 9000 系列的性能提升了约 14%, 而 Mesa 25.2-devel 已经包含了一些光线追踪优化
在 Quake II RTX 之外, 光线追踪的优势也很有趣
就在上周, 我在 AMD Radeon RX 9070 光线追踪性能在 Mesa 25.2 中得到改进中介绍了一些基准测试, 这些测试已经显示了本季度 Mesa3D 功能发布中 RADV 的 Vulkan 光线追踪性能得到了大幅改进
随着今天的合并, 这些数字现在已经过时了, 我渴望在 AMD Radeon RX 7000 系列和 RX 9000 系列 GPU 上运行一些新的测试
#Radeon
原文链接
NVIDIA GeForce GTX 600/700 "Kepler" 显卡现支持 Vulkan 1.2 并符合 NVK 标准
Mesa 25.2 版本 (定于下个月发布, 距离功能冻结还有几天) 的功能代码仍在不断涌入, 今晚进入 Mesa Git 的代码现在将 NVIDIA Kepler GPU 视为符合 Vulkan 1.2 标准的设备, 此前 NVK 开源驱动程序与 Nouveau 内核驱动程序配合通过了 Vulkan 1.2 CTS
除少数例外, Kepler 主要指老化的 NVIDIA GeForce GTX 600 和 GTX 700 系列 (不包括 GeForce GTX 750 系列, 因为它是 Maxwell 1), 其他 Kepler 包括笔记本电脑的 GeForce GT 800M/900M 部分以及各种 Quadro "K" 显卡和 Quadro 410
NVIDIA Kepler GPU 已被 NVIDIA Linux 驱动程序视为 "遗留" 产品, Maxwell 和 Pascal 也将在下一个分支中走向这一步
对于那些希望继续使用上游 Linux 发行版且不想担心 NVIDIA 遗留系列的用户来说, Kepler NVK 支持仍在不断完善
此外, 使用 Nouveau DRM 内核驱动程序的 Kepler GPU 无需使用任何签名固件, 并且与后来的 Maxwell 部件不同
这款开源 NVIDIA 驱动程序能够重新设置 GPU 时钟以获得更好的性能
Collabora 的 Faith Ekstrand 刚刚提交了补丁, 该补丁现在将 Mesa Git 中的 Kepler GPU 视为符合 Vulkan 1.2 标准的设备, 先于 Mesa 25.2 分支, 此前已向 Khronos 提交了 Vulkan 1.2 CTS (1 和 2), 以正式确认支持, 到目前为止, 只有 Maxwell 1 及更新的 NVIDIA GPU 在 NVK 开源驱动程序上符合标准
如果您前几天错过了, 我当时在最新的 Mesa Git 代码上运行了一些新的 Mesa NVK 与 NVIDIA 驱动程序基准测试, 那是使用较新的 Ampere RTX 40 GPU 进行的
如果时间允许, 我很快会为 Mesa 25.2 运行一些新的 Kepler 基准测试, 尽管许多现代 Vulkan 游戏在老化的 GeForce GTX 600/700 系列硬件上无法运行良好
#Nouveau
原文链接
Mesa 25.2 版本 (定于下个月发布, 距离功能冻结还有几天) 的功能代码仍在不断涌入, 今晚进入 Mesa Git 的代码现在将 NVIDIA Kepler GPU 视为符合 Vulkan 1.2 标准的设备, 此前 NVK 开源驱动程序与 Nouveau 内核驱动程序配合通过了 Vulkan 1.2 CTS
除少数例外, Kepler 主要指老化的 NVIDIA GeForce GTX 600 和 GTX 700 系列 (不包括 GeForce GTX 750 系列, 因为它是 Maxwell 1), 其他 Kepler 包括笔记本电脑的 GeForce GT 800M/900M 部分以及各种 Quadro "K" 显卡和 Quadro 410
NVIDIA Kepler GPU 已被 NVIDIA Linux 驱动程序视为 "遗留" 产品, Maxwell 和 Pascal 也将在下一个分支中走向这一步
对于那些希望继续使用上游 Linux 发行版且不想担心 NVIDIA 遗留系列的用户来说, Kepler NVK 支持仍在不断完善
此外, 使用 Nouveau DRM 内核驱动程序的 Kepler GPU 无需使用任何签名固件, 并且与后来的 Maxwell 部件不同
这款开源 NVIDIA 驱动程序能够重新设置 GPU 时钟以获得更好的性能
Collabora 的 Faith Ekstrand 刚刚提交了补丁, 该补丁现在将 Mesa Git 中的 Kepler GPU 视为符合 Vulkan 1.2 标准的设备, 先于 Mesa 25.2 分支, 此前已向 Khronos 提交了 Vulkan 1.2 CTS (1 和 2), 以正式确认支持, 到目前为止, 只有 Maxwell 1 及更新的 NVIDIA GPU 在 NVK 开源驱动程序上符合标准
如果您前几天错过了, 我当时在最新的 Mesa Git 代码上运行了一些新的 Mesa NVK 与 NVIDIA 驱动程序基准测试, 那是使用较新的 Ampere RTX 40 GPU 进行的
如果时间允许, 我很快会为 Mesa 25.2 运行一些新的 Kepler 基准测试, 尽管许多现代 Vulkan 游戏在老化的 GeForce GTX 600/700 系列硬件上无法运行良好
#Nouveau
原文链接
❤1
Hyprland 0.50 发布, 包含新的渲染调度, 弃用传统渲染器
Hyprland 0.50 作为此 Wayland 合成器的最新功能版本于今日发布, 该版本专注于提供大量 Linux 桌面 "闪光点"
Hyprland 0.50 放弃了其旧版渲染器, 因此现在要求图形驱动程序至少支持 OpenGL ES 3.0
Hyprland 0.50 也不再提供显式同步设置, 因为现在默认情况下始终使用显式同步支持
Hyprland 0.50 中一个值得注意的补充是新的渲染调度, 它能够根据需要动态切换到三重缓冲
在某些情况下, 这可以为性能不足的设备提供更好的帧速率, 类似于 Ubuntu 在 GNOME 上为帮助 Intel 集成显卡和 Raspberry Pi 显卡等而追求的动态三重缓冲
Hyprland 0.50 将新的渲染调度视为实验性功能, 默认禁用, 但他们希望在下一个功能版本中可以默认启用
Hyprland 0.50 还增加了 "禁止屏幕共享" 选项, 可以在屏幕共享期间将任何窗口变黑以保护隐私, 并增加了对 DRM 租约的多 GPU 支持, 各种小型优化以及许多修复和其他增强功能
其中也包括一些 XWayland 集成修复
有关 Hyprland 0.50 合成器版本的下载和更多详细信息, 请访问 Hypr.land 和 GitHub
#Wayland
原文链接
Hyprland 0.50 作为此 Wayland 合成器的最新功能版本于今日发布, 该版本专注于提供大量 Linux 桌面 "闪光点"
Hyprland 0.50 放弃了其旧版渲染器, 因此现在要求图形驱动程序至少支持 OpenGL ES 3.0
Hyprland 0.50 也不再提供显式同步设置, 因为现在默认情况下始终使用显式同步支持
Hyprland 0.50 中一个值得注意的补充是新的渲染调度, 它能够根据需要动态切换到三重缓冲
在某些情况下, 这可以为性能不足的设备提供更好的帧速率, 类似于 Ubuntu 在 GNOME 上为帮助 Intel 集成显卡和 Raspberry Pi 显卡等而追求的动态三重缓冲
Hyprland 0.50 将新的渲染调度视为实验性功能, 默认禁用, 但他们希望在下一个功能版本中可以默认启用
Hyprland 0.50 还增加了 "禁止屏幕共享" 选项, 可以在屏幕共享期间将任何窗口变黑以保护隐私, 并增加了对 DRM 租约的多 GPU 支持, 各种小型优化以及许多修复和其他增强功能
其中也包括一些 XWayland 集成修复
有关 Hyprland 0.50 合成器版本的下载和更多详细信息, 请访问 Hypr.land 和 GitHub
#Wayland
原文链接
❤1
Intel 媒体驱动 2025Q2 发布 Panther Lake 视频编码支持
Intel Media Driver 发布了其季度功能版本, 为 Linux 上的 Intel 图形硬件带来了所有最新的开源视频加速改进
增强对即将推出的 Panther Lake SoC 的支持仍然是主要焦点
在内核图形方面, Panther Lake 已准备好与 Linux 6.17 配合使用, OpenGL 和 Vulkan 驱动程序支持也已就绪
当涉及到通过 Intel Media Driver 进行基于 VA-API 的视频加速时, Panther Lake 的支持也正在完善中
今天的 Intel Media Driver 2025Q2 版本带来了 Panther Lake 视频编码支持
此外, 这个季度 Intel Media Driver 版本还为 Panther Lake 增强了 HDR 播放稳定性
此外, 还有一些针对旧 Intel 图形平台的修复, 但完成 Panther Lake 的启动是 Intel Media Driver 2025Q2 的主要焦点
Broadwell 时代以来的 Intel 集成和独立图形硬件继续受到 Linux 系统上这个开源 VA-API 驱动程序的支持
Intel Media Driver 2025Q2 的下载和更多详细信息请通过 GitHub 获取
今天还发布了适用于 Intel oneAPI 媒体堆栈的 oneVPL GPU Runtime 2025Q2 版本
VPL GPU Runtime 现在也与 Panther Lake 视频编码支持兼容, 同时增加了对 VVC 解码级别 6.3 的支持
#Intel
原文链接
Intel Media Driver 发布了其季度功能版本, 为 Linux 上的 Intel 图形硬件带来了所有最新的开源视频加速改进
增强对即将推出的 Panther Lake SoC 的支持仍然是主要焦点
在内核图形方面, Panther Lake 已准备好与 Linux 6.17 配合使用, OpenGL 和 Vulkan 驱动程序支持也已就绪
当涉及到通过 Intel Media Driver 进行基于 VA-API 的视频加速时, Panther Lake 的支持也正在完善中
今天的 Intel Media Driver 2025Q2 版本带来了 Panther Lake 视频编码支持
此外, 这个季度 Intel Media Driver 版本还为 Panther Lake 增强了 HDR 播放稳定性
此外, 还有一些针对旧 Intel 图形平台的修复, 但完成 Panther Lake 的启动是 Intel Media Driver 2025Q2 的主要焦点
Broadwell 时代以来的 Intel 集成和独立图形硬件继续受到 Linux 系统上这个开源 VA-API 驱动程序的支持
Intel Media Driver 2025Q2 的下载和更多详细信息请通过 GitHub 获取
今天还发布了适用于 Intel oneAPI 媒体堆栈的 oneVPL GPU Runtime 2025Q2 版本
VPL GPU Runtime 现在也与 Panther Lake 视频编码支持兼容, 同时增加了对 VVC 解码级别 6.3 的支持
#Intel
原文链接
ESWIN Computing EBC77 RISC-V SBC 将支持 Ubuntu Linux
Canonical 今天宣布与 ESWIN Computing 合作, 将 Ubuntu Linux 作为其 ESWIN Computing EBC77 系列单板计算机的首选操作系统出货
基于 RISC-V 的 ESWIN Computing EBC77 采用了 ESWIN EIC7700X SoC, 提供四个 1.8GHz 的内核和一个自研的额定 20 TOPS 的 NPU, Imagination PowerVR 图形以及 LPDDR5-6400 内存支持
鉴于其自研的神经网络处理单元 (NPU), 该 NPU 何时能得到上游/主线内核版本的支持, 可能还需要一段时间
截至目前, 我尚未看到任何为在主线上启用此 NPU 而提交的 Linux 内核补丁
ESWIN EBC77 还配备了一个 4 通道 PCIe Gen3 FPC 插槽, 两个 USB 3.2 Gen1 插槽, 两个 USB 2.0 插槽, micro HDMI 输出, 千兆以太网, micro-SD 卡插槽, 802.11ac WiFi 以及其他现代单板计算机的标准配置
据推测, Canonical 将专注于 Ubuntu 24.04 LTS 作为其 RISC-V 移植到 EBC77 SBC 的版本
值得注意的是, 这款 ESWIN SoC 采用了 RV64GC/RVA20 配置的 RISC-V 内核
Canonical 此前宣布, 自 Ubuntu 25.10 起, 他们将 RISC-V 基线提升至 RVA23
假设 RVA23 基线计划不变, 这款新发布的, 支持 Ubuntu 的 RISC-V 单板计算机将仅限于 Ubuntu 25.04 及更早版本 (或 Ubuntu 24.04 LTS 以获得长期支持)
Canonical 关于 EBC77 支持 Ubuntu RISC-V 的公告可在其博客上找到
这款最新的 RISC-V 单板计算机的定价尚不明确, 因为它刚刚发布, 而亚马逊预购页面仅显示 "目前无货", 没有标明价格
#Ubuntu
原文链接
Canonical 今天宣布与 ESWIN Computing 合作, 将 Ubuntu Linux 作为其 ESWIN Computing EBC77 系列单板计算机的首选操作系统出货
基于 RISC-V 的 ESWIN Computing EBC77 采用了 ESWIN EIC7700X SoC, 提供四个 1.8GHz 的内核和一个自研的额定 20 TOPS 的 NPU, Imagination PowerVR 图形以及 LPDDR5-6400 内存支持
鉴于其自研的神经网络处理单元 (NPU), 该 NPU 何时能得到上游/主线内核版本的支持, 可能还需要一段时间
截至目前, 我尚未看到任何为在主线上启用此 NPU 而提交的 Linux 内核补丁
ESWIN EBC77 还配备了一个 4 通道 PCIe Gen3 FPC 插槽, 两个 USB 3.2 Gen1 插槽, 两个 USB 2.0 插槽, micro HDMI 输出, 千兆以太网, micro-SD 卡插槽, 802.11ac WiFi 以及其他现代单板计算机的标准配置
据推测, Canonical 将专注于 Ubuntu 24.04 LTS 作为其 RISC-V 移植到 EBC77 SBC 的版本
值得注意的是, 这款 ESWIN SoC 采用了 RV64GC/RVA20 配置的 RISC-V 内核
Canonical 此前宣布, 自 Ubuntu 25.10 起, 他们将 RISC-V 基线提升至 RVA23
假设 RVA23 基线计划不变, 这款新发布的, 支持 Ubuntu 的 RISC-V 单板计算机将仅限于 Ubuntu 25.04 及更早版本 (或 Ubuntu 24.04 LTS 以获得长期支持)
Canonical 关于 EBC77 支持 Ubuntu RISC-V 的公告可在其博客上找到
这款最新的 RISC-V 单板计算机的定价尚不明确, 因为它刚刚发布, 而亚马逊预购页面仅显示 "目前无货", 没有标明价格
#Ubuntu
原文链接
❤1
LLVM 22 停止对 Google 原生客户端 "NaCl" 的最终支持
LLVM 22 编译器堆栈目前正在开发中, 其早期变化之一是彻底移除对 Google Native Client "NaCl" 的支持
Google Native Client 沙盒技术在最初构想时很有趣, 但多年来, WebAssembly (WASM) 在网络浏览器中运行原生代码方面一直更胜一筹
Google 在 2022 年逐步淘汰了其官方 Native Client 支持, 而现在到 2025 年, LLVM 编译器堆栈正在移除其构建任何新的 NaCl/PNaCl 二进制文件的支持
这个合并请求彻底移除了 LLVM 中对 Native Client 的支持
最初, 该合并请求在今年早些时候就被提出, 但 Google 要求推迟几个月, 以便他们完成清除 Chromium 内部的支持代码残余
Chrome/Chromium 139 中清除了剩余的 Native Client 代码, 现在为 LLVM 22 中移除编译器支持打开了大门
该代码现已合并, 使 LLVM 编译器减少了 2.5k+ 行代码
#LLVM
原文链接
LLVM 22 编译器堆栈目前正在开发中, 其早期变化之一是彻底移除对 Google Native Client "NaCl" 的支持
Google Native Client 沙盒技术在最初构想时很有趣, 但多年来, WebAssembly (WASM) 在网络浏览器中运行原生代码方面一直更胜一筹
Google 在 2022 年逐步淘汰了其官方 Native Client 支持, 而现在到 2025 年, LLVM 编译器堆栈正在移除其构建任何新的 NaCl/PNaCl 二进制文件的支持
这个合并请求彻底移除了 LLVM 中对 Native Client 的支持
最初, 该合并请求在今年早些时候就被提出, 但 Google 要求推迟几个月, 以便他们完成清除 Chromium 内部的支持代码残余
Chrome/Chromium 139 中清除了剩余的 Native Client 代码, 现在为 LLVM 22 中移除编译器支持打开了大门
该代码现已合并, 使 LLVM 编译器减少了 2.5k+ 行代码
#LLVM
原文链接
❤2
更多 AMD FidelityFX Super Resolution 4 改进应用于开源驱动程序
在 Mesa 25.2 代码分支发布之前, 开源 OpenGL 和 Vulkan 驱动程序在本周非常繁忙
除了 RADV 光线追踪改进, Kepler GPU 的 Vulkan 1.2 一致性, 默认启用 Xe3 Panther Lake 显卡以及许多其他最后一刻的更改之外, 过去一周也一直在推动将更多 AMD FidelityFX Super Resolution 4 "FSR 4"改进合并到 Radeon RADV 驱动程序中
今天早上, Mesa Git 又迎来了一轮 FSR4 优化
此合并请求优化了 GFX11 矩阵使用转换, 以使 AMD RDNA3 (GFX11) 类 GPU 受益
没有提到任何最终用户受益的性能数据
在过去的几天里, 还对 RADV 的一些整数算术和带有标量条件代码的 BCSEL 进行了矢量化, 以帮助 FSR4 着色器
此外, 还为 AMD ACO 编译器添加了一个专用通道, 用于更好地插入浮点 MODE 以帮助 FSR4
以及 Mesa 25.2 之前几周的其他 FSR4 优化
FidelityFX Super Resolution 4 是 AMD 最新的游戏超采样和帧生成技术, 旨在帮助游戏
在 Linux 下, 主要受益于 Steam Play (Proton) 在 Linux 上运行 Windows 游戏的游戏体验
昨天开放了一个针对 GFX11 8 位 CMAT 加载优化的合并请求, 旨在帮助一些 FSR4 着色器, 尽管该代码尚未合并
另一个是这个针对 FSR4 的 ACO 优化
Valve 的 Linux 图形团队最近一直在围绕 FSR4 和光线追踪进行大量工作, 这是他们最近 RADV 驱动程序改进的一些共同主题
Mesa 25.2 代码分支最快今天就会发生, 所以我们将看看这个季度功能发布在最后一刻可能还会落地什么, 它将在 8 月稳定版发布之前经历几周的发布候选版本
#Mesa
原文链接
在 Mesa 25.2 代码分支发布之前, 开源 OpenGL 和 Vulkan 驱动程序在本周非常繁忙
除了 RADV 光线追踪改进, Kepler GPU 的 Vulkan 1.2 一致性, 默认启用 Xe3 Panther Lake 显卡以及许多其他最后一刻的更改之外, 过去一周也一直在推动将更多 AMD FidelityFX Super Resolution 4 "FSR 4"改进合并到 Radeon RADV 驱动程序中
今天早上, Mesa Git 又迎来了一轮 FSR4 优化
此合并请求优化了 GFX11 矩阵使用转换, 以使 AMD RDNA3 (GFX11) 类 GPU 受益
没有提到任何最终用户受益的性能数据
在过去的几天里, 还对 RADV 的一些整数算术和带有标量条件代码的 BCSEL 进行了矢量化, 以帮助 FSR4 着色器
此外, 还为 AMD ACO 编译器添加了一个专用通道, 用于更好地插入浮点 MODE 以帮助 FSR4
以及 Mesa 25.2 之前几周的其他 FSR4 优化
FidelityFX Super Resolution 4 是 AMD 最新的游戏超采样和帧生成技术, 旨在帮助游戏
在 Linux 下, 主要受益于 Steam Play (Proton) 在 Linux 上运行 Windows 游戏的游戏体验
昨天开放了一个针对 GFX11 8 位 CMAT 加载优化的合并请求, 旨在帮助一些 FSR4 着色器, 尽管该代码尚未合并
另一个是这个针对 FSR4 的 ACO 优化
Valve 的 Linux 图形团队最近一直在围绕 FSR4 和光线追踪进行大量工作, 这是他们最近 RADV 驱动程序改进的一些共同主题
Mesa 25.2 代码分支最快今天就会发生, 所以我们将看看这个季度功能发布在最后一刻可能还会落地什么, 它将在 8 月稳定版发布之前经历几周的发布候选版本
#Mesa
原文链接
12k 行 NVIDIA Blackwell 3D 类头文件开源
类似于 NVIDIA 之前为前代 GPU 开源的 3D 类头文件, 昨天 NVIDIA 采取了类似的开源举动, 发布了其最新 Blackwell 图形处理器的所有 3D 类头文件
这些都是与 Blackwell GPU 3D 引擎编程相关的所有头文件, 对 NVK Mesa Vulkan 驱动等开源 Linux 驱动工作很有用
昨天 NVIDIA 开源 GPU 文档仓库的这次提交, 添加了 Blackwell A 和 Blackwell B 硬件的所有 3D 类头文件
所有这些头文件大约有 1.2 万行代码, 用于帮助他们的开源工作
同样, Mesa 也已将所有这些头文件导入到 Mesa 源代码仓库中, 供 Nouveau/NVK 驱动代码使用
此前, Linux 6.16 已在 Nouveau 内核图形驱动中提供初步的 Blackwell 支持, Mesa 25.2 也为 Blackwell 提供了初步的 NVK Vulkan 驱动支持, 预计很快会有更多改进
最初的 Nouveau 内核驱动补丁是由 NVIDIA 在支持 Hopper 的同时发布的
值得注意的是, Nouveau/NVK 的开发人员, 如 Red Hat 的开发人员, 最近似乎可以访问 NVIDIA 的 NDA 文档, 以帮助他们的开源驱动工作
昨天 Red Hat 的 David Airlie 对 Mesa Git 的这个补丁提到了 "来自 NVIDIA NDA 文档" 的一些值
NVIDIA 近年来增加了他们的开源贡献, 并为他们自己的开源驱动到上游的努力 (如 Nouveau/NOVA) 提供了更多帮助, 尽管看起来某些方面仍涉及保密协议文档以帮助早期硬件支持
#NVIDIA
原文链接
类似于 NVIDIA 之前为前代 GPU 开源的 3D 类头文件, 昨天 NVIDIA 采取了类似的开源举动, 发布了其最新 Blackwell 图形处理器的所有 3D 类头文件
这些都是与 Blackwell GPU 3D 引擎编程相关的所有头文件, 对 NVK Mesa Vulkan 驱动等开源 Linux 驱动工作很有用
昨天 NVIDIA 开源 GPU 文档仓库的这次提交, 添加了 Blackwell A 和 Blackwell B 硬件的所有 3D 类头文件
所有这些头文件大约有 1.2 万行代码, 用于帮助他们的开源工作
同样, Mesa 也已将所有这些头文件导入到 Mesa 源代码仓库中, 供 Nouveau/NVK 驱动代码使用
此前, Linux 6.16 已在 Nouveau 内核图形驱动中提供初步的 Blackwell 支持, Mesa 25.2 也为 Blackwell 提供了初步的 NVK Vulkan 驱动支持, 预计很快会有更多改进
最初的 Nouveau 内核驱动补丁是由 NVIDIA 在支持 Hopper 的同时发布的
值得注意的是, Nouveau/NVK 的开发人员, 如 Red Hat 的开发人员, 最近似乎可以访问 NVIDIA 的 NDA 文档, 以帮助他们的开源驱动工作
昨天 Red Hat 的 David Airlie 对 Mesa Git 的这个补丁提到了 "来自 NVIDIA NDA 文档" 的一些值
NVIDIA 近年来增加了他们的开源贡献, 并为他们自己的开源驱动到上游的努力 (如 Nouveau/NOVA) 提供了更多帮助, 尽管看起来某些方面仍涉及保密协议文档以帮助早期硬件支持
#NVIDIA
原文链接
Mesa 25.2-rc1 发布: 更快的 RADV 光线追踪, NVK Blackwell 及更多优化
Mesa 25.2 现已分支, 并因此进入功能冻结期, Mesa 25.2-rc1 也已发布
这标志着每周发布候选版本的开始, 直到 Mesa 25.2 稳定版本准备好在 8 月份的某个时候发布为止
Mesa 25.2 是一个特别令人兴奋的季度功能版本, 因为它包含了许多重大更改 - 特别是对于 Radeon RADV 和 RadeonSI 驱动程序, Intel ANV 和 Iris 驱动程序以及 NVIDIA NVK 驱动程序
Mesa 25.2 在 AMD 方面包括 RDNA3 和 RDNA4 光线追踪性能优化, 各种新的 Vulkan API 扩展, FSR 4 改进, RDNA 4 GPU 的 Vulkan Video 支持, 以及特别感谢 Valve / Red Hat / AMD 带来的各种其他性能优化和调整
在 Intel 方面, Xe3 Panther Lake 显卡现在被认为是稳定的, Vulkan Video 有所改进, Iris Gallium3D 驱动程序支持共享虚拟内存, 以及特别是针对 Xe2 和 Xe3 显卡硬件的各种其他改进
对于开源 NVIDIA Vulkan 支持的 NVK 驱动程序, Kepler GPU 符合 Vulkan 1.2 标准, 初步支持 NVIDIA Blackwell, 各种 NAK 编译器优化, Maxwell GPU 符合 Vulkan 1.4 标准, 以及各种其他改进
此外, 还有各种其他新的 OpenGL 和 Vulkan 扩展连接到不同的驱动程序, PanVK 驱动程序的 Vulkan 1.4, 移除了 X11 DRI2 支持, 放弃了 DMA-BUF 之前的 wl_drm Wayland 支持, Rusticl 支持 OpenCL 2.0 粗粒度缓冲区 SVM, 以及许多其他更改, 同时淘汰了旧的 Clover 驱动程序
Mesa 25.2-rc1 的简短发布公告可在 Mesa 邮件列表中阅读
#Mesa
原文链接
Mesa 25.2 现已分支, 并因此进入功能冻结期, Mesa 25.2-rc1 也已发布
这标志着每周发布候选版本的开始, 直到 Mesa 25.2 稳定版本准备好在 8 月份的某个时候发布为止
Mesa 25.2 是一个特别令人兴奋的季度功能版本, 因为它包含了许多重大更改 - 特别是对于 Radeon RADV 和 RadeonSI 驱动程序, Intel ANV 和 Iris 驱动程序以及 NVIDIA NVK 驱动程序
Mesa 25.2 在 AMD 方面包括 RDNA3 和 RDNA4 光线追踪性能优化, 各种新的 Vulkan API 扩展, FSR 4 改进, RDNA 4 GPU 的 Vulkan Video 支持, 以及特别感谢 Valve / Red Hat / AMD 带来的各种其他性能优化和调整
在 Intel 方面, Xe3 Panther Lake 显卡现在被认为是稳定的, Vulkan Video 有所改进, Iris Gallium3D 驱动程序支持共享虚拟内存, 以及特别是针对 Xe2 和 Xe3 显卡硬件的各种其他改进
对于开源 NVIDIA Vulkan 支持的 NVK 驱动程序, Kepler GPU 符合 Vulkan 1.2 标准, 初步支持 NVIDIA Blackwell, 各种 NAK 编译器优化, Maxwell GPU 符合 Vulkan 1.4 标准, 以及各种其他改进
此外, 还有各种其他新的 OpenGL 和 Vulkan 扩展连接到不同的驱动程序, PanVK 驱动程序的 Vulkan 1.4, 移除了 X11 DRI2 支持, 放弃了 DMA-BUF 之前的 wl_drm Wayland 支持, Rusticl 支持 OpenCL 2.0 粗粒度缓冲区 SVM, 以及许多其他更改, 同时淘汰了旧的 Clover 驱动程序
Mesa 25.2-rc1 的简短发布公告可在 Mesa 邮件列表中阅读
#Mesa
原文链接
❤1
Mesa 25.1.6 发布: 默认启用 Intel Xe3 Panther Lake 显卡
除了发布 Mesa 25.2-rc1 及其众多新功能供测试外, Mesa 发布经理 Eric Engestrom 今天还发布了 Mesa 25.1.6, 作为上季度系列的最新双周稳定版点发布
Mesa 25.1.6 收集了最新的向后移植修复, 而 Mesa 25.2.0 正在努力发布, 大约在 8 月中旬, 具体取决于每周发布候选版本的进展
Mesa 25.1.6 值得注意的是, 它向后移植了默认启用 Intel Xe3 集成显卡以支持即将推出的 Panther Lake SoC 的更改
很高兴看到 Intel Panther Lake 的支持在未来几个月内下一代笔记本电脑上市之前得到全面解决
Mesa 25.1.6 的一些亮点包括:
更多详情请参阅今天的 25.1.6 发布公告
#Mesa
原文链接
除了发布 Mesa 25.2-rc1 及其众多新功能供测试外, Mesa 发布经理 Eric Engestrom 今天还发布了 Mesa 25.1.6, 作为上季度系列的最新双周稳定版点发布
Mesa 25.1.6 收集了最新的向后移植修复, 而 Mesa 25.2.0 正在努力发布, 大约在 8 月中旬, 具体取决于每周发布候选版本的进展
Mesa 25.1.6 值得注意的是, 它向后移植了默认启用 Intel Xe3 集成显卡以支持即将推出的 Panther Lake SoC 的更改
很高兴看到 Intel Panther Lake 的支持在未来几个月内下一代笔记本电脑上市之前得到全面解决
Mesa 25.1.6 的一些亮点包括:
- Intel ANV 和 Iris 图形驱动程序默认将 Xe3 Panther Lake 集成显卡视为已启用
Panther Lake 的 OpenGL 和 Vulkan 支持现在在 Mesa 25.1.6+或 Mesa 25.2+中状况良好
您还需要使用 Linux 6.17+内核, 以便通过 Xe 内核图形驱动程序获得开箱即用的支持
- 修复了 GFX12.5+硬件上使用 Intel ANV 驱动程序的 Vulkan Video 中 H.265 和 VP9 视频内容的平铺问题
- Intel ANV 驱动程序现在将 Gen11+硬件上的最大顶点缓冲区数量增加到 33 个
- 各种 Zink OpenGL-on-Vulkan 驱动程序修复
- 多个 Radeon RADV Vulkan 驱动程序修复, 包括 GFX12 (RDNA4) 的修复, GFX10 到 GFX11.5 (RDNA 1 到 RDNA 3.5) 的解决方法, 以及其他修复
- 针对 Team Fortress 2 游戏的传统 OpenGL 的解决方法
- 各种其他错误修复
更多详情请参阅今天的 25.1.6 发布公告
#Mesa
原文链接
Linux 6.17 将修复 AMDGPU 唤醒功能, 使其在大型 GPU 服务器上不再耗时约 50 分钟
在 Linux 6.16 周期的后期, 并赶在 Linux 6.17 新 DRM 驱动程序功能材料排队期结束的截止日期前, 今天又发出了一个额外的 drm-misc-next 拉取请求, 其中包含针对下一个内核周期的一些最后一刻的内核图形驱动程序更改
推动这次额外拉取的是最近的 AMDGPU 系统休眠补丁
今天 drm-misc-next 拉取请求的头条变化是整合了 AMD 补丁, 以减少大型 AI/GPU 服务器休眠时的系统内存需求
这些补丁和问题之前已在 Phoronix 上报道过, 内容是 AMD Instinct 加速器如此大的 vRAM 暴露了 Linux 休眠问题
最新的 AMD Instinct 加速器能够看到 192GB 的设备内存, 并且每台服务器最多有八个, 所有这些设备内存都在休眠期间给 AMDGPU 驱动程序带来了问题
在某些情况下, 它会导致在创建休眠映像时没有足够的可用系统内存, 即使成功了, 由于所有缓冲区对象的归档和恢复, 也会花费很长时间
除了系统内存不足可能导致休眠失败之外, 当一切顺利时, 它也会花费很长时间:
在一台配置齐全的 AMD Instinct 加速器服务器上, 这些补丁可以节省近一个小时
这些用于彻底改进 AMDGPU 休眠处理的补丁是今天 drm-misc-next 拉取请求的一部分, 也是推动这次额外拉取的原因
此拉取请求中还包含针对 Linux 6.17 的一些内存泄漏修复, Nouveau 驱动程序的调度程序改进, Sitronix ST7567 支持, BOE NE14QDM 面板支持以及其他最后一刻的更改
#AMD
原文链接
在 Linux 6.16 周期的后期, 并赶在 Linux 6.17 新 DRM 驱动程序功能材料排队期结束的截止日期前, 今天又发出了一个额外的 drm-misc-next 拉取请求, 其中包含针对下一个内核周期的一些最后一刻的内核图形驱动程序更改
推动这次额外拉取的是最近的 AMDGPU 系统休眠补丁
今天 drm-misc-next 拉取请求的头条变化是整合了 AMD 补丁, 以减少大型 AI/GPU 服务器休眠时的系统内存需求
这些补丁和问题之前已在 Phoronix 上报道过, 内容是 AMD Instinct 加速器如此大的 vRAM 暴露了 Linux 休眠问题
最新的 AMD Instinct 加速器能够看到 192GB 的设备内存, 并且每台服务器最多有八个, 所有这些设备内存都在休眠期间给 AMDGPU 驱动程序带来了问题
在某些情况下, 它会导致在创建休眠映像时没有足够的可用系统内存, 即使成功了, 由于所有缓冲区对象的归档和恢复, 也会花费很长时间
除了系统内存不足可能导致休眠失败之外, 当一切顺利时, 它也会花费很长时间:
对于正常休眠, GPU 不需要在解冻时恢复, 因为它不参与写入休眠映像
在这种情况下跳过恢复可以减少休眠时间
在具有 8 * 192GB VRAM dGPU, 98% VRAM 使用率和 1.7TB 系统内存的 VM 上, 这可以节省 50 分钟
在一台配置齐全的 AMD Instinct 加速器服务器上, 这些补丁可以节省近一个小时
这些用于彻底改进 AMDGPU 休眠处理的补丁是今天 drm-misc-next 拉取请求的一部分, 也是推动这次额外拉取的原因
此拉取请求中还包含针对 Linux 6.17 的一些内存泄漏修复, Nouveau 驱动程序的调度程序改进, Sitronix ST7567 支持, BOE NE14QDM 面板支持以及其他最后一刻的更改
#AMD
原文链接
Linux 6.17 将为十年前的 Marvell PXA1908 SoC 提供上游支持
Marvell PXA1908 SoC 于 2014 年推出, 专为 4G LTE 智能手机设计, 配备四个 Arm Cortex-A53 核心
以当时的标准来看, 它的性能并不算太出色, 如今更是如此
尽管在十年间没有看到主线 Linux 内核支持, 并且一些供应商内核停留在 Linux 3.14 时代, 但即将到来的 Linux 6.17 周期有望为主线添加对这款旧智能手机 SoC 的支持
在 Linux 6.17 内核合并窗口之前, 已经排队实现了对 Marvell PXA1908 SoC 的初步支持, 并随之启用了 Samsung Core Prime Velte, 它是少数使用 PXA1908 的智能手机之一
Marvell ARMADA Mobile PXA1908 的四个 Cortex A53 核心主频高达 1.5GHz, 整体性能远低于 ARMADA PXA1936
早在 2017 年就曾尝试将 Marvell PXA1908 的支持提交到主线, 但并未成功, 之后公开可用的供应商内核源代码也早已过时
无论如何, 如果有人碰巧拥有 PXA1908 设备, 现在其支持已在 Linux 6.17 周期之前排入 soc.git 的 for-next 分支
#Hardware
原文链接
Marvell PXA1908 SoC 于 2014 年推出, 专为 4G LTE 智能手机设计, 配备四个 Arm Cortex-A53 核心
以当时的标准来看, 它的性能并不算太出色, 如今更是如此
尽管在十年间没有看到主线 Linux 内核支持, 并且一些供应商内核停留在 Linux 3.14 时代, 但即将到来的 Linux 6.17 周期有望为主线添加对这款旧智能手机 SoC 的支持
在 Linux 6.17 内核合并窗口之前, 已经排队实现了对 Marvell PXA1908 SoC 的初步支持, 并随之启用了 Samsung Core Prime Velte, 它是少数使用 PXA1908 的智能手机之一
Marvell ARMADA Mobile PXA1908 的四个 Cortex A53 核心主频高达 1.5GHz, 整体性能远低于 ARMADA PXA1936
早在 2017 年就曾尝试将 Marvell PXA1908 的支持提交到主线, 但并未成功, 之后公开可用的供应商内核源代码也早已过时
无论如何, 如果有人碰巧拥有 PXA1908 设备, 现在其支持已在 Linux 6.17 周期之前排入 soc.git 的 for-next 分支
#Hardware
原文链接
单运行队列代理执行似乎已准备好用于 Linux 6.17
Linux 内核中长期开发的代理执行工作似乎已为即将到来的 Linux 6.17 合并窗口做好准备, Single RunQueue Proxy Execution 补丁经过 19 轮补丁审查/修订后已排入 TIP 分支
Google 的 John Stultz 一直致力于代理执行, 将其作为一种内核机制, 用于让拥有互斥锁的任务继承更高优先级等待者的调度上下文
Google 一直寻求通过这种方式实现优先级继承的代理执行, 以用于 Android, 从而改善某些工作负载的延迟, 并通过避免优先级反转实现更确定的延迟
致力于 Single RunQueue Proxy Execution 的 v19 补丁系列已排入 TIP.git 的 "sched/core" 分支
现在, 它已达到进入 sched/core 的里程碑, 很可能会在即将到来的 Linux 6.17 合并窗口中提交
除非 Linus Torvalds 在最后一刻提出任何问题或异议, 否则此代理执行支持应在 Linux 6.17 中首次亮相
代理执行功能由 "SCHED_PROXY_EXEC" Kconfig 开关控制, 然后在启动时通过内核参数 "sched_proxy_exec=" 启用/禁用代理执行支持
#LinuxKernel
原文链接
Linux 内核中长期开发的代理执行工作似乎已为即将到来的 Linux 6.17 合并窗口做好准备, Single RunQueue Proxy Execution 补丁经过 19 轮补丁审查/修订后已排入 TIP 分支
Google 的 John Stultz 一直致力于代理执行, 将其作为一种内核机制, 用于让拥有互斥锁的任务继承更高优先级等待者的调度上下文
Google 一直寻求通过这种方式实现优先级继承的代理执行, 以用于 Android, 从而改善某些工作负载的延迟, 并通过避免优先级反转实现更确定的延迟
致力于 Single RunQueue Proxy Execution 的 v19 补丁系列已排入 TIP.git 的 "sched/core" 分支
现在, 它已达到进入 sched/core 的里程碑, 很可能会在即将到来的 Linux 6.17 合并窗口中提交
除非 Linus Torvalds 在最后一刻提出任何问题或异议, 否则此代理执行支持应在 Linux 6.17 中首次亮相
代理执行功能由 "SCHED_PROXY_EXEC" Kconfig 开关控制, 然后在启动时通过内核参数 "sched_proxy_exec=" 启用/禁用代理执行支持
#LinuxKernel
原文链接
Google 继续开发 "Magma" 用于 Mesa 跨平台系统调用接口
Mesa 25.2 昨日进入功能冻结阶段, 带来了许多令人兴奋的驱动改进, 包括新功能和性能优化, 但 Magma 这一功能尚未准备好在本季度的发布中合并, 它是 Google 工程师最近致力于为 Mesa 开发的跨平台系统调用接口, 并且是用 Rust 编写的
Magma 是 Mesa 中一个跨平台的 GPU 系统调用库
Google 工程师一直在开发它, 着眼于 Chrome OS 的使用, 以及未来可能与他们的 Fuchsia 操作系统一起使用
更有趣的是, 它还计划与 Microsoft 的 Windows 显示驱动程序模型 (WDDM) 结合, 用于 Windows
这个跨平台 GPU 系统调用库将与 Linux DRM, Windows WDDM, Fuchsia 以及可能其他平台进行接口
Magma 是用 Rust 编程语言编写的, 早期目标之一是将其用于 Linux 和 Fuchsia 的半虚拟化用例
Google 对其在虚拟化图形方面的使用有相当宏伟的目标:
Magma 也可能最终有助于将更多 Mesa 硬件驱动程序引入 Windows 的工作
Magma 尚未准备好合并到 Mesa 25.2 中, 但仍在积极开发中
截至上个月, 该代码仍被认为是正在进行中的工作, 并且正在解决各种 Rust 特性
想要了解更多关于 Magma 的人可以通过 Mesa 的此 RFC WIP 合并请求进行了解
#Mesa
原文链接
Mesa 25.2 昨日进入功能冻结阶段, 带来了许多令人兴奋的驱动改进, 包括新功能和性能优化, 但 Magma 这一功能尚未准备好在本季度的发布中合并, 它是 Google 工程师最近致力于为 Mesa 开发的跨平台系统调用接口, 并且是用 Rust 编写的
Magma 是 Mesa 中一个跨平台的 GPU 系统调用库
Google 工程师一直在开发它, 着眼于 Chrome OS 的使用, 以及未来可能与他们的 Fuchsia 操作系统一起使用
更有趣的是, 它还计划与 Microsoft 的 Windows 显示驱动程序模型 (WDDM) 结合, 用于 Windows
这个跨平台 GPU 系统调用库将与 Linux DRM, Windows WDDM, Fuchsia 以及可能其他平台进行接口
Magma 是用 Rust 编程语言编写的, 早期目标之一是将其用于 Linux 和 Fuchsia 的半虚拟化用例
Google 对其在虚拟化图形方面的使用有相当宏伟的目标:
对于嵌入式 GPU 半虚拟化, 我们的目标是在主机用户空间虚拟机管理器 (VMM) 级别实现 100% 基于 Rust 的解决方案
我们一直在通过 Rutabaga 努力实现这一目标
Xen 的开发者也对此目标表示了兴趣
使用 virglrenderer 和 gfxstream 都会阻碍这一点, 因为它们都依赖于许多全局数据实例
这使得当这些功能启用时, Rutabaga 无法在不同线程之间安全地共享
Magma 也可能最终有助于将更多 Mesa 硬件驱动程序引入 Windows 的工作
Magma 尚未准备好合并到 Mesa 25.2 中, 但仍在积极开发中
截至上个月, 该代码仍被认为是正在进行中的工作, 并且正在解决各种 Rust 特性
想要了解更多关于 Magma 的人可以通过 Mesa 的此 RFC WIP 合并请求进行了解
#Mesa
原文链接
新的 FFmpeg AVX-512 优化性能最高可达普通 C 代码的 36 倍
今天合并到 FFmpeg Git 的一些提交为支持 AVX-512 的 Intel 和 AMD 处理器提供了额外的手动优化汇编代码
开源多媒体开发者 Niklas Haas 今天向 FFmpeg 上游提交了一些额外的 AVX2 和 AVX-512 优化, 这是在该多媒体库已有的用于利用高级矢量扩展的大量手动优化代码基础之上的
根据 Niklas Haas 运行的基准测试, FFmpeg 的 avfilter scene_sad 代码现在添加了 AVX-512 实现, 其速度是普通 C 代码的 36.31 倍
此前已有一个 AVX2 路径, 其性能是普通 C 代码的 25 倍, 但现在使用 AVX-512 后, 性能超过 36 倍
另一个提交添加了 scene_sad avfilter 代码的高位深 AVX2 和 AVX-512 版本
相对于普通 C 代码, 性能提升了大约 11 倍, 或者在使用 AVX-512 时大约提升了 22 倍
AVX-512 继续带来显著效益, 尤其是在最新的 AMD Zen 4 / Zen 5 和近期 Intel Xeon 处理器上
#Multimedia
原文链接
今天合并到 FFmpeg Git 的一些提交为支持 AVX-512 的 Intel 和 AMD 处理器提供了额外的手动优化汇编代码
开源多媒体开发者 Niklas Haas 今天向 FFmpeg 上游提交了一些额外的 AVX2 和 AVX-512 优化, 这是在该多媒体库已有的用于利用高级矢量扩展的大量手动优化代码基础之上的
根据 Niklas Haas 运行的基准测试, FFmpeg 的 avfilter scene_sad 代码现在添加了 AVX-512 实现, 其速度是普通 C 代码的 36.31 倍
此前已有一个 AVX2 路径, 其性能是普通 C 代码的 25 倍, 但现在使用 AVX-512 后, 性能超过 36 倍
另一个提交添加了 scene_sad avfilter 代码的高位深 AVX2 和 AVX-512 版本
相对于普通 C 代码, 性能提升了大约 11 倍, 或者在使用 AVX-512 时大约提升了 22 倍
AVX-512 继续带来显著效益, 尤其是在最新的 AMD Zen 4 / Zen 5 和近期 Intel Xeon 处理器上
#Multimedia
原文链接
Linux 接收针对 AMD Radeon Polaris 显卡产生大量日志垃圾的修复
对于那些在 Linux 上使用 AMD Radeon RX 500 "Polaris" 显卡并经常暂停/恢复系统的用户, Linux 6.16 内核中将有一个修复, 并会回溯到稳定版本, 该修复解决了 AMDGPU 驱动程序可能在内核日志中产生大量垃圾信息的问题
今天发布的是本周的 drm-fixes-6.16, 用于 Radeon 和 AMDGPU 开源内核图形驱动程序
其中包括 DC 显示代码中的内存泄漏修复, DCN 4.0.1 degamma LUT 修复, 修复软恢复时的重置计数器处理, 以及一个引起我注意的 GFX8 (Polaris) 修复, 因为 AMD 针对老化的 GFX9 之前的硬件很少有新的提交
这个修复是针对这个 5 个月前关于系统从睡眠中唤醒后出现大量 "日志垃圾信息" 的错误报告
报告者 DeKay 解释说:
其他在 Linux 上使用 AMD Radeon RX 500 "Polaris" 显卡的用户也报告了类似的问题, 即系统唤醒/恢复后, 他们的内核日志会被无数关于 "scheduler comp_1.0.X is not ready, skipping" 的消息淹没
经过数月用户在 Linux 下使用 Polaris GPU 遇到此问题以及 AMD 努力分析和调试问题后, 该修复现在已准备好首先进入 Linux 6.16, 并将在未来几天回溯到受支持的稳定内核系列
只需要一行代码即可在恢复时重置 GPU 上的计算环 wptr, 以避免驱动程序和固件指针之间的断开连接
此外, 关于旧硬件修复, 今天的拉取请求还在暂停/恢复时为主要由 GCN 之前的硬件使用的 Radeon DRM 驱动程序取消了控制台锁
这修复了 Radeon 与另一个 DRM 驱动程序一起使用时的循环依赖问题
#Radeon
原文链接
对于那些在 Linux 上使用 AMD Radeon RX 500 "Polaris" 显卡并经常暂停/恢复系统的用户, Linux 6.16 内核中将有一个修复, 并会回溯到稳定版本, 该修复解决了 AMDGPU 驱动程序可能在内核日志中产生大量垃圾信息的问题
今天发布的是本周的 drm-fixes-6.16, 用于 Radeon 和 AMDGPU 开源内核图形驱动程序
其中包括 DC 显示代码中的内存泄漏修复, DCN 4.0.1 degamma LUT 修复, 修复软恢复时的重置计数器处理, 以及一个引起我注意的 GFX8 (Polaris) 修复, 因为 AMD 针对老化的 GFX9 之前的硬件很少有新的提交
这个修复是针对这个 5 个月前关于系统从睡眠中唤醒后出现大量 "日志垃圾信息" 的错误报告
报告者 DeKay 解释说:
从睡眠中醒来后, 我会在 journalctl 和 dmesg 中看到数千行这样的信息, 以至于更早的 dmesg 启动事件都会丢失
我的 GPU 是 AMD RX560, 运行在 Arch Linux 内核 6.12.10-arch1-1 和 KDE 下
其他在 Linux 上使用 AMD Radeon RX 500 "Polaris" 显卡的用户也报告了类似的问题, 即系统唤醒/恢复后, 他们的内核日志会被无数关于 "scheduler comp_1.0.X is not ready, skipping" 的消息淹没
经过数月用户在 Linux 下使用 Polaris GPU 遇到此问题以及 AMD 努力分析和调试问题后, 该修复现在已准备好首先进入 Linux 6.16, 并将在未来几天回溯到受支持的稳定内核系列
只需要一行代码即可在恢复时重置 GPU 上的计算环 wptr, 以避免驱动程序和固件指针之间的断开连接
此外, 关于旧硬件修复, 今天的拉取请求还在暂停/恢复时为主要由 GCN 之前的硬件使用的 Radeon DRM 驱动程序取消了控制台锁
这修复了 Radeon 与另一个 DRM 驱动程序一起使用时的循环依赖问题
#Radeon
原文链接
❤1