[Mesa-dev] RFC: Fixing nv30 fbo attachments

[Ilia Mirkin]

Hello,

I attempted doing this a while back, before I really understood what
was going on. I got some advice that went totally over my head, and I
dropped the issue. I think I'm much better-prepared to tackle the
issue this time around.

To recap, nv30 (and nv40) hw can't handle certain color/depth format
combinations. Specifically, a 16-bit color format must be paired with
a 16-bit depth format, and a 32-bit color format must be paired with a
32-bit depth format (well, Z24S8). This HW also can't handle different
per-attachment sizes, and also the "linearity" of all the attachments
must be the same. (Whether a surface is linear or not is _generally_
dictated by its w/h, but not always -- POT textures can sometimes end
up allocated linearly by e.g. the ddx, or something else.) The
different sizes are handled by not exposing ARB_fbo. However the rest
of the cases remain.

Now that I kinda understand how things are structured, I was thinking
of doing the following:

When rendering (i.e. draw_vbo & co) and the fbo has changed (and has
one of the problems above), I would instead put in a temporary texture
as the depth attachment. Before actually drawing, I would blit from
the real target texture into the temporary texture, and then when
rendering is done, blit back from the temp texture back into the
target. This deals with the target texture getting modified between
draws with various blits/mapping/whatever.

This means that you'll only get 16 bits of depth even if you ask for
24 with a 16-bit color format, but the alternative seems too
complex/costly.

So there are a few questions from this approach:

1. Where do I get the temporary texture from? (And more importantly --
when... what happens if allocation fails?)

2. Having to blit the depth texture back and forth on every draw seems
_really_ wasteful... anything I can do about that?

Thanks,

  -ilia