当前位置：首页 > news >正文

自由学习记录（107）

news 2025/10/19 12:57:51

.sln 文件本身不是可执行程序，而是 Visual Studio 的解决方案文件（solution file）。之所以“直接打开就能运行”，是因为：

1. `.sln` 的作用

它记录了：

项目结构（多个 .vcxproj 工程）
源码路径
编译目标（Debug/Release）
使用的编译器（MSVC + NVCC）
输出路径

Visual Studio 读取 .sln 后，会自动调用内部构建系统（MSBuild）与 CUDA 插件执行完整的编译→链接→运行过程。

不是“不好”，而是Windows 选择稳定与安全优先的设计取向。
Linux/macOS 依赖软链接和动态库路径更灵活；
Windows 依赖注册表与固定路径更可控。
它是一种有意限制换取可预测性的工程取舍。

🧩 为什么全局维护困难

实时跟踪意味着：

操作系统要维护一个路径映射数据库（类似 Linux 的 inode，但跨卷、跨权限）；
每个文件移动都触发系统级事件 → 成本高；
必须验证权限、防止欺骗（例如恶意程序把注册表路径指向自己）。

这会让整个 I/O 子系统更复杂、更慢。

你的直觉正确。严格来说，这种“静态注册表”设计不是坏事，而是权衡后的优点。

✅ 优点

性能稳定
注册表只在读取时访问，不维护文件系统事件监听，不会拖慢系统。
确定性强
所有程序路径、版本信息固定，系统和第三方工具可以稳定查找依赖。
安全性更高
不允许自动跟踪文件移动，能防止恶意软件伪装或劫持合法程序路径。
可控更新机制
软件安装、更新、卸载都有明确入口（MSI、Setup），系统可验证来源。

⚠️ 缺点

灵活性差
软件移动后要重新安装或手动修复注册表。
系统耦合度高
一旦注册表损坏或清理错误，很多程序会直接无法启动。
跨设备移植困难
拷贝整个文件夹到另一台机器通常无法运行。

如果操作系统提供了注册表实时路径更新功能，那么：

软件可以被任意移动；
系统必须维护全局文件映射表；
性能与安全复杂度都会显著增加。

因此 Windows 选择了固定安装路径 + 注册表静态映射的架构。

为什么注册表不会“实时改变”

Windows 注册表不是文件系统索引，而是静态键值数据库。它不会监控磁盘文件移动，因为：

路径只是普通字符串，没有文件句柄绑定；
监控所有文件系统变化成本极高；
设计目标是“配置中心”，不是“动态文件跟踪器”。

在 Visual Studio Installer 的“安装详细信息”里：

如果你的系统是 Windows 11，只要勾选带有 Windows 11 SDK (10.x.x.x) 的那一项即可。
如果你打算兼容更老版本（比如未来项目要在 Windows 10 机器上编译），可以 额外勾选 Windows 10 SDK (10.0.19041.0)。

CUDA 编译器（nvcc）调用 cl.exe 时只要求系统有任意一个有效的 Windows SDK，用于链接头文件和库，不要求两者同时存在。

也就是说如果我修改了vs的安装路径，然后启动cuda的时候说找不到cl.exe，这个问题不是出在注册表上或者系统变量上，因为默认就是通过注册表查询的，和环境变量没有关系，我需要检查的是安装的c++sdk需要是windows11适配到自己的电脑

自动写入键，如果安装vs的时候自定义安装路径，那这个键的写入是否收到影响

ChatGPT said:

会写入，不受影响。

解释：
Visual Studio 安装程序（vs_installer.exe）无论你选默认路径还是自定义路径，都会自动写入正确的实际安装目录到注册表键：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7

键名是版本号（如 17.0），键值就是你选的路径，例如：

"D:\Dev\VS2022\" = "17.0"

因此：

CUDA 安装器、CMake、Intel oneAPI 等都能从注册表准确找到位置。
无需你手动改或创建环境变量。
只有在你强行复制移动整个 VS 文件夹（不是用安装器）时，注册表不会更新，这种情况下 CUDA 就会找不到 VS。

对比总结

项目	环境变量	注册表
修改权限	用户级 / 进程级	管理员级
作用范围	临时、运行时	永久、系统级
信息结构	扁平文本键值	层级树状结构（可序列化）
安全性	低	高
用途	路径、选项	版本、安装信息、许可、驱动、服务

