On Sat, Jul 14, 2012 at 9:56 AM, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Fri, Jul 13, 2012 at 8:11 PM, Jerome Glisse <j.gli...@gmail.com> wrote: >> On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
