On Fri, Jan 8, 2016 at 4:30 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> On 08.01.2016 06:48, Marek Olšák wrote:
>>
>> On Fri, Jan 8, 2016 at 12:35 PM, Axel Davy <axel.d...@ens.fr> wrote:
>>>
>>> On 08/01/2016 02:30, Marek Olšák wrote:
>>>>
>>>>
>>>> From: Marek Olšák <marek.ol...@amd.com>
>>>>
>>>> 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).
>
>
> According to the docs it forces the position into the upper-left corner,
> AFAICT overriding the choice of POS_FLOAT_LOCATION. But that's exactly what
> we want here, isn't it?
I'm not sure. It either truncates the position, or it moves the pixel
center to the upper-left corner, and then adds the sample position,
whose components are in [-0.5, 0.5).
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
