<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [nva5] Wrong provoking vertex is selected for flat attribute interpolation (clipping?)" href="https://bugs.freedesktop.org/show_bug.cgi?id=66642#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [nva5] Wrong provoking vertex is selected for flat attribute interpolation (clipping?)" href="https://bugs.freedesktop.org/show_bug.cgi?id=66642">bug 66642</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>