UDA 为什么读注册表

NVIDIA 遵循微软的 SDK 集成规范：Visual Studio 安装时自动写入键

HKLM\SOFTWARE\Microsoft\VisualStudio\SxS\VS7

任何需要与 VS 集成的外部工具（如 CUDA、Intel OneAPI、CMake、Qt）都用它来定位编译器路径。
这样不依赖用户环境变量，不必猜测 VS 安装在什么盘。

目的不同

环境变量：存放临时或轻量级路径信息（如 PATH、CUDA_PATH），由用户或进程修改。
注册表：Windows 内核级配置数据库，用于系统与第三方软件统一查询“安装状态、版本、路径、许可信息”等。

注册表是 Windows 的“中央索引”。
→ 当 CUDA 安装器运行时，它需要可靠地找到系统里是否存在 VS，以及版本号。
→ 环境变量可能不存在或被多用户篡改；注册表写入需要管理员权限，更安全、可追踪。

CUDA 编译时 nvcc 使用的 MSVC 路径

nvcc 在调用 cl.exe（MSVC 编译器）时，会读取环境变量：

VSINSTALLDIR VCINSTALLDIR

如果你希望 nvcc 使用特定版本的编译器，可以在命令行临时设置：

set VSINSTALLDIR=D:\CustomVS2022\

set VCINSTALLDIR=D:\CustomVS2022\VC\

或写入批处理脚本（例如 build.bat）中。

CUDA → Visual Studio 检测路径

安装时 CUDA 安装器会在注册表中读取以下键值：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7

其中键名是版本号（如 17.0 对应 VS2022），键值是安装路径，例如：

C:\Program Files\Microsoft Visual Studio\2022\Community\

要改识别路径，可以修改这一项让 CUDA 安装器找到自定义 VS 目录。

不建议改动，除非你是把 VS 安装在非系统盘或用便携式构建。

Windows（命令提示符 / PowerShell）

nvidia-smi

输出包括：

GPU 名称（如 RTX 4070）
驱动版本（Driver Version）
CUDA Version（表示该驱动支持的最高 CUDA 版本）

如需更详细信息：

nvidia-smi -q

可查看 GPU 内存、温度、显存占用等。

判断方式：

打开 CUDA Toolkit 官方文档（同页左侧目录中 “System Requirements → Supported Host Compiler”）。
查找当前 CUDA 版本对应的 VS 版本号。例如：
- CUDA 12.6 支持 VS 2019（16.x）与 VS 2022（17.x）。
- 若安装其他版本（如 VS 2017），则不算 supported。
若系统内已安装的 VS 版本在该列表中，则算“supported”。
若仅安装 VS Code，不满足要求，因为 VS Code 不是 C++ 编译环境，不含 MSVC 编译器。

Nsight Systems
用于分析整个系统级性能。可直接加载 hello.cu 编译生成的 .exe 文件，点击“Run and Trace”即可运行 CUDA 程序。
Nsight Compute
用于分析单个 CUDA kernel 的性能。可选择可执行文件并直接运行以查看每个 kernel 的详细指标（线程利用率、内存带宽等）。
Nsight Monitor
主要作为后台服务监控 GPU 性能，为前两个工具提供数据支持。

你必须用 nvcc 把 .cpp 源码编译成 .exe，然后运行。

cd 无法跨盘符 → 先输入目标盘符（E:）再 cd。
路径中有空格 → 必须用引号。

Windows 的 cd 命令不能直接跨盘符进入另一个分区；如果你现在在 D: 盘，而目标路径在 E: 盘，你必须先切换盘符，再执行 cd。

为什么不冲突

Unity 的计算着色器走的是 图形 API 路径，与 CUDA 的 驱动 API 路径并行存在。
同一块 NVIDIA GPU 可以同时执行 CUDA 程序和 Unity Compute Shader，只要上下文不同。
实际上 CUDA 与 DirectX/Vulkan 可以共享显存资源（通过 cudaGraphicsD3D11RegisterResource 等）。

