[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jun 12 01:22:39 UTC 2019


https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #9 from Richard Thier <u9vata at gmail.com> ---
So these does not seem to happen at any time:

        /* Emit clear packets. */
        r300_emit_gpu_flush(r300, r300->gpu_flush.size, r300->gpu_flush.state);
        r300->gpu_flush.dirty = FALSE;

        if (r300->zmask_clear.dirty) {
            fprintf(stderr, "KUL-AKVA\n");
            r300_emit_zmask_clear(r300, r300->zmask_clear.size,
                                  r300->zmask_clear.state);
            r300->zmask_clear.dirty = FALSE;
        }   
        if (r300->hiz_clear.dirty) {
            fprintf(stderr, "KUL-AKVA2\n");
            r300_emit_hiz_clear(r300, r300->hiz_clear.size,
                                r300->hiz_clear.state);
            r300->hiz_clear.dirty = FALSE;
        }   
        if (r300->cmask_clear.dirty) {
            r300_emit_cmask_clear(r300, r300->cmask_clear.size,
                                  r300->cmask_clear.state);
            r300->cmask_clear.dirty = FALSE;
        }

At least not with glxgears. But I kind of get the impression that the intention
of the code is to end up here as earlier we set things as dirty:

            /* Setup Hyper-Z clears. */
            if (r300->hyperz_enabled) {
                if (zmask_clear) {
                    hyperz_dcv = hyperz->zb_depthclearvalue =
                        r300_depth_clear_value(fb->zsbuf->format, depth,
stencil);
                    r300_mark_atom_dirty(r300, &r300->zmask_clear);
                    r300_mark_atom_dirty(r300, &r300->gpu_flush);
                    buffers &= ~PIPE_CLEAR_DEPTHSTENCIL;
/* FIXME: REMOVE KUL* LOGS: */
                    fprintf(stderr, "KUL-A\n");
                }

                if (hiz_clear) {
                    r300->hiz_clear_value = r300_hiz_clear_value(depth);
                    r300_mark_atom_dirty(r300, &r300->hiz_clear);
                    r300_mark_atom_dirty(r300, &r300->gpu_flush);
                }
                r300->num_z_clears++;
            }

Looking at mark_atom_dirty it seems to set the flag. I do not know who deletes
it but it got deleted. Also I have printed what is the value of "buffers" where
we enter the "KUL-C" code path (according to my log scheme) and the value is
buffers=4 which is the first (0th) color buffer. It is not some new kind, but
above this check I see only one place where this could get zeroed and maybe
that is not happening for this card but for others it does.

What bugs me is that the dirtyness of zmask_clear and hiz_clear also go away
somewhere, but I am too tired to see where. Just wanted to write down all the
stuff so far and at least provide the logs and insights.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190612/9c8983a9/attachment.html>


More information about the dri-devel mailing list