Early analysis makes it seem like the issue is with face culling or depth tests. The colors you see on the model are the background color on which the model is drawn (Or not drawn, as the case might be.) Both depth test and front-face culling are enabled.

The frag shaders being used to draw it are *crazy* long, they're all like

if (bool) { bunch o' code }
if (other bool) { bunch o' code }
if (third bool) { bunch o' code }

and so on. I guess they were written with the assumption that the programs would be compiled with the bools known ahead of time and only have one or two of the bunches o' code. Oh well. But they're generally simple... Could still be an error in the frag shaders though, should try replacing them with just writing a solid color. Hopefully qapitrace makes that possible.

This issue reproduces on both nvc0 and nv50.

Created attachment 117125 [details]
vert shader at failing call

OK, so in my trimmed trace,

http://people.freedesktop.org/~imirkin/traces/tru-trim.trace.xz

it seems like things start going wrong on API call 424136 (I ran apitrace dump-images with '*/draw' and then did the diff-images thing).

Coincidentally, right before this happens, it does glDepthFunc(GL_EQUAL) [which is *nuts*] and glDepthRange(0, 0.98).

I need to see if nuking that glDepthRange call causes llvmpipe to generate the same image for that draw call. Also see if there are any funny depth-related bits we know about... ugh.

Still bothering me is that apitrace is returning broken-looking depth surfaces.

The previous draws all had glDepthRange(0.98, 1)... coincidence? And the shader will end up generating very negative z values, which will map to a depth range of 0.98 I guess?

Erm, make that call 390980. Everything else I said applies.

There are even earlier differences in 377128 and the draws that follow, but they seem like minor lighting differences between llvmpipe and nvc0.

I think this bug affects Deus Ex: Human Revolution as well, where characters, weapons, doors have those flashing artifacts on them.

DeusEx HR trace (uncompressed 296M):
https://drive.google.com/open?id=0B-tTbLKBl-tOS0pFV0pVd19vQW8

OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV106
OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.1.0-devel (git-5a64549)
OpenGL core profile shading language version string: 4.30

Confirmed, I can reproduce the issue on my GF119.

Unfortunately, it still not fixed but I will have a look at some point.

Thanks for reporting.

For the deus ex trace, the first bad shader is 3355374. The newly-built/used vertex shader (linked into program 5098) does look a LOT like the one from TR:U, but not 100% identical.

Should probably double-check whether 3348622 and 3348662 check out - perhaps the differences were too small for retracediff.py to care. But those happen around another glDepthRange() call.

These rendering artifacts appear to magically be gone on Mesa 13.0.3. I haven't done a reverse bisect to see what fixed it.

OK, I did the bisect. It was commit

commit b04ef3c08a288a5857349c9e582ee2718fa562f7
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Fri May 30 23:52:22 2014 -0700

    glsl: Immediately inline built-ins rather than generating calls.

that fixed it. That means that this was some kind of nv50/ir compiler bug which has gotten hidden away. Urgh :(

FWIW I did determine that it was the previously attached vertex shader that was at fault. However comparing the two versions (before and after the patch that "fixed" it), I didn't see any apparent differences. There was some minor code reordering, but nothing serious. I'm going to stop looking now.

Good to know. Maybe F1 2015 now works by luck too? :)