项目	Unity Compute Shader	CUDA
接口标准	DirectX / Vulkan / Metal	NVIDIA 专用 API
兼容显卡	所有厂商（NVIDIA/AMD/Intel）	仅 NVIDIA
编译语言	HLSL 或 GLSL	CUDA C/C++
生态功能	主要用于渲染、粒子、物理	广泛用于科学计算、AI、深度学习
引擎封装	Unity 统一封装调度	用户直接操作 CUDA 核函数和内存

Unity 的 Compute Shader 和 NVIDIA 的 CUDA 属于同一层级——都面向 GPU 通用计算（GPGPU），但走的管线与生态完全不同，且不冲突。

1. Unity Compute Shader 的本质

使用 HLSL/DirectX Compute Shader（或 Metal/Vulkan 等后端）。
运行时由 Unity 调用底层图形 API（DirectX 12、Vulkan、Metal）编译并提交到 GPU 驱动。
驱动再将 HLSL 的字节码（DXIL/SPIR-V）编译为显卡可执行的机器指令（SASS）。
→ 即：Unity → 图形 API → GPU 驱动 → 硬件。

2. CUDA 的本质

CUDA 提供独立于图形 API 的 通用计算生态。
它由 NVIDIA 驱动暴露的 CUDA Runtime / Driver API 调度执行。
编译链：nvcc → PTX（虚拟 ISA）→ 驱动 → SASS。
→ 即：CUDA → NVIDIA 驱动 → 硬件。

显卡型号决定“最高支持版本”，但不影响安装

比如 GTX 750（Compute Capability 5.0）最高支持 CUDA 11.4。
你仍可安装 CUDA 13.0，但运行时驱动会报：

your GPU architecture is not supported
因此 CUDA 安装与否取决驱动兼容性，能否运行才取决显卡算力

驱动承担“翻译层”角色

CUDA 工具链（如 nvcc、cuBLAS）不直接访问硬件，而调用 NVIDIA 驱动提供的 API。
驱动负责将这些 CUDA API 调用翻译成底层 GPU 指令（PTX → SASS → GPU microcode）。
因此只要驱动知道怎么和显卡通信，CUDA 工具链不必关心具体显卡型号。

显卡功能由驱动报告，不由安装器直接识别

显卡的 CUDA 支持（如 SM 架构版本、算力级别）是通过驱动暴露给系统的。
安装器不会直接去识别显卡芯片型号，而是调用驱动的接口（Device Query API）读取能力表。
如果驱动能报告“支持 CUDA”，安装器就视为可用设备。

例：

你的显卡是 RTX 3080，只要驱动版本 ≥ R560，安装器认为完全兼容。
即使显卡极强，但驱动太旧（例如 R520），则 CUDA 13.0 会报“不兼容”。

自动检测机制
- CUDA 安装程序确实会检测系统中是否存在受支持的 NVIDIA 驱动版本。
- 若驱动版本低于所需（< R560），安装程序会提示“驱动版本不兼容”，并提供“Install driver”选项。
- 若你的显卡不在 CUDA 支持列表中（例如太旧的 GTX 600 系列或非 NVIDIA GPU），安装程序不会中断，但 CUDA 工具链安装成功后将无法运行 GPU 代码。
英伟达不会强制阻止安装
- 安装器默认允许你安装 CUDA Toolkit（nvcc、库、头文件），即使显卡不兼容。
- 真正执行 CUDA 程序时（如运行 deviceQuery.exe 或 nvcc sample.cu），才会报错：
  no CUDA-capable device detected
- 因此英伟达不会在安装阶段“绝对不让你装”，它只会警告不兼容。

UnityEditor.Rendering → 渲染管线开发者用。

UnityEditor 系列 → 技术美术 / 工具作者常用。

UnityEditor.Rendering.LookDev 是你在 Unity 编辑器里看到的 LookDev 窗口的实现部分。它处理用户界面、上下文、编辑器交互、环境库、视图布局、调试控制等。
UnityEngine.Rendering.LookDev 则是面向渲染管线的运行时 API，让 SRP（如 HDRP）能够在编辑器中或运行时与 LookDev 的系统对接。比如，渲染管线通过实现 IDataProvider 接口来让 LookDev 窗口能够正确显示环境、天空、阴影、调试视图等元素。 Unity Documentation+2Unity Documentation+2
编辑器那边的 LookDev 窗口在操作时会与运行时组件协作。比如在 Editor 模式下修改环境、摄像机参数，Editor 端通过调用运行时接口来刷新渲染预览。

