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?
Created attachment 84289 [details] 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 """
FTR this test also fails with nvidia 331.20 drivers on NV98. (Interesting, with the blob drivers, *all* the smooth tests fail.)
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.
-- 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.