In a perfect world, we'd use fp16 varyings for mediump and fp32 for
highp, allowing us to get a performance win without sacrificing
conformance. Unfortunately, we're not there (yet), so it's better we
assume always fp32 than always fp16 to avoid artefacts / breaking a lot
of deqp.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
/* Default to a vec4 varying */
struct mali_attr_meta v = {
- .format = MALI_RGBA16F,
+ .format = MALI_RGBA32F,
.swizzle = default_vec4_swizzle,
.unknown1 = 0x2,
};
state->reads_point_coord = true;
} else {
v.index = 0;
- v.src_offset = 8 * (general_purpose_count++);
+ v.src_offset = 16 * (general_purpose_count++);
}
state->varyings[i] = v;
}
- /* Set the stride for the general purpose fp16 vec4 varyings */
- state->general_varying_stride = (2 * 4) * general_purpose_count;
+ /* Set the stride for the general purpose fp32 vec4 varyings */
+ state->general_varying_stride = (4 * 4) * general_purpose_count;
}