模块	功能
Environment / Lighting	环境光与 HDRI 贴图的加载、切换、曝光调节、阴影设置。
Material / Shader	绑定测试模型、材质与 Shader，比较不同版本的渲染表现。
Camera / View	双视图对比（左右对比或上下对比），相机位置与角度同步控制。
Scene Context	当前被测试对象的上下文状态，包含资源路径、材质实例引用等。
UI / Editor Integration	与 Editor 工具栏、Inspector 面板集成的交互组件。

核心用途：

校验 PBR、Toon、NPR 等材质在统一光照下的外观一致性。
对比不同 Shader Graph、贴图集、渲染管线的视觉结果。
生成 look preset 或 lighting preset。

LookDev 命名空间通常包含环境、相机、材质、视图、上下文、UI等模块，用于材质与光照的可视化测试和比对

在 C# 中，命名空间可以嵌套。声明方式例如：

namespace A {namespace B {class C { }}
}

访问规则如下：

命名空间只是逻辑分组，不产生层级访问权限。
“父命名空间”不会自动“拥有”子命名空间的作用域。
即 namespace A 内的代码，不能直接访问 B.C ，必须写完整限定名 A.B.C 或 using A.B;。
相反，子命名空间也不会自动“继承”父命名空间的 using 声明。各自独立。
命名空间之间无访问控制机制（不像类的 private/protected/public）。它只影响名称解析，不影响可见性。

Render Pipeline Instance and Render Pipeline Asset

Every render pipeline based on SRP has two key customized elements:

A Render Pipeline Instance. This is an instance of a class that defines the functionality of your render pipeline. Its script inherits from RenderPipeline, and overrides its Render() method.
A Render Pipeline Asset. This is an asset in your Unity Project that stores data about which Render Pipeline Instance to use, and how to configure it. Its script inherits from RenderPipelineAsset and overrides its CreatePipeline() method.

For more information on these elements, and instructions on how to create them in a custom render pipeline, see Creating a Render Pipeline Asset and a Render Pipeline Instance.

ScriptableRenderContext

ScriptableRenderContext is a class that acts as an interface between the custom C# code in the render pipeline and Unity’s low-level graphics code.

Use the ScriptableRenderContext API to schedule and execute rendering commands. For information, see Scheduling and executing rendering commands in the Scriptable Render Pipeline.

https://www.youtube.com/watch?v=1L-x_DH3Uvg

https://www.youtube.com/watch?v=QQceTDjA4f4

#include <stdio.h>

// 这个函数在 GPU 上执行（kernel），标记这是一个可从主机调用，在设备上执行的kernel 函数
__global__ void helloFromGPU() {
printf("Hello from GPU! Thread (%d, %d, %d)\n",
blockIdx.x, threadIdx.x, blockIdx.x * blockDim.x + threadIdx.x);

//在支持的 GPU 架构上可用（较新 CUDA 版本支持），用于在 device端调试输出
}

int main() {
// 启动 kernel：用 1 个 block，1 个 thread，CUDA 的 kernel launch 语法, 表示: 1 个 block, 每个 block 1 个thread
helloFromGPU<<<1, 1>>>();

// 同步，确保 GPU 的 printf 输出能被刷新回主机，等待GPU完成所有工作。否则主机可能在GPU 输出之前就退出，导致看不到输出
cudaDeviceSynchronize();

return 0;
}

https://www.youtube.com/watch?v=QQceTDjA4f4

“Dimensional tensor” 指具有特定维度结构的张量。

Tensor（张量）是一个多维数组的泛化。

在深度学习中的含义

在 PyTorch、TensorFlow、NumPy 等框架中：

张量是所有数据（图像、音频、文本 embedding 等）的统一存储形式；
维度数量（rank）和每个维度长度（shape）定义了其结构；
示例：
图像批次：[batch, height, width, channel] → 4D tensor
视频序列：[batch, frame, height, width, channel] → 5D tensor

一个 3D tensor 可以看作多个 2D 矩阵的堆叠。但这些子张量的 shape 和 dtype 仍必须一致，否则张量无法构成统一形状。

