On Thu, Jul 5, 2018 at 12:49 PM, Eric Anholt <[email protected]> wrote: > From the ARB_color_buffer_float spec: > > 35. Should the clamping of fragment shader output gl_FragData[n] > be controlled by the fragment color clamp. > > RESOLVED: Since the destination of the FragData is a color > buffer, the fragment color clamp control should apply. > > Fixes arb_color_buffer_float-mrt mixed on v3d.
Reviewed-by: Rob Clark <[email protected]> *possibly* over thinking this, the comment in the gl_frag_result enum implies that FRAG_RESULT_DATAn come at the end of the enum (ie. if there was somehow ever a new value added it should come before FRAG_RESULT_DATA0).. maybe that comment should be less subtle to avoid accidentally breaking the logic below? BR, -R > --- > src/compiler/nir/nir_lower_clamp_color_outputs.c | 9 ++------- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/src/compiler/nir/nir_lower_clamp_color_outputs.c > b/src/compiler/nir/nir_lower_clamp_color_outputs.c > index b76a4d51aaca..32f855624276 100644 > --- a/src/compiler/nir/nir_lower_clamp_color_outputs.c > +++ b/src/compiler/nir/nir_lower_clamp_color_outputs.c > @@ -47,13 +47,8 @@ is_color_output(lower_state *state, nir_variable *out) > } > break; > case MESA_SHADER_FRAGMENT: > - switch (out->data.location) { > - case FRAG_RESULT_COLOR: > - return true; > - default: > - return false; > - } > - break; > + return (out->data.location == FRAG_RESULT_COLOR || > + out->data.location >= FRAG_RESULT_DATA0); > default: > return false; > } > -- > 2.18.0 > _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
