On Fri, Jan 8, 2016 at 12:35 PM, Axel Davy <[email protected]> wrote: > On 08/01/2016 02:30, Marek Olšák wrote: >> >> From: Marek Olšák <[email protected]> >> >> It will become a system value, not an input. >> --- >> src/gallium/drivers/radeonsi/si_state_shaders.c | 45 >> ++++++++++++------------- >> 1 file changed, 22 insertions(+), 23 deletions(-) >> >> diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c >> b/src/gallium/drivers/radeonsi/si_state_shaders.c >> index 64adf69..460dda5 100644 >> --- a/src/gallium/drivers/radeonsi/si_state_shaders.c >> +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c >> @@ -399,30 +399,29 @@ static void si_shader_ps(struct si_shader *shader) >> if (!pm4) >> return; >> - for (i = 0; i < info->num_inputs; i++) { >> - switch (info->input_semantic_name[i]) { >> - case TGSI_SEMANTIC_POSITION: >> - /* SPI_BARYC_CNTL.POS_FLOAT_LOCATION >> - * Possible vaules: >> - * 0 -> Position = pixel center (default) >> - * 1 -> Position = pixel centroid >> - * 2 -> Position = at sample position >> - */ >> - switch (info->input_interpolate_loc[i]) { >> - case TGSI_INTERPOLATE_LOC_CENTROID: >> - spi_baryc_cntl |= >> S_0286E0_POS_FLOAT_LOCATION(1); >> - break; >> - case TGSI_INTERPOLATE_LOC_SAMPLE: >> - spi_baryc_cntl |= >> S_0286E0_POS_FLOAT_LOCATION(2); >> - break; >> - } >> + /* SPI_BARYC_CNTL.POS_FLOAT_LOCATION >> + * Possible vaules: >> + * 0 -> Position = pixel center >> + * 1 -> Position = pixel centroid >> + * 2 -> Position = at sample position >> + * >> + * From GLSL 4.5 specification, section 7.1: >> + * "The variable gl_FragCoord is available as an input variable >> from >> + * within fragment shaders and it holds the window relative >> coordinates >> + * (x, y, z, 1/w) values for the fragment. If multi-sampling, >> this >> + * value can be for any location within the pixel, or one of >> the >> + * fragment samples. The use of centroid does not further >> restrict >> + * this value to be inside the current primitive." >> + * >> + * Meaning that centroid has no effect and we can return anything >> within >> + * the pixel. Thus, return the value at sample position, because >> that's >> + * the most accurate one shaders can get. >> + */ >> + spi_baryc_cntl |= S_0286E0_POS_FLOAT_LOCATION(2); > > > When combined with POS_FLOAT_ULC, in which situation could we see > a difference in the POSITION value ?
No MSAA: the value is at the pixel center MSAA, no sample shading: the value is at the sample position of any visible sample (compatible with "centroid") MSAA sample shading: the value is at the sample position of the computed sample As far as I know, POS_FLOAT_ULC only offsets the value by a constant (0.5). Marek _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
