On 03/09/2012 09:07 AM, Roland Scheidegger wrote:
Brian,
I think you're right, the test in r200_ioctl.c looks bogus
(the idea is fastz clear can only be used if both depth and stencil are
cleared, though the test isn't quite right as it certainly would be
possible to use fastz clear if there's n
btw I think there's more wrong with clears, for instance fbo clears
(BUFFER_BIT_COLORx) will always lead to swrast fallback, which seems
unnecessary. Clearly if we can render to it we can also clear it. The
clear function is just meta_Clear actually so maybe the whole
r200/radeonClear functions cou
Brian,
I think you're right, the test in r200_ioctl.c looks bogus
(the idea is fastz clear can only be used if both depth and stencil are
cleared, though the test isn't quite right as it certainly would be
possible to use fastz clear if there's no stencil buffer at all).
However, all code related
Dave, it looks like you were the last person to touch this code.
-Brian
On 03/09/2012 07:33 AM, Brian Paul wrote:
I happened to be looking at radeonClear() and r200Clear() in the
legacy DRI drivers. I think there's a bug in one function or the other
in the hyperz/fastclear test:
From radeon_
I happened to be looking at radeonClear() and r200Clear() in the
legacy DRI drivers. I think there's a bug in one function or the
other in the hyperz/fastclear test:
From radeon_ioctl.c:
if (rmesa->using_hyperz) {
flags |= RADEON_USE_COMP_ZBUF;
/* if (rmesa->radeon.radeonScree
