Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-20 Thread Erik Faye-Lund 
On Thu, Nov 16, 2017 at 6:26 PM, Ilia Mirkin  wrote:
> On Thu, Nov 16, 2017 at 7:15 AM, Wladimir  wrote:
>>> I think it would be reasonable to re-emit the shader state (or maybe
>>> just the varyings) when the primitive type changes from points to
>>> non-points. It virtually never happens that the same shader combo is
>>> used for points and non-points.
>>
>> Thinking about it, this might even simplify some contorted code we
>> currently have in the emit sequence with regard to pointsize VS
>> outputs. Which becomes even worse in GC7000 where there's more (USC /
>> buffering related) state depending on the exact number of VS outputs.
>>
>> Hmm that state depends on point_size_per_vertex, not whether we're
>> rendering points. So I guess we'd want to re-link the shader if:
>>
>> - switching from point to non-point rendering, or vice versa
>> - if rendering points AND point_size_per_vertex changes
>>
>> Though as for the latter I have no clue where vivantes get the point
>> size from if !point_size_per_vertex, currently we don't handle
>> pipe_rasterizer_state->point_size at all, we pretty much just assume
>> point_size_per_vertex.
>
> I'm probably just saying stuff that you already know, but ... I'll say
> it anyways:
>
> The point of the texcoord semantics is precisely point sprite
> replacement. NVIDIA hardware (Fermi+) can only do point sprite
> replacement on certain specially-located varyings, hence the texcoord
> semantic was created. (And nv30 also has similar restrictions. nv50 is
> unconstrained, go figure.)
>
> In legacy GL, only gl_TexCoord varyings may be replaced by point
> sprites, and the gl_PointCoord is handled separately. I don't think ES
> has an equivalent of point sprite coord replacements.

OpenGL ES 1.x does, through OES_point_sprite. But this should already
use legacy gl_TexCoord varyings. On OpenGL ES 2.0, all we have is
gl_PointCoord. So yeah, OpenGL ES should be covered.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-18 Thread Wladimir J. van der Laan 
On Thu, Nov 16, 2017 at 01:38:32PM -0500, Ilia Mirkin wrote:

> > Which is annoying as it means that shader state now depends on either the 
> > kind
> > of primitive (which is per-draw), or the shading model (which is part of
> > rasterizer state).
> 
> I take it your hardware doesn't support setting a different polygon
> mode for front and back-facing triangles?

I don't know. Might have been added at some point, though I wouldn't be
suprised if it's emulated. The current driver certainly doesn't handle it.

In general Vivante's focus seems to have been to make hw for OpenGL ES 2.0, then
3.x, recently Vulkan. Anything else is usually emulated.

I don't currently have any means to figure out, cannot test OpenGL desktop with
the blob.

