关键不在float本身，而在其组织方式与计算范式：cpu端用floatvector批量向量化处理图像数据，gpu端用float3/float4x4等类型驱动并行矩阵运算，配合内存对齐、统一变量传递和专用库调用以提升吞吐量。
直接用 float 类型本身无法“动态接收矩阵变量”或提升渲染吞吐量——它只是 32 位浮点数的存储单元。真正起作用的是：如何把 float 组织成向量/矩阵结构，并在合适层级（CPU 向量化 / GPU 着色器）上调度计算。关键不在 float，而在它所处的计算范式。
用 FloatVector 在 CPU 层批量处理图像数据
Java 中的 FloatVector 不是“接收矩阵”，而是按硬件向量长度（如 AVX-512 下 16 个 float）自动分块加载、运算、写回。适合图像预处理（如 YUV 转 RGB 的系数乘加）、滤波卷积等规则访存场景。
- 确保输入数组内存连续、对齐，避免跨步（stride ≠ 1）导致性能下降
- 用
SPECIES_PREFERRED让 JVM 自动匹配当前 CPU 最优指令集，无需手动判断 SSE/AVX - 循环边界需按
SPECIES.length()对齐，剩余元素用标量补足，避免越界 - 示例：对一张 1920×1080 灰度图做逐像素线性拉伸，比传统 for 循环快 2–3 倍
用 float 在 HLSL/GLSL 中驱动 GPU 并行矩阵运算
GPU 上的 float 是向量计算的基本粒度。通过 float3、float4x4 等类型，配合纹理采样和内置矩阵函数，才能真正释放吞吐能力。
- 在片段着色器中，用
float3 yuv = tex2D(y_tex, uv).rgb一次读取三通道，而非三次单通道采样 - YUV→RGB 转换应使用
mul(yuv_matrix, yuv)而非手写三个独立表达式，编译器可优化为单条 SIMD 指令 - 避免在着色器中构造运行时矩阵（如用 if 动态拼接），所有变换矩阵应由 CPU 计算好后以 uniform 传入
- Unity Shader Graph 中的 Float 节点若用于控制曝光、对比度等参数，建议设为 [0, 1] 范围并启用精度模式为 Half，减少寄存器压力
规避 float 使用中的常见效能陷阱
高频图形渲染对数值稳定性与访存效率极其敏感，几个容易被忽略但影响显著的点：
- 不要在 CPU 端用 float 数组模拟矩阵乘法（如 4×4 × 4×1），改用专用库（Eigen、GLM）或直接交由 GPU 处理
- 避免在循环内反复将 int 坐标转 float 再做除法归一化（如
(float)i / width），提前算好步长常量 - Android OpenGL ES 中，NV21 渲染必须用两个
sampler2D分别采样 Y 和 UV 平面，不能合并为一个 float4 纹理——格式不兼容会导致采样错误或性能暴跌 - float 运算顺序会影响结果（尤其累加），但在图像处理中通常可接受；若需确定性，用
strictfp（Java）或#pragma fp(fast=false)（HLSL）
