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

[Jerome Glisse]

On Mon, Jul 30, 2012 at 1:03 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Mon, Jul 30, 2012 at 12:52 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
>> On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
>>> On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
>>>> 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.
>>>
>>> Some further clarifications from the hw team.  If you want to have
>>> truly independent z and stencil buffers that allows for mixing and
>>> matching, you need to make sure that any z and stencil buffer that can
>>> be bound together must share the same addressing parameters (except
>>> tile split), and you must disable the htile buffer on evergreen and
>>> before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
>>> for stencil on cayman and newer
>>> (DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
>>> in unbinding z or stencil independently (but not mixing and matching)
>>> then you don't need to the above restrictions on the htile buffer.
>>> You can do so by setting the format to INVALID.
>>>
>>> Alex
>>
>> Well somehow i can't reproduce might have been fixed by something like
>> render backend fix. I should have write down how i saw this back in
>> the day.
>
> I think it was related to tiling.  I remember you mentioning something
> about that at the time.
>
> Alex

Yeah might be tiling related, surface allocator probably got the bo size right.

Cheers,
Jerime