<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#c17">Comment # 17</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:skeggsb@gmail.com" title="Ben Skeggs <skeggsb@gmail.com>"> Ben Skeggs</a> <pre>(In reply to Ilia Mirkin from <a href="show_bug.cgi?id=92306#c14">comment #14</a>) > (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. I believe that restriction might only apply to swizzled surfaces.</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>