[Mesa-dev] r600g: hyperz

Jerome Glisse j.glisse at gmail.com
Sat Jul 14 09:28:26 PDT 2012


On Sat, Jul 14, 2012 at 9:56 AM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Fri, Jul 13, 2012 at 8:11 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
>> On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> Hi Jerome,
>>>
>>> I couldn't open the patch, because freedesktop.org doesn't seem to
>>> work for me today, it always times out.
>>>
>>> Anyway, non-working code shouldn't be merged into Mesa master, because
>>> it decreases the quality of the driver and is a pain to maintain. As
>>> as I said in another email, merging non-working code on purpose is a
>>> very bad idea. Please don't do it.
>>>
>>> Marek
>>
>> Code works, no regression, but if you enable hyperz get ready to
>> experience lockup, likelyhood depends on what you are doing.
>>
>> So no i don't consider this a non working code. It does work and
>> doesn't regress.
>
> Is it just 6xx/7xx that locks or also evergreen?  Also even if we
> don't turn on hyperz, it probably makes sense to always have an htile
> buffer bound as the htile cache (and backing htile buffer) is used for
> Z/S compression, culling, fast ops, etc. in addition to HiZ/S if a Z
> or S buffer is bound.
>
> Alex

Just enabling htile surface is enough to trigger the lockup, thus we
can't bind the htile buffer. Quite frankly i don't know how much
evergreen is an issue, i pretty much stuck with r6xx/r7xx as they were
always locking up with my test case. Thought i have been able to
lockup evergreen but i did have the feeling that it was lot less
likely to happen.

Basicly to trigger the lockup you have to switch btw a lot of depth
surface/htile surface, if you just have a single depth buffer you will
be fine. Thus most use case will just work properly.

Cheers,
Jerome


More information about the mesa-dev mailing list