torch.tensor([[1,2],[3,4]]) # 合法

torch.tensor([[1,2],[3]]) # 不合法（形状不统一）

与“一维数组”不同的抽象层：

一维数组：线性存储结构。
张量：多维代数对象，支持坐标变换、张量积、卷积等操作。它在 GPU/线性代数硬件上有统一的并行内存布局。

Flynn’s Taxonomy（弗林分类法）是计算机体系结构中用于划分并行计算模型的经典框架，由 Michael J. Flynn 于 1966 年提出。

依据两维度：

指令流（Instruction stream）：控制逻辑发出的指令序列数量
数据流（Data stream）：被处理的数据序列数量

类型	全称	特征	示例
SISD	Single Instruction, Single Data	单指令、单数据流；顺序执行	传统单核 CPU
SIMD	Single Instruction, Multiple Data	一条指令同时处理多组数据	GPU、向量处理器
MISD	Multiple Instruction, Single Data	多条指令作用于同一数据流（极少见）	容错系统、信号冗余管线
MIMD	Multiple Instruction, Multiple Data	多指令、多数据流；各处理单元独立运行	多核 CPU、分布式集群

与 GPU/游戏图形的关系

GPU 属于 SIMD/SIMT（Single Instruction, Multiple Thread）架构的演化形态：

每个线程执行相同指令序列（shader 代码）；
但处理不同顶点、像素、粒子（不同数据流）。这正是 Flynn 分类中 SIMD 模式的现代实现。

CPU 则属于 MIMD：

每个核心可执行不同程序线程（不同指令流与数据流）。

公式示例

以单精度（FP32）为例：

Throughput=CUDA cores×每核心每周期运算次数×时钟频率

示例（RTX 4090）：

16384 cores × 2 FMA ops × 2.52 GHz ≈ 82.5 TFLOPS

与延迟（latency）的区别

指标	含义	目标
Latency	单个任务完成所需时间	尽量低
Throughput	同时处理多个任务的效率	尽量高

GPU 为了最大化 throughput，常牺牲单线程的 latency。即：一次算慢一点没关系，只要能并行算更多就行。

GPU throughput（吞吐量）指 GPU 在单位时间内能完成的有效计算或数据处理量，是衡量 GPU 性能的核心指标之一。

Throughput = 工作完成量 ÷ 时间

在 GPU 中，通常用以下方式度量：

每秒可执行的浮点运算次数（FLOPS）；
每秒可处理的像素或顶点数量；
每秒可读写的数据量（带宽 GB/s）。

Embarrassingly parallel program：

指任务之间完全独立、无需通信或同步的并行问题。每个数据单元都可以独立计算，结果互不影响。顶点坐标批量乘以矩阵是一种 embarrassingly parallel workload。

embarrassingly parallel 是任务特性；（Vertex Shader，Fragment Shader，Compute Shader）
SIMD 是实现这种任务并行的硬件机制之一。

概念	层级	说明
SIMD	硬件/指令层面	同一条指令作用于多个数据
Embarrassingly parallel	算法/任务层面	每个任务彼此独立，无需通信

添加图片注释，不超过 140 字（可选）

SIMD（Single Instruction, Multiple Data）与模型顶点变换的关系：

它是加速这些顶点数学运算的底层机制。

Micron 是一家半导体制造公司，全名 Micron Technology, Inc.，总部在美国爱达荷州。它生产 DRAM（动态随机存取内存）、NAND Flash（闪存）和显存芯片（如 GDDR 系列）。 GDDR6X 是一种显存（Graphics Double Data Rate 6X）标准，由 Micron 与 NVIDIA 联合开发，是 GDDR6 的增强版。

核心区别与技术要点如下：

项	Micron	GDDR6X
类型	公司（制造商）	显存标准
功能	设计、生产内存芯片	为 GPU 提供高带宽显存
推出时间	成立于 1978 年	2020 年（首次用于 RTX 3080/3090）
技术特征	生产 DDR、LPDDR、GDDR、NAND 等	PAM4 信号传输（每时钟传 4 个电平）、高带宽（最高 24 Gbps/pin）
典型应用	PC 内存、SSD、显卡显存	高端 GPU（RTX 30/40 系列）
数据传输模式	不限，取决于产品	比 GDDR6 的 NRZ 双电平更高效

