[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Marek Olšák]

On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> If we don't need stencil, don't allocate it.
>> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>>
>> v2: actually do it correctly
>
> Big NAK
>
> We need to allocate stencil and depth no matter what. Otherwise it
> will lockup. You can take a look by poisonning the surface and see
> that when stencil is disabled or depth is disabled the hw still write
> to it.

:)

If what you say is true, then we're in a big trouble. Regardless of
this patch, we're in it right now, because we cannot fully disable
depth or stencil if the user binds a NULL zbuffer. That's clearly the
kind of issue that cannot be fixed in the allocator code and should be
fixed in r600g where the hardware is programmed.

I *think* that the correct way to disable Z or stencil is to set the
Z_INVALID or STENCIL_INVALID format, respectively, and not by
disabling reads and writes. (cc'ing Alex to confirm that if he can). I
don't think the hardware designers have added those "invalid" formats
just for the lulz. Please see my latest kernel patch "drm/radeon/kms:
allow "invalid" DB formats as a means to disable DB" that tries to
address this issue.

For r600g, I was thinking of allocating a dummy buffer that will be
always bound in case the depth or stencil buffer or both are missing.
Either way, we should find how to get around this issue without
wasting memory, especially when there are other options to try.

BTW, before we used this allocator, we allocated the depth and stencil
buffers in separate resources. We might need to get back to it in the
future if Gallium grows separate depth and stencil buffer bindings.

Marek