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

[Alex Deucher]

On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák <maraeo at gmail.com> wrote:
> 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.

That is correct.  I just verified with the hw team.  If you allocate
both buffers there are some restrictions in that they share tiling
parameters, but you can set either buffer to _INVALID and allocate one
or the other independently.

Alex

>
> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel