Segfault ?

下面的程序会段错误吗？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#include <stdio.h>

struct bar {
    int a;
};

struct foo {
    struct bar b;
};

void func(struct foo *pf)
{
    printf("%p\n", &pf->b);
}

int main(int argc, char *argv[])
{
    struct foo *f = NULL;

    printf("%p\n", &f->b);

    func(f);
}

Introduction

driconf 是一个基于 XML 的 DRI 驱动配置机制，它同时提供系统范围的和每用户的配置方式 (如果同时存在，后者覆盖前者)。driconf 提供统一的配置格式，并整理出驱动常见的配置选项，方便易用。 driconf 不仅可以针对指定设备，指定 screen, 指定驱动设置选项，而且可以针对每个应用设置选项。

Edge 函数定义

• $E_{01}(P) > 0$ 当 $P$ 在 $\overrightharpoon{V_0V_1}$ 的右边
• $E_{01}(P) = 0$ 当 $P$ 在 $\overrightharpoon{V_0V_1}$ 的边上
• $E_{01}(P) < 0$ 当 $P$ 在 $\overrightharpoon{V_0V_1}$ 的左边

更好记的形式: $\lVert \overrightharpoon{V_1V_0} \times \overrightharpoon{PV_0} \rVert$

XCB 是应用与 X 服务器交互使用的 C 绑定函数集，它里面的一些 C 函数是通过 python3-xcbgen 工具生成的，不经过编译在它的源码库是找不到的。而且 XCB 古老到仍然使用 autotools 那套构建系统，想要看到某些函数的“真容”，你还得“千呼万唤”。

Vulkan 是一个低开销、跨平台的二维和三维图形与计算的应用程序接口，由 Khronos 在2015年在 GDC 上首次发布。它旨在提供高效能和更均衡的 CPU 和 GPU 占用，类似于 Direct3D 12 和 AMD Mantle。

本文主要记录一下在 llvmpipe 软渲染 Vulkan 驱动下， 一个 vulkan 应用程序 (demo) 的执行过程。

Just read it

gallium/dril: Compatibility stub for the legacy DRI loader interface

Linux 计算加速器子系统旨在以通用的方式向用户空间开放计算加速器的接口。这些计算加速器可以是独立的 ASIC, 也可以是 SoC/GPU 内的 IP 块。通常计算加速器包括以下几种类型:

• 边缘 AI - 在边缘设备上进行推理计算
• 推理数据中心 - 大型服务器中的单用户/多用户设备
• 训练数据中心 - 类似于推理数据中心卡，但通常具有更强的计算能力和更高的存储带宽

高端硅片可以构建市场，但最终，软件支持往往决定了赢家和输家

        -- Jack Huynh, AMD 高级副总裁兼计算和图形业务集团总经理

AMD 的通用计算平台 ROCm (Radeon Open Compute) 是在通用计算领域与 NVIDIA 的 CUDA （Compute Unified Device Architecture) 相抗衡的软件基础设施。ROCm 实现的其实是由 AMD 发起的 HSA (Heterogeneous System Architecture) 标准，所以它的运行时主要由 3 个部分组成:

OOC: ROCm 平台又叫 Boltzmann 平台，原因据说是为了纪念统计力学和热力学领域著名物理学家路德维希·玻尔兹曼，他的工作对理解物质的微观行为和能量分布有着深远的影响。AMD 选取这个名字，可能是为了强调该平台在高性能计算领域的强大计算力和科学计算的应用前景。

AMD 在 Linux 下维护着两套开源 Vulkan 驱动:

• AMDVLK
  • 从闭源 Windows Vulkan 驱动适配而来，主要不同在 shader 编译后端, AMDVLK 使用基于 LLVM 的 LLPC
• RADV
  • 是 Mesa 项目的一部分，主要由社区驱动。使用的 shader 编译后端是基于 NIR 的 ACO (AMD COmpiler)

这里主要是记录一下两者的异同点，学习两者不同的设计策略及其作出选择的背后理念。