> > Thinking of it, the latter is also an option, at least we don't have to
> > "smuggle" per-draw info into the state emit call. But it's still
> > quite more involved to fix than I expected :(
> 
> When you say flat shading ... are you talking about like "flat in vec4
> bla", or like glShadeModel(GL_FLAT)? If the latter, note that this
> only applies to gl_Color / gl_SecondaryColor. Not regular varyings.
> The "flat" keyword can apply to any varying, of course.

Talking about support for ancient glShaderModel(...). You're right about it
only applying to color semantics, that's why my patch is not correct. We're
fighting with the hardware there which seemingly uses different semantics.

flat as a GLSL attribute was introduced in GLSL ES 300, not sure how this is
handled by the blob, but we're not quite there yet.

> These are totally separate concepts, I'd really recommend poring over
> your traces again to see if you might have missed something. Here's
> how it works on Adreno:
> 
> a3xx is easy:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/a3xx/fd3_program.c#n386
> 
> a4xx+ is a little weird:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/a4xx/fd4_program.c#n473
> +
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c#n2945
> 
> (i.e. you have to load flat inputs specially on a4xx+)

Interesting, both quite different approaches from Vivante. 

Regards,
Wladimir
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-16 Thread Ilia Mirkin 
On Thu, Nov 16, 2017 at 1:20 PM, Wladimir J. van der Laan
 wrote:
> On Thu, Nov 16, 2017 at 12:26:05PM -0500, Ilia Mirkin wrote:
>> On Thu, Nov 16, 2017 at 7:15 AM, Wladimir  wrote:
>
>> The point of the texcoord semantics is precisely point sprite
>> replacement. NVIDIA hardware (Fermi+) can only do point sprite
>> replacement on certain specially-located varyings, hence the texcoord
>> semantic was created. (And nv30 also has similar restrictions. nv50 is
>> unconstrained, go figure.)
>>
>> In legacy GL, only gl_TexCoord varyings may be replaced by point
>> sprites, and the gl_PointCoord is handled separately. I don't think ES
>> has an equivalent of point sprite coord replacements.
>>
>> Hardware without that restriction should probably not use the texcoord
>> semantic and just use GENERIC for everything.
>
> Thanks for the info - I know about nothing about legacy GL, too long
> ago for me.
>
> For Vivantes (HALTI4-) it is the case that any varying can be replaced by the
> point coordinate. This is used for the gl_PointCoord as well. So far so good.
>
> However the trouble is in how this interacts with flat shading. The same flag
> is used to mark varyings that should be interpolated when using flat
> shading (apparently everything except COLOR?).
>
> Currently the criterion for setting the flag is !=SEMANTIC_COLOR. This
> works for polygons, by allowing non-color varyings override flat shading, but
> breaks when rendering points, because we want GENERIC varyings to be simply
> passed through in that case - not replaced with the point coordinate!
>
> Which gives us the following varying state, for flat shaded and smooth 
> polygons
> and for points (where shading model is irrelevant) respectively:
>
>  GENERIC  T/PCOORD COLOR
> Flat11   0
> Smooth  xx   x
> Points  01   0
>
> (0=VARYING_USE_USED, 1=VARYING_USE_POINTCOORD, x=dont_care)
>
> Which is annoying as it means that shader state now depends on either the kind
> of primitive (which is per-draw), or the shading model (which is part of
> rasterizer state).

I take it your hardware doesn't support setting a different polygon
mode for front and back-facing triangles?

>
> Thinking of it, the latter is also an option, at least we don't have to
> "smuggle" per-draw info into the state emit call. But it's still
> quite more involved to fix than I expected :(

When you say flat shading ... are you talking about like "flat in vec4
bla", or like glShadeModel(GL_FLAT)? If the latter, note that this
only applies to gl_Color / gl_SecondaryColor. Not regular varyings.
The "flat" keyword can apply to any varying, of course.

These are totally separate concepts, I'd really recommend poring over
your traces again to see if you might have missed something. Here's
how it works on Adreno:

a3xx is easy:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/a3xx/fd3_program.c#n386

a4xx+ is a little weird:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/a4xx/fd4_program.c#n473
+
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c#n2945

(i.e. you have to load flat inputs specially on a4xx+)

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-16 Thread Wladimir J. van der Laan 
On Thu, Nov 16, 2017 at 12:26:05PM -0500, Ilia Mirkin wrote:
> On Thu, Nov 16, 2017 at 7:15 AM, Wladimir  wrote:

> The point of the texcoord semantics is precisely point sprite
> replacement. NVIDIA hardware (Fermi+) can only do point sprite
> replacement on certain specially-located varyings, hence the texcoord
> semantic was created. (And nv30 also has similar restrictions. nv50 is
> unconstrained, go figure.)
> 
> In legacy GL, only gl_TexCoord varyings may be replaced by point
> sprites, and the gl_PointCoord is handled separately. I don't think ES
> has an equivalent of point sprite coord replacements.
> 
> Hardware without that restriction should probably not use the texcoord
> semantic and just use GENERIC for everything.

Thanks for the info - I know about nothing about legacy GL, too long
ago for me.

For Vivantes (HALTI4-) it is the case that any varying can be replaced by the
point coordinate. This is used for the gl_PointCoord as well. So far so good.

However the trouble is in how this interacts with flat shading. The same flag
is used to mark varyings that should be interpolated when using flat
shading (apparently everything except COLOR?).

Currently the criterion for setting the flag is !=SEMANTIC_COLOR. This
works for polygons, by allowing non-color varyings override flat shading, but
breaks when rendering points, because we want GENERIC varyings to be simply
passed through in that case - not replaced with the point coordinate!

Which gives us the following varying state, for flat shaded and smooth polygons
and for points (where shading model is irrelevant) respectively:

 GENERIC  T/PCOORD COLOR
Flat11   0
Smooth  xx   x
Points  01   0

(0=VARYING_USE_USED, 1=VARYING_USE_POINTCOORD, x=dont_care)

Which is annoying as it means that shader state now depends on either the kind
of primitive (which is per-draw), or the shading model (which is part of
rasterizer state).

Thinking of it, the latter is also an option, at least we don't have to
"smuggle" per-draw info into the state emit call. But it's still
quite more involved to fix than I expected :(

Regards,
Wladimir
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-16 Thread Ilia Mirkin 
On Thu, Nov 16, 2017 at 7:15 AM, Wladimir  wrote:
>> I think it would be reasonable to re-emit the shader state (or maybe
>> just the varyings) when the primitive type changes from points to
>> non-points. It virtually never happens that the same shader combo is
>> used for points and non-points.
>
> Thinking about it, this might even simplify some contorted code we
> currently have in the emit sequence with regard to pointsize VS
> outputs. Which becomes even worse in GC7000 where there's more (USC /
> buffering related) state depending on the exact number of VS outputs.
>
> Hmm that state depends on point_size_per_vertex, not whether we're
> rendering points. So I guess we'd want to re-link the shader if:
>
> - switching from point to non-point rendering, or vice versa
> - if rendering points AND point_size_per_vertex changes
>
> Though as for the latter I have no clue where vivantes get the point
> size from if !point_size_per_vertex, currently we don't handle
> pipe_rasterizer_state->point_size at all, we pretty much just assume
> point_size_per_vertex.

I'm probably just saying stuff that you already know, but ... I'll say
it anyways:

The point of the texcoord semantics is precisely point sprite
replacement. NVIDIA hardware (Fermi+) can only do point sprite
replacement on certain specially-located varyings, hence the texcoord
semantic was created. (And nv30 also has similar restrictions. nv50 is
unconstrained, go figure.)

In legacy GL, only gl_TexCoord varyings may be replaced by point
sprites, and the gl_PointCoord is handled separately. I don't think ES
has an equivalent of point sprite coord replacements.

Hardware without that restriction should probably not use the texcoord
semantic and just use GENERIC for everything.

Cheers,

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-16 Thread Wladimir 
> I think it would be reasonable to re-emit the shader state (or maybe
> just the varyings) when the primitive type changes from points to
> non-points. It virtually never happens that the same shader combo is
> used for points and non-points.

Thinking about it, this might even simplify some contorted code we
currently have in the emit sequence with regard to pointsize VS
outputs. Which becomes even worse in GC7000 where there's more (USC /
buffering related) state depending on the exact number of VS outputs.

Hmm that state depends on point_size_per_vertex, not whether we're
rendering points. So I guess we'd want to re-link the shader if:

- switching from point to non-point rendering, or vice versa
- if rendering points AND point_size_per_vertex changes

Though as for the latter I have no clue where vivantes get the point
size from if !point_size_per_vertex, currently we don't handle
pipe_rasterizer_state->point_size at all, we pretty much just assume
point_size_per_vertex.

Wladimir
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-16 Thread Wladimir 
>> What if the PS doesn't use the point coordinate, e.g. to render solid
>> points?
>>
>> I thought about that, but I don't think it's general enough.
>>
>> Could we make the blitter label texture coordinates properly?
>
> We could do that, but still most texcoord varyings from actual GLSL
> shaders will end up with SEMANTIC_GENERIC, which will break if the
> application is really using flatshading.

At least OpenGL ES would be covered in that case, as flat shading only
exists in OpenGL ES 1 which has no shaders.

I think it would be reasonable to re-emit the shader state (or maybe
just the varyings) when the primitive type changes from points to
non-points. It virtually never happens that the same shader combo is
used for points and non-points.

Wladimir
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-16 Thread Lucas Stach 
Am Donnerstag, den 16.11.2017, 11:36 +0100 schrieb Wladimir:
> On Thu, Nov 16, 2017 at 11:29 AM, Lucas Stach  > wrote:
> 
> > Or maybe we can just scan the input
> > varyings and if we find a PCOORD varying assume that we are going
> > to
> > render points, but I don't know if this assumption holds for all
> > cases.
> 
> What if the PS doesn't use the point coordinate, e.g. to render solid
> points?
> 
> I thought about that, but I don't think it's general enough.
> 
> Could we make the blitter label texture coordinates properly?

We could do that, but still most texcoord varyings from actual GLSL
shaders will end up with SEMANTIC_GENERIC, which will break if the
application is really using flatshading.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-16 Thread Wladimir 
On Thu, Nov 16, 2017 at 11:29 AM, Lucas Stach  wrote:

> Or maybe we can just scan the input
> varyings and if we find a PCOORD varying assume that we are going to
> render points, but I don't know if this assumption holds for all cases.

What if the PS doesn't use the point coordinate, e.g. to render solid points?

I thought about that, but I don't think it's general enough.

Could we make the blitter label texture coordinates properly?

Wladimir
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-16 Thread Lucas Stach 
Am Mittwoch, den 15.11.2017, 19:55 +0100 schrieb Wladimir J. van der
Laan:
> > Sorry for noticing before, but this breaks glmark2 texture. I
> > didn't
> > yet dig into the issue but it's definitely caused by this commit.
> > 
> > To reproduce, simply run
> > glmark2-es2-drm -b texture:texture-filter=mipmap
> 
> That's weird, as that neither uses point sprites nor flat shading.
> 
> I'll have a look...

I think the issue is the mipmap generation. The blitter used to do that
is using flatshading, but probably doesn't declare the textcoord
varyings as TGSI_SEMANTIC_TEXCOORD but TGSI_SEMANTIC_GENERIC instead.

It seems this is legal, so we can't rely on texcoord varyings being
declared with TGSI_SEMANTIC_TEXCOORD...

This means we really need to make the varying use a derived state
depending on the primitive. Or maybe we can just scan the input
varyings and if we find a PCOORD varying assume that we are going to
render points, but I don't know if this assumption holds for all cases.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-15 Thread Wladimir J. van der Laan 
> Sorry for noticing before, but this breaks glmark2 texture. I didn't
> yet dig into the issue but it's definitely caused by this commit.
> 
> To reproduce, simply run
> glmark2-es2-drm -b texture:texture-filter=mipmap

That's weird, as that neither uses point sprites nor flat shading.

I'll have a look...

Regards,
Wladimir
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-15 Thread Lucas Stach 
Hi Wladimir,

Am Mittwoch, den 15.11.2017, 18:03 +0100 schrieb Wladimir J. van der Laan:
> A recent commit (see below) fixed flat shading but at the same time
> broke the use of point sprites with multiple varyings. This resulted in
> particle systems rendering wrongly.
> 
> The reason for this is that it set VARYING_COMPONENT_USE_POINTCOORD_[XY]
> for all non-color varyings, causing them to be replaced with the point
> coordinate when rendering points.
> 
> VARYING_COMPONENT_USE_POINTCOORD_[XY] is a misnomer, it should be
> TEXCOORD. Its semantics are: texture coordinates will get replaced with
> the point coordinate when rendering GL_POINTS, for other primitives
> their interpolation is independent of the shading model.
> 
> So use VARYING_COMPONENT_USE_POINTCOORD_[XY] only for texture coordinates.
> This causes them to be interpolated correctly while flat shading, while
> generic varyings are left as-is when rendering point sprites.

Sorry for noticing before, but this breaks glmark2 texture. I didn't
yet dig into the issue but it's definitely caused by this commit.

To reproduce, simply run
glmark2-es2-drm -b texture:texture-filter=mipmap

Regards,
Lucas

> Fixes: cedab87e762aa38997a07bc8a2eb624aed584afd "etnaviv: fix varying 
> interpolation"
> > Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_compiler.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
> b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> index 3180646..6569979 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> @@ -2561,7 +2561,11 @@ etna_link_shader(struct etna_shader_link_info *info,
>    const struct etna_shader_inout *fsio = >infile.reg[idx];
>    const struct etna_shader_inout *vsio = etna_shader_vs_lookup(vs, fsio);
>    struct etna_varying *varying;
> -  bool interpolate_always = fsio->semantic.Name != TGSI_SEMANTIC_COLOR;
> +  /* Texture coordinates will get replaced with the point coordinate when
> +   * rendering GL_POINTS, for other primitives their interpolation is
> +   * independent of the shading model. */
> +  bool is_texcoord = fsio->semantic.Name == TGSI_SEMANTIC_TEXCOORD ||
> + fsio->semantic.Name == TGSI_SEMANTIC_PCOORD;
>  
>    assert(fsio->reg > 0 && fsio->reg <= ARRAY_SIZE(info->varyings));
>  
> @@ -2571,13 +2575,14 @@ etna_link_shader(struct etna_shader_link_info *info,
>    varying = >varyings[fsio->reg - 1];
>    varying->num_components = fsio->num_components;
>  
> -  if (!interpolate_always) /* colors affected by flat shading */
> +  /* PA_ATTRIBUTES appears to be unused on HALTI0 and up */
> +  if (!is_texcoord) /* colors affected by flat shading */
>   varying->pa_attributes = 0x200;
>    else /* texture coord or other bypasses flat shading */
>   varying->pa_attributes = 0x2f1;
>  
> -  varying->use[0] = interpolate_always ? 
> VARYING_COMPONENT_USE_POINTCOORD_X : VARYING_COMPONENT_USE_USED;
> -  varying->use[1] = interpolate_always ? 
> VARYING_COMPONENT_USE_POINTCOORD_Y : VARYING_COMPONENT_USE_USED;
> +  varying->use[0] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_X : 
> VARYING_COMPONENT_USE_USED;
> +  varying->use[1] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_Y : 
> VARYING_COMPONENT_USE_USED;
>    varying->use[2] = VARYING_COMPONENT_USE_USED;
>    varying->use[3] = VARYING_COMPONENT_USE_USED;
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-15 Thread Wladimir J. van der Laan 
A recent commit (see below) fixed flat shading but at the same time
broke the use of point sprites with multiple varyings. This resulted in
particle systems rendering wrongly.

The reason for this is that it set VARYING_COMPONENT_USE_POINTCOORD_[XY]
for all non-color varyings, causing them to be replaced with the point
coordinate when rendering points.

VARYING_COMPONENT_USE_POINTCOORD_[XY] is a misnomer, it should be
TEXCOORD. Its semantics are: texture coordinates will get replaced with
the point coordinate when rendering GL_POINTS, for other primitives
their interpolation is independent of the shading model.

So use VARYING_COMPONENT_USE_POINTCOORD_[XY] only for texture coordinates.
This causes them to be interpolated correctly while flat shading, while
generic varyings are left as-is when rendering point sprites.

Fixes: cedab87e762aa38997a07bc8a2eb624aed584afd "etnaviv: fix varying 
interpolation"
Signed-off-by: Wladimir J. van der Laan 
---
 src/gallium/drivers/etnaviv/etnaviv_compiler.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index 3180646..6569979 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -2561,7 +2561,11 @@ etna_link_shader(struct etna_shader_link_info *info,
   const struct etna_shader_inout *fsio = >infile.reg[idx];
   const struct etna_shader_inout *vsio = etna_shader_vs_lookup(vs, fsio);
   struct etna_varying *varying;
-  bool interpolate_always = fsio->semantic.Name != TGSI_SEMANTIC_COLOR;
+  /* Texture coordinates will get replaced with the point coordinate when
+   * rendering GL_POINTS, for other primitives their interpolation is
+   * independent of the shading model. */
+  bool is_texcoord = fsio->semantic.Name == TGSI_SEMANTIC_TEXCOORD ||
+ fsio->semantic.Name == TGSI_SEMANTIC_PCOORD;
 
   assert(fsio->reg > 0 && fsio->reg <= ARRAY_SIZE(info->varyings));
 
@@ -2571,13 +2575,14 @@ etna_link_shader(struct etna_shader_link_info *info,
   varying = >varyings[fsio->reg - 1];
   varying->num_components = fsio->num_components;
 
-  if (!interpolate_always) /* colors affected by flat shading */
+  /* PA_ATTRIBUTES appears to be unused on HALTI0 and up */
+  if (!is_texcoord) /* colors affected by flat shading */
  varying->pa_attributes = 0x200;
   else /* texture coord or other bypasses flat shading */
  varying->pa_attributes = 0x2f1;
 
-  varying->use[0] = interpolate_always ? 
VARYING_COMPONENT_USE_POINTCOORD_X : VARYING_COMPONENT_USE_USED;
-  varying->use[1] = interpolate_always ? 
VARYING_COMPONENT_USE_POINTCOORD_Y : VARYING_COMPONENT_USE_USED;
+  varying->use[0] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_X : 
VARYING_COMPONENT_USE_USED;
+  varying->use[1] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_Y : 
VARYING_COMPONENT_USE_USED;
   varying->use[2] = VARYING_COMPONENT_USE_USED;
   varying->use[3] = VARYING_COMPONENT_USE_USED;
 
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev