Nouveau - Mar 2014 - ARB_depth_texture regression on nouveau since 9.1

Hello,

I've been tracking down a regression in fbo-generatemipmap-formats
with ARB_depth_texture on nouveau (nv50 and nvc0 are affected) since
http://cgit.freedesktop.org/mesa/mesa/commit/?id=0a1479c829ed34a65e60c6619a8164e1b079aaee

FTR, the test I'm running is:

bin/fbo-generatemipmap-formats GL_ARB_depth_texture -fbo -auto

Looking at the displayed output (without -fbo -auto), it looks like
level 0 is fine, but all the subsequent levels are variously mangled.
(For anyone trying to repro this, there's a _really_ annoying effect
that allocations are relatively constant across runs, so running a
working version can cause a broken version to appear to work. Running
max-texture-size clears it up nicely.)

As you might expect, making format == GL_DEPTH_COMPONENT go to the
fallback in st_TexSubImage at HEAD fixes it too, but I don't think
that's desired. This ends up taking the blit_3d path in
nv50_surface.c.

Of note is that on nva0+, GL_DEPTH_COMPONENT16 seems to work fine,
which is also where the Z16_MSX_LSR storage type appeared, so probably
not a coincidence. But a bit surprising is that on nva0+ it does work
for Z16, but still not for the other ones. Makes me think this is a
storage type/tiling-related situation. The blit code has this:

/* Since shaders cannot export stencil, we cannot copy stencil values when
 * rendering to ZETA, so we attach the ZS surface to a colour render target.
 */
static INLINE enum pipe_format
nv50_blit_zeta_to_colour_format(enum pipe_format format)

Getting rid of that conversion naturally breaks stuff... by also
hacking up nv50_blit_select_mode, I can restore it to a very similar
broken mode as without the hackery (adding further hackery to force it
to use zsbuf instead of cbuf breaks everything, but I suspect even
more hackery could be performed to make it work). Unfortunately I
don't know enough about this storage type business, and what effect it
has on things like render targets, esp if you're lying about the type
(i.e. it's trying to render to a Z24X8 texture/memtype as if it were
RGBA8).

Any ideas/suggestions appreciated.

  -ilia