Nouveau - Jul 2013 - [Bug 66642] New: [nva5] Wrong provoking vertex is selected for flat attribute interpolation (clipping?)

https://bugs.freedesktop.org/show_bug.cgi?id=66642

          Priority: medium
            Bug ID: 66642
          Assignee: nouveau at lists.freedesktop.org
           Summary: [nva5] Wrong provoking vertex is selected for flat
                    attribute interpolation (clipping?)
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: alzeih at gmail.com
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: git
         Component: Drivers/DRI/nouveau
           Product: Mesa

The following piglit test:

  interpolation-flat-gl_BackColor-smooth-none.shader_test

appears to select the wrong provoking vertex depending on the exact value of
v[0].y.

For v[0].y > -1.0, the triangle ends up red.
For v[0].y = -1.0, the triangle ends up green.
For v[0].y < -1.0, the triangle ends up (correctly) blue.

Hardware: nva5 (GT330M) in MacBookPro6,2
Mesa version: 1415a1884c
Kernel: 3.9.8-1-ARCH

Suspect the clipper doesn't respect the index of the provoking vertex in the
triangle?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130706/b9bbacf8/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=66642

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Created attachment 84289
  --> https://bugs.freedesktop.org/attachment.cgi?id=84289&action=edit
pushbuf dump of
generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-flat-gl_BackColor-smooth-none.shader_test

calim and I looked at this briefly, he couldn't figure out the issue. (And I
know nowhere close to enough about it to even try.)

Some observations:

(a) I see the same problem on NV96.
(b) All the interpolation-flat-gl_*BackColor-smooth-* tests fail, the
FrontColor ones succeed.

Attached is a pushbuf dump of the program. Would be good to see what the blob
does on the same test.

"""
<calim> so, if you want to fix it completely you have to add shader
variants,
if you just want to fix it partially you have to set SHADE_MODEL depending on
the shader instead of just the rasterizer state, or you ignore it because
it's
an insignificant corner case no one cares about
<calim> ah yes, or you see if the blob knows a cheat around it
<calim> it would be good to know if it actually sets SHADE_MODEL to flat
in
that test
"""

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130819/53dbebf5/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=66642

--- Comment #2 from Ilia Mirkin <imirkin at alum.mit.edu> ---
FTR this test also fails with nvidia 331.20 drivers on NV98. (Interesting, with
the blob drivers, *all* the smooth tests fail.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20131125/7ba42d9a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=66642

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
OK, so... I spent some time thinking about all this with my newfound
understanding of flatshading, and some of the nv50 family limitations around
all this. There are a few separate issues:

(a) shade model flat just totally didn't work, any tests that passed did so
largely by happy coincidence

I have a patch that fixes this that will be going out shortly. I believe this
should fix a lot of cases that are actually hit by real software. When
flat-shading, we have to mark the varying as non-perspective-divided.

(b) When forcing both primary and secondary color to smooth or flat, that
causes totally wrong data to be generated

This is easily fixable by moving the frontcolor varying to the non-interpolated
section of the map. Needs some more analysis, but should be entirely doable.
Probably need to be careful about not setting SHADE_MODEL = flat in this case.

(c) nv50 family gpu's are not set up to have front and back colors with
different interpolation parameters.

The issue is that the first and second color need to be adjacent to one another
in the result map in order for the back colors to replace the front colors.
However the way it works is that the result map is split into 3 pieces:

1. attributes invisible to frag shader (position, back color)
2. interpolated varyings (with a special allowance for the color varyings to be
flat-shaded when the shade model = flat)
3. non-interpolated varyings

So there are a few things we can do here. We can ignore the whole front/back
color thing and just use regular varyings and then use the faceness to
determine which face to use. If the first color is smooth and the second is
flat, we can probably place it at the interp/non-interp boundary. However for
the inverse, there is no clear way to handle this (i.e. first color is flat,
secondary color is smooth/noperspective).

The piglit test mentioned in this bug falls into category (b), which I plan on
fixing. I believe I'm going to leave category (c) unfixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151024/7aef8bdf/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=66642

GitLab Migration User <gitlab-migration at fdo.invalid> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #4 from GitLab Migration User <gitlab-migration at
fdo.invalid> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1055.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190918/311e8609/attachment.html>