<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - GL Excess demo renders incorrectly on nv43" href="https://bugs.freedesktop.org/show_bug.cgi?id=92306#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - GL Excess demo renders incorrectly on nv43" href="https://bugs.freedesktop.org/show_bug.cgi?id=92306">bug 92306</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>(In reply to Andrew Randrianasulu from <a href="show_bug.cgi?id=92306#c13">comment #13</a>) > (In reply to Ilia Mirkin from <a href="show_bug.cgi?id=92306#c12">comment #12</a>) > > (In reply to Andrew Randrianasulu from <a href="show_bug.cgi?id=92306#c11">comment #11</a>) > > > "Mismatched color and zeta formats, ignoring zeta." > > > > Yeah, as I suspected... unfortunately there's not a ton you can do besides > > fixing the issue. The problem is that you can't render to a 32-bit color > > format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you > > can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit > > zeta (Z24S8). > > > > My current solution to this problem is to just not set the zeta buffer and > > move on with life. This leads to incorrect rendering, but at least no hangs. > > > > The proper solution is to have 2 depth textures that you copy to and fro and > > set the "right" one for the given color format. Ideally while minimizing the > > number of copies. > > Hm, but in my case it apparently worked fine... so, may be check is > overrestrictive? > > I also tried to apply this path on top of mesa version indicated above > ((git-93161be) > > ----patch--- > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c > b/src/gallium/drivers/nouveau/nv30/nv30_state.c > index fd604c2..cceedfd 100644 > --- a/src/gallium/drivers/nouveau/nv30/nv30_state.c > +++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c > @@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe, > (util_format_get_blocksize(fb->zsbuf->format) > 2) != > (util_format_get_blocksize(fb->cbufs[0]->format) > 2)) { > nv30->framebuffer.zsbuf = NULL; > - debug_printf("Mismatched color and zeta formats, ignoring > zeta.\n"); > + debug_printf("Mismatched color %d and zeta %d formats, ignoring > zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format); > } > } > } > --------end----- > > and got this in terminal: > "Mismatched color 1 and zeta 16 formats, ignoring zeta." > > This is a bit strange, this demo from ~2002 era, and apparently was working > fine on older nvidia hardware. And on nouveau, until this commit. I will > retest just for making sure it doesn't flood my dmesg with errors .... You should be seeing errors about invalid values in dmesg for 0208 or some similar method. I'm guessing that the zeta buffer is used in such a way that things happen to work out, but the card doesn't really support it. src/gallium/include/pipe/p_format.h: PIPE_FORMAT_B8G8R8A8_UNORM = 1, src/gallium/include/pipe/p_format.h: PIPE_FORMAT_Z16_UNORM = 16, Not a valid combo, AFAIK.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>