Comment # 9
on bug 110897
from Richard Thier
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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
