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

From: Alex Deucher <alexdeucher@gmail.com>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG
Date: Mon, 30 Jul 2012 12:16:22 -0400	[thread overview]
Message-ID: <CADnq5_PuGQPe9ehSK9wF9GNnMi5Y11-WLiX76b3-1Yu2wyu_EQ@mail.gmail.com> (raw)
In-Reply-To: <CADnq5_P+bRXyD0ySNi24_xAcc9hs-PAtircPodxAyM3he+=tGw@mail.gmail.com>

On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák <maraeo@gmail.com> wrote:
>> On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>> On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák <maraeo@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel