常规Uniform下点光源属性存储：合并与分离方案孰优？

我为点光源设计了如下常规Uniform结构：

uniform struct lights
{
    int size;          // 要遍历的光源总数
    vec3 position[20]; // 最多支持20个光源
    vec3 color[20];
    float radius[20];
    float intensity[20];
}
uni_point_lights;

我会在Shader中遍历[0; uni_point_lights.size)范围内的属性。另外我也可以把属性合并存储：

vec4 position_and_radius[20];
vec4 color_and_intensity[20];

也就是把vec3和float合并成vec4，通过.xyz和.w分别访问对应数据。

第一种方案代码更易读整洁，但第二种我猜测在对齐限制上可能更有优势，不过需要额外处理拆分数据。我知道UBO的uniform块布局（比如std140中vec3和vec4占用空间相同）能明确方案选择，但找不到关于常规Uniform的相关资料，现有资料大多围绕UBO，而且我用的是数组而非单个值。

请问哪种方案更优？原因是什么？

优先选择第二种合并vec4的方案，原因如下： #

• 内存对齐与空间利用率：绝大多数GPU驱动对常规Uniform的内存对齐逻辑和UBO的std140规则类似——vec3类型会被强制对齐到vec4的16字节空间。也就是说第一种方案里的vec3 position[20]实际占用2016字节，而非理论上的2012字节，后续的radius数组还要继续按对齐规则排布，整体会浪费大量内存空间。合并成vec4后，每个光源的两组数据都刚好填满16字节空间，完全没有浪费。
• 数据访问效率：合并后的结构让每个光源的位置+半径、颜色+强度都能作为一个完整的4分量向量被GPU一次性读取，减少了内存访问次数。而第一种方案中，position、color、radius、intensity是分散的数组，GPU需要跨多个数组读取数据，缓存命中率更低，性能表现不如合并方案。
• Uniform资源限制：常规Uniform有数量上限（不同GPU规格有差异），分散的多数组会占用更多Uniform槽位，合并后的数组数量更少，能有效避免触发Uniform数量不足的问题。

可读性补充方案 #

如果担心合并后代码可读性下降，可以在Shader里定义简单的宏来封装访问逻辑，比如：

#define GET_LIGHT_POS(idx) uni_point_lights.position_and_radius[idx].xyz
#define GET_LIGHT_RADIUS(idx) uni_point_lights.position_and_radius[idx].w
#define GET_LIGHT_COLOR(idx) uni_point_lights.color_and_intensity[idx].xyz
#define GET_LIGHT_INTENSITY(idx) uni_point_lights.color_and_intensity[idx].w

这样既能保证性能优势，又能让代码保持清晰易读。

内容的提问来源于stack exchange，提问作者postcoital-solitaire