简而言之：

Micron 是公司；
GDDR6X 是由 Micron 生产、用于高性能 GPU 的显存技术。

proves that I'm living for the last day

QA 与调试标准

所有 Blend Tree 必须有“边界动画”，防止 NaN 混合。
参数变化曲线在 Profiler 中平滑（无跳变）。
Layer 权重可动态监控（Animator 窗口）。
Root Motion 位移与视觉一致，不漂移。

状态过渡（Clip Blend Tree）：在“同一维度”的动作间插值（如速度变化）。
Layer 混合（Layer Weight）：在“不同维度”的动作间叠加（如姿态叠加、表情、装备）

何时不能用 Layer

场景	原因
同骨架、同类型行走与跑步	应用 Blend Tree 最平滑
有 Root Motion 位移	Layer 混合无法同步位移，容易漂移
仅速度控制	参数驱动比 Layer 权重更直观

动画系统来自不同来源（无法 Blend）

Walk 与 Run 动画出自不同骨架或风格（例如 Humanoid 与 Generic 混用），无法放入同一 Blend Tree；
为避免重定向误差，用 Layer 区分并手动切换权重。

行走动画与装备动画混合

角色边走边背重物

Base：走路
Layer 1：带重物姿态（覆盖 Spine→Arms）
权重可动态调节以模拟“负重感”。

只有在两个动作属于并行维度、而非线性状态时才用 Layer。

1. 行走层 + “冲刺强化层”

场景：跑步时希望叠加一个“额外冲刺姿势”或“上半身加速摆臂”动作
做法：

Base Layer：普通跑步
Sprint Layer：覆盖部分骨骼（上半身）
Shift 按下时提高 Sprint Layer 权重
结果：底层跑步仍保留，额外层增强上半身动作。

用例	描述
角色开镜瞄准	按下右键增加上半身“瞄准层”权重
跑步→冲刺过渡	按 Shift 提高冲刺层权重
情绪/表情混合	动态插入“表情层”
动作模糊过渡	在动画事件中缓慢插值权重实现平滑 blending

You can vary the weight
to get interesting results and animate to achieve a smooth blend between animations

例外：Humanoid Avatar Mask

若你的 Mask 类型是 Humanoid（而不是 Transform）：

Unity 使用标准人形骨架定义（Hips、Spine、Arms、Legs、Head）。
这时不需导入具体 Avatar 也能看到固定的通用分区（Body、Head、Left Arm 等）。
但前提是动画控制器使用的是 Humanoid rig。

这种模式下，Unity 使用自己的 Humanoid Retargeting 系统，自动匹配标准部位。

增加资源的复用能力？。mask

对avatar的一种mask，对的，对avatar

In the Inspector
you’ll see two types to select from
depending on the animation type your
character is using

You can use an avatar mask to define
which body parts will use the basic
walk animation and which will use a
different animation Use them with the
layer system to exclude certain body
parts affected by specific animations
You can combine motions together,
e g , use the upper body from one and
the lower body from another

a powerful way to time your code with the Animator component

它展示了 AnimatorStateInfo、IsTag() 的用法，适合初学者理解 Animator 状态检测；
但在生产代码中，这段写法属于“演示级伪逻辑”，不会出现在正式项目中。？？

You can also assign certain animations tags in the Tag field, which are useful when
coding

For an animation to be active it needs a transition from any node that
is connected to the default state issuing from the orange node, or a transition from the Any
State node

Ensure that the animations match the same animation
type set for the character: Generic animations for a generic character, and humanoid
animations for a humanoid character

They will need
to reference the avatar from the FBX character file to ensure the animations are matched
correctly to that character’s skeleton

只有动画的FBX文件也将默认使用通用的动画类型从FBX角色文件中引用角色，以确保动画匹配正确的角色骨架

Animation-only FBX files will also use a generic animation type by default They will need
to reference the avatar from the FBX character file to ensure the animations are matched
correctly to that character’s skeleton

other animations for characters
that have a different skeletal setup might not work with this character when using a generic
animation type, but generic animations will still work with characters that have the same
skeletal layout

here it’s unnecessary to share animations between characters with different